разный размер бэкапа на мастере и реплике
kos12345 opened this issue · 10 comments
добрый день.
выполняю полный бэкап на мастере - размер бэкапа 805GB , Zratio 1.74
выполняю полный бэкап на реплике - размер бэкапа 468Gb Zratio 2.99.
в чём может быть причина, подскажите пожалуйста.
zlib версия одинаковая. при выполнении бэкапа использую команду --compress
Здравствуйте, какая у Вас версия сервера и пробэкапа?
pg_probackup-10 2.5.4 (PostgreSQL 10.19)
ОС RHEL 7.8
PS. реинициализировал реплику. всё равно бэкап с неё весит почти в 2 раза меньше.
вот такие размеры в разрезе баз данных внутри бэкапов
на мастере
553G /var/lib/pgsql/probackup/backups/master/RXNHGP/database/base/19888
228G /var/lib/pgsql/probackup/backups/master/RXNHGP/database/base/40555
на реплике
218G /var/lib/pgsql/probackup/backups/replica/RYEPND/database/base/19888
239G /var/lib/pgsql/probackup/backups/replica/RYEPND/database/base/40555
бд 19888 там хранятся фотографии
бд 40555 там текстовые таблицы
выполняю полный бэкап на мастере - размер бэкапа 805GB , Zratio 1.74
выполняю полный бэкап на реплике - размер бэкапа 468Gb Zratio 2.99.
а степени сжатия вас не удивляют?
805 * 1.74 = 1400,7
468 * 2.99 = 1399,32
Думаю, вполне одинаковые размеры исходного каталога данных ...
так я и не говорю, что на реплике меньше данных. у меня вопрос, почему на ней сжимается сильнее.
я ж в первом сообщении написал что zlib одинаковой версии. что ещё проверить - я не знаю, недостаточно опыта.
может кто подскажет.
ОС идентичные по идее. но может админы что-то обновили - установили на одном, чего нет на втором...
почему на ней сжимается сильнее.
Возможно из-за разного физического заполнения страниц, в которых хранятя данные на дисках!?
почему на ней сжимается сильнее.
Возможно из-за разного физического заполнения страниц, в которых хранятя данные на дисках!?
а это разве возможно при физической репликации?
Я догадался.
Дело вот в чём:
- когда постгресс подчищает удалённые таплы, он их уплотняет,
- но «освободившееся» место остаётся «грязным», ванильный Постгрес его ни как не зачищает,
- однако, когда в WAL пишется Full-Page-Write запись страницы, в ней «пустое место» вырезается,
- по-этому на реплике на «пустом» месте в странице - нули, и они хорошо жмутся.
Кстати, кажется с 15 версии поменялся алгоритм упаковки таплов, и возможно что место стало зачищаться. Но на вскидку не помню, надо проверить.
Если что, я пытался протолкнуть в ваниль зачистку пустого места в странице. Отмахнулись, сказали «не понятен профит, и может скажется на скорости».
В ПгПро сборках конечно же место зачищается.
В теории, вырезать пустое место можно во время бэкапа. Но это не «два пальца об асфальт», т.к. бэкап не знает, что есть таблица, а что индекс; а индексы бывают разные. Наверное, поставим себе задачку на подумать.
то есть vacuum хоть и написано, что "высвобождает пространство, занимаемое «мёртвыми» кортежами"
на самом деле просто в FSM помечает это место как свободное, но фактически данные продолжают лежать в таблице?
и при реинициализации реплики, разве basebackup не просто копирует 1 к 1 файлы на реплику?
Почему же? Место свободное в том смысле, что в него писать можно. «Свободное» не значит «чистое».
Например, free тоже только помечает место свободным в обычных аллокаторах, не зачищая его.