PostgreSQL: Streaming lag with {#MASTER} is too high (over 600 in 5m)

Если я правильно понял слейв не успевает за мастером, то тут только увеличить производительность слейва.

Производительность на cpu, памяти? Я так понимаю это лаги репликации? Может ещё в postgresql.conf нужно параметр увеличить max_standby_streaming_delay = *s ?

Слейв отстал от мастера слишком надолго. Есть несколько способов решения проблемы:

• настроить репликацию через replication slot (есть минусы, что wal файлы будут копиться, пока их не потребит слейв, что может привести к «wal бомбе»)
• увеличить параметр wal_keep_segments (количество wal файлов, которые будет хранить мастер)

Слейв может отставать по нескольким причинам, например железо хуже, чем у мастера, из-за этого он не успевает раскодировать и накатывать wal файлы (postgres делает это в один поток). Проверить это можно просто взглянув на процессы, если есть с именем

postgres: startup   recovering

и он потребляет 100% ядра, значит postgres не успевает накатывать приходящие wal файлы, тут надо либо снижать количество генерируемых wal файлов, либо апгрейдить железо на слейве. Вторая причина отставаний может быть в том, что на слейв приходят запросы, которые могут блокировать накатку wal логов (эту проблему можно обойти через тюнинг параметра max_standby_streaming_delay).

max_standby_streaming_delay - от тебе может помочь только в случае, если на слейв идут запросы и они блокируют накатку wal. И то в этом случае его надо не увеличивать, а уменьшать, потому что этот параметр отвечает за то, через какое время начинать отстреливать запрос, который блокирует накатку wal.

Слейв отстал от мастера слишком надолго. Есть несколько способов решения проблемы:

Значит можно и не накатывать новый дамп с мастера на слейв параметров достаточно будет для исправления ошибки?

Вопрос про будущее? Я не знаю твой юзкейс, ты ж ничего не рассказываешь. Возможно, параметры тебе помогут и не будет отставать реплика, но я так же описал кейсы, где тебе не поможет тюнинг параметров.

Не, еще не про будущее) Кейс такой, были смигрированы старые инстансы в новый мастер и реплику для куберов (k8s) под сервисы. В итоге при миграции, что то отвалилось была большая нагрузка на машинки... И после этого слэйв начал оставать по мониторингу zabbix, хотя в данный момент по производительности тачек всё пришло в норму. В данный момент тюнинг на тачках по параметрам который ты описал выше стоит wal_keep_segments=64, а max_standby_streaming_delay=120s

wal_keep_segments=64

это очень мало. Т.е. это говорит о том, что мастер хранит не больше 64 (если не ошибаюсь 16-мегабайтовых) файла wal. То есть если у тебя пришла транзакция, которая нагенерила сразу пачку большую пачку изменений, то это всё упаковывается в файлы и, к примеру, это не влезло в 64 файла, а потребовалось 65 файлов, то у тебя уже стримки отвалятся, потому что они не получат wal для накатки. Советую поставить этот параметр много выше текущего, зависит от доступного места на твоих нодах, но это точно должны быть сотни, а то и тысячи, чтобы не допускать отставаний.

В итоге при миграции, что то отвалилось была большая нагрузка на машинки

если я правильно понял тебя, то на стримки идут селекты? Если да, то надо ставить параметр max_standby_streaming_delay в такое значение, после которого не жалко остреливать запросы, чтобы не сломать репликацию.

Ок, Спасибо за поделившейся инфой! поменяю параметры проверю..