разный размер бэкапа на мастере и реплике

[kos12345]

добрый день.
выполняю полный бэкап на мастере - размер бэкапа 805GB , Zratio 1.74
выполняю полный бэкап на реплике - размер бэкапа 468Gb Zratio 2.99.
в чём может быть причина, подскажите пожалуйста.
zlib версия одинаковая. при выполнении бэкапа использую команду --compress

[fukanchik]

Здравствуйте, какая у Вас версия сервера и пробэкапа?

[kos12345]

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 там текстовые таблицы

[slothfk]

выполняю полный бэкап на мастере - размер бэкапа 805GB , Zratio 1.74
выполняю полный бэкап на реплике - размер бэкапа 468Gb Zratio 2.99.

а степени сжатия вас не удивляют?
805 * 1.74 = 1400,7
468 * 2.99 = 1399,32

Думаю, вполне одинаковые размеры исходного каталога данных ...

[kos12345]

так я и не говорю, что на реплике меньше данных. у меня вопрос, почему на ней сжимается сильнее.
я ж в первом сообщении написал что zlib одинаковой версии. что ещё проверить - я не знаю, недостаточно опыта.
может кто подскажет.
ОС идентичные по идее. но может админы что-то обновили - установили на одном, чего нет на втором...

[slothfk]

почему на ней сжимается сильнее.

Возможно из-за разного физического заполнения страниц, в которых хранятя данные на дисках!?

[kos12345]

почему на ней сжимается сильнее.

Возможно из-за разного физического заполнения страниц, в которых хранятя данные на дисках!?

а это разве возможно при физической репликации?

[funny-falcon]

Я догадался.

Дело вот в чём:

• когда постгресс подчищает удалённые таплы, он их уплотняет,
• но «освободившееся» место остаётся «грязным», ванильный Постгрес его ни как не зачищает,
• однако, когда в WAL пишется Full-Page-Write запись страницы, в ней «пустое место» вырезается,
• по-этому на реплике на «пустом» месте в странице - нули, и они хорошо жмутся.

Кстати, кажется с 15 версии поменялся алгоритм упаковки таплов, и возможно что место стало зачищаться. Но на вскидку не помню, надо проверить.

[funny-falcon]

Если что, я пытался протолкнуть в ваниль зачистку пустого места в странице. Отмахнулись, сказали «не понятен профит, и может скажется на скорости».

В ПгПро сборках конечно же место зачищается.

В теории, вырезать пустое место можно во время бэкапа. Но это не «два пальца об асфальт», т.к. бэкап не знает, что есть таблица, а что индекс; а индексы бывают разные. Наверное, поставим себе задачку на подумать.

[kos12345]

то есть vacuum хоть и написано, что "высвобождает пространство, занимаемое «мёртвыми» кортежами"
на самом деле просто в FSM помечает это место как свободное, но фактически данные продолжают лежать в таблице?

и при реинициализации реплики, разве basebackup не просто копирует 1 к 1 файлы на реплику?

[funny-falcon]

Почему же? Место свободное в том смысле, что в него писать можно. «Свободное» не значит «чистое».

Например, free тоже только помечает место свободным в обычных аллокаторах, не зачищая его.