🛠️ Реплика PostgreSQL отстаёт на 20 минут. Отчёты показывают старые данные, а на prima... — 29 июня 2026 г. в 13:02:00.986
🛠️ Реплика 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 не отправляется, не доходит, не записывается или не применяется. Сохраните порядок проверки, чтобы не искать проблему только в сети. #УЦФОРС #PostgreSQL #Репликация #DBA #АдминистрированиеБД