🛠️ Реплика PostgreSQL отстаёт на 20 минут. Отчёты показывают старые данные, а на primary нагрузка выглядит обычной.

Первая версия часто звучит так: «Наверное, сеть».

Но replication lag — это не одна причина, а несколько участков пути WAL.

Условный фрагмент pg_stat_replication на primary:

replica: reports_replica state: streaming

sent: 7/B900010 write: 7/B8FF900 flush: 7/B8FF900 replay: 7/B7A1200

replay_lag: 00:20:14

state = streaming показывает, что поток репликации активен. Но это ещё не значит, что standby успевает применять все изменения.

Как читать развилку: — если sent_lsn отстаёт от текущего WAL на primary, смотрим генерацию WAL и отправку потока; — если write_lsn или flush_lsn отстают от sent_lsn, проверяем доставку, диск и нагрузку на standby; — если write_lsn и flush_lsn близки к sent_lsn, а replay_lsn заметно позади, WAL уже записан на standby, но его применение отстаёт.

Отдельный слой — долгие запросы на hot standby. Они могут конфликтовать с recovery и задерживать replay в пределах настроек. Но это не повод автоматически отменять отчёты: сначала нужно понять последствия для пользователей и свежести данных.

Практический порядок проверки: Разделить lag по этапам: отправка, запись, flush, replay. Проверить генерацию WAL на primary. Посмотреть доставку до standby. Проверить диск, CPU и I/O на реплике. Найти долгие запросы на standby и оценить, конфликтуют ли они с recovery. Проверить настройки hot standby, но не менять их вслепую.

Практический вывод: «реплика отстаёт» — это не диагноз. Сначала нужно понять, где появился разрыв: WAL не отправляется, не доходит, не записывается или не применяется.

Сохраните порядок проверки, чтобы не искать проблему только в сети.

🔹🔹🔹🔹