Коллеги добрый вечер. Подскажите решение проблемы. На мастере по крону

раз в 4 часа запускается задача на insert/update большого количества строк длительностью 1.5 часа. Поток wal порядка 2 ГБ в минуту. Почти сразу реплика отстаёт (слота репликации нет) и начинается восстановление из архива. К сожалению за 2.5 часа до следующего крона она не успевает догнать мастер. В результате запускается следующий крон и очередь растет ещё больше пока wal не удалятся из архива и окончательно теряем реплику. Хотелось бы узнать проигрывание wal через протокол потоковой репликации идёт быстрее или так же как из архива (всё идет в один поток но возможно что в первом случае быстрее)? Какие есть варианты решения?

> Почти сразу реплика отстаёт (слота репликации нет) А почему бы не добавить (перейти на streaming по умолчанию)? > Поток wal порядка 2 ГБ в минуту. А покажите связанные с WAL настройки на primary. И главное — какая это версия PostgreSQL (SELECT version();)? > Какие есть варианты решения? Сначала нужно больше информации, см. выше.

1. Что бы не уронить мастер. Для этого сделали архив wal 2. версия PostgreSQL 14.8 (Debian 14.8-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit (1 row) max_wal_size = 4GB min_wal_size = 1GB wal_level = logical max_wal_senders = 3 wal_buffers = 16MB archive_mode = on archive_timeout = 60 archive_command = 'pgbackrest --stanza=cards --process-max=8 archive-push %p' Настройки pgbackrtest process-max=8 archive-async=y spool-path=/data/postgresql/14/main/pg_wal/spool compress-type=gz compress-level=3

Хм а зачем logical?

> Что бы не уронить мастер. Для этого сделали архив wal А варианта сделать там больше места нет? Ну и таки сделать слот и подстраховаться max_slot_wal_keep_size. Далее, почему max_wal_size = 4GB, почему бы не увеличить? Да и wal_buffers тоже можно. А почему wal_level = logical — есть и логическая репликация? wal_compression выключен? Если да, то почему? ;) > и начинается восстановление из архива Да, а архив-то где находится? Если не на реплике — нет ли там "тормозов" с получением оттуда файлов?

И вот ещё что — если медленно работает именно восстановление (т.е. со скоростью доступа к файлам и т.п. проблем нет) — посмотрите вот на это: https://www.postgresql.org/docs/15/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY Этого всего нет в используемой Вами версии, но была сторонняя утилита для предыдущих, которая делает примерно то же самое (т.е. если именно в этом там проблема, то утилиту можно найти / посмотреть / применить).

что бы не перезапускать мастер если понадобится логическая репликация. Но идея понятна - уменьшить объем wal включение сжатия туда же

можно и max_slot_wal_keep_size выставить для слота и max_wal_size увеличить но это имеет смысл только если потоковая репликация работает быстрее чем восстановление из архива. Сжатие включу, wal_level выставлю в replica. Архив находится на другом хосте. При архивировании действительно были проблемы - авторизация по ssh медленнее чем процесс архивирования. Для pgbackrest это решается настройкой archive-async=y (он архивирует и передаёт пачками а не каждый файл отдельно) эта настройка так же актуальна и для восстановления. Закидывает пачку и по одному проигрывает. Кстати при работе крона очередь на архивацию вырастает до 100 ГБ.

Алексей, вам нужно сначала разобраться с причинами. Отвечая на ваш вопрос, потоковая репликация работает по тому же принципу что и восстановление из архива, в том смысле что тоже в один поток, НО. Потоковая репликация передает данные от сервера бд к серверу бд, и влияет на её скорость сеть между серверами бд. "восстановление из архива" же состоит из двух шагов: archive_command на мастере отправляет wal'ы в промежуточное хранилище, а restore_command на слейве забирает их из промежуточного хранилища. То есть на "восстановление из архива" будет влиять сеть от мастера к хранилищу, и от хранилища к слейву. И в случае с дебагом восстановления из архива - нужно проверять оба этапа, и скорость отправления валов в хранилище, и восстановление из него. Если у вас "хранилище" это какое-нибудь облако, к которому хороший канал (более быстрый чем сеть между серверами, хотя было бы странновато) - то восстановление из архива будет работать быстрее потоковой репликации. 2GB в минуту это так-то не очень много, 270 мегабит/с всего. У вас сеть между серверами 100мегабитная что ли, если отставание сразу происходит?

> но это имеет смысл только если потоковая репликация работает быстрее чем восстановление из архива Не так просто — если (как там это происходит, видимо) большую часть времени она работает быстрее, чем генерируются WAL на primary, но иногда бывает наоборот, то её перспектива догнать primary зависит как раз от запаса места для WAL на нём. Ну и max_wal_size влияет на частоту checkpoints, которые, в свою очередь, влияют на объём WAL (за счёт необходимости писать full-page images при первом изменении страницы после них). Т.е. в том, чтобы дать больше места, есть и такая потенциальная выгода. > Архив находится на другом хосте. Хмм.. так в чём же проблема на реплике тогда, всё же (я как-то не понял, извините)? Т.е. она не успевает получать файлы, или не успевает проигрывать, или что-то третье, неизвестное?

Илья спасибо, посмотрю в сторону сети. Когда начал разбираться с проблемой действительно обнаружилось что реплика не в той сети и скорость ограничена 100 Мб. Эту проблему решили реплика сейчас наливается быстрее (обещали 10 ГБ/с но я пока видел в районе 5-7 Гб/с). Теперь проверю канал между архивом и репликой и то что писали выше.

Эх, я только дописать хотел, что можно поменять кучу настроек, а в итоге окажется что на сервере 2 интерфейса, один на 10Гбит, а другой на 100 мегабит, и данные гоняются как раз не по тому, по которому должны)