Измерение лага репликации PostgreSQL под нагрузкой
Измерение лага репликации PostgreSQL под нагрузкой помогает найти этап, где копится WAL. Разберём физическую репликацию PostgreSQL 18.
Какая метрика лага отражает задержку, видимую пользователю?
На асинхронной реплике replay_lag приближённо показывает задержку появления последних изменений. Отсчёт идёт от сохранения WAL на основном сервере до получения подтверждения его применения на реплике. Для проверки конкретной транзакции отслеживают появление её контрольной записи на реплике в новом снимке данных.
sent, write, flush и replay как разные виды отставания
Для бенчмарка лага репликации PostgreSQL нужны четыре позиции WAL: sent – отправлено, write – записано в ОС, flush – сохранено на диск, replay – применено. Основной сервер показывает их в pg_stat_replication, получая последние три от реплики. pg_wal_lsn_diff считает разрывы в байтах: текущий LSN–sent, sent–write, write–flush, flush–replay.
Топология, слоты и режим подтверждения транзакций
На лаг в pg_stat_replication влияют режим репликации и частота отчётов. Поэтому до теста фиксируют версии, число реплик, synchronous_standby_names, synchronous_commit и слоты. Удержание WAL слотами ограничивает max_slot_wal_keep_size. Лимит проверяется при checkpoint.
Одна временная шкала primary и standby
Опрос обоих серверов пишет LSN и разрывы в CSV с шагом 1 с и метками UTC. Часы узлов синхронизируют. pg_last_xact_replay_timestamp() даёт время commit/abort последней применённой транзакции с основного сервера. При простое её возраст растёт даже у догнавшей реплики, lag может стать NULL.
Как создать и измерить лаг репликации под нагрузкой?
На тестовом стенде постепенно увеличивают нагрузку записи через pgbench и регулярно снимают позиции WAL с обоих серверов. Разрывы между этапами показывают, где растёт очередь, а метрики сети, CPU и дисков помогают найти причину. Если мощности хватает, нагрузка может вообще не вызвать заметного отставания.
Рост WAL, постоянная нагрузка и прекращение записи
В CSV отмечают фазы pgbench. Для расчёта скорости WAL прирост текущего LSN делят на интервал между замерами. Лаг LSN PostgreSQL выражают в байтах. Чтобы измерить время catch-up, после остановки записи фиксируют конечный LSN и ждут, пока реплика его применит.
Когда sent–write растёт из-за сети или receiver
За этим разрывом могут стоять сеть, запись WAL или задержка отчёта реплики. Причину ищут по пропускной способности, потерям и работе walreceiver. p99 лага streaming replication считают отдельно по фазам, указав единицы и шаг опроса.
Где именно копится очередь
Оба разрыва живут на реплике, но упираются в разное: первый в диск, второй в применение WAL.
Как разделить сетевое, дисковое и replay-узкие места?
1. sent–write проверяют вместе с сетью и приёмником WAL: сам разрыв не доказывает сетевую проблему.
2. write–flush сопоставляют с задержками fsync и очередью диска реплики.
3. Для flush–replay проверяют CPU, I/O и конфликты запросов, учитывая отставание flush.
При synchronous replication synchronous_commit задаёт условие завершения COMMIT: remote_apply требует применения WAL на выбранных синхронных репликах.
Почему standby может задерживать применение WAL
Задержка replay WAL под нагрузкой возможна и при стабильном WAL generation rate: конфликт с запросом задерживает применение WAL. Увеличение max_standby_streaming_delay продлевает ожидание. Отмены запросов видны в pg_stat_database_conflicts. hot_standby_feedback уменьшает конфликты очистки ценой накопления старых версий строк на основном сервере.
Пороги, привязанные к байтам и времени восстановления
Порог потери данных задают по RPO, а отставание данных и время catch-up ограничивают отдельно. Сохранённый на диск реплики WAL применяется и после отказа основного сервера. Причину уточняют по network RTT, CPU и I/O обоих узлов.
Измерение лага репликации PostgreSQL под нагрузкой даёт основу для оповещений по этапам: важны размер очереди и скорость её роста. Оповещение по одному порогу lag в секундах такой картины не даёт.