7.2. Инструменты отслеживания репликации

Представление pg_stat_replication

Основной узел является источником всех изменений и может реплицировать данные больше чем на один узел. Скорость отправки изменений и скорость их применения на репликах могут различаться, что выражается в величине отставания репликации и степени актуальности данных. Для определения отставания репликации и других характеристик передачи журнала можно использовать представление pg_stat_replication. В каждой его строке содержится статистика работы отдельного процесса walsender. Представление pg_stat_replication показываеттекущие данные аналогично тому,как работает представление pg_stat_activity:

# TABLE pg_stat_replication;

В тестовом окружении настроен кластер репликации с одним запасным узлом; соответственно,в представлении будет всего одна строка.Набор полей таков:

•pid—идентификатор процесса walsender в операционной системе;

•usesysid,usename—идентификаториимяпользователяСУБД,откотороговыполненопод- ключение со стороны резервного узла;

•application_name — дополнительный идентификатор приложения, который можно указать при подключении к основному узлу;

•client_addr,client_hostname,client_port—сетевые реквизиты со стороны резервного уз-

ла: адрес,имя узла и номер порта;

•backend_start—отметка времени подключения и создания процесса walsender;

178Глава 7. Репликация

•backend_xmin—транзакционный горизонтреплики,переданный основному узлу через об-

ратную связь (см. hot_standby_feedback);

•state — текущее состояние процесса walsender, определяющее и общее состояние репликации:

—startup—walsender находится в процессе запуска;

—catchup—реплика пытается «догнать» основной узел;

—streaming—этоосновнойрежимработы:walsenderпередаетпотокизмененийнареп- лику,после того как реплика успешно «догнала» основной узел;

—backup—walsender находится в процессе передачи резервной копии;

—stopping—walsender находится в процессе выключения.

На основе следующих полей, показывающих состояние отправки и приема журнала, можно определить величину отставания конкретной реплики и объем работы,который ей предстоит проделать,чтобы полностью устранить это отставание:

•sent_lsn—позиция журнала,записи до которой отправлены на реплику;

•write_lsn—позиция журнала,записи до которой приняты,но еще не синхронизированы процессом walreceiver;

•flush_lsn — позиция журнала, записи до которой уже синхронизированы процессом walreceiver;

•replay_lsn—позиция журнала,записи до которой воспроизведены процессом startup.

Как уже упоминалось, изменения на репликах могут появляться с задержкой. Величина задержки (отставание репликации) в идеале должна быть близка к нулю, но это не всегда возможно.Отставание еще можно расценивать как меру работы,которую необходимо проделать. Однако основной узел не стоит на месте, и в его журнал записываются новые и новые изменения.Объем появляющихся измененийможетварьироваться; соответственно,отставание реплики тоже будет непостоянным. Увеличение отставания может выражаться в том, что результаты выполнения запросов к основному узлу и реплике будут расходиться, и это следует учитывать при проектировании приложений,которые получаютданные с реплик.

Чтобы «догнать» основной узел,реплике требуется: а) получить все изменения с него,б) записатьихвлокальноехранилище,в)синхронизироватьиг)воспроизвестинадлокальнойкопией данных. Используя вышеперечисленные поля с позициями журнала, можно вычислить расстояние в байтах между позициями и получить представление о том, в каком месте образоваласьнаибольшая задержка.Для этого потребуются уже известная функция pg_current_wal_lsn

иоператор вычитания,который поддерживается типом данных pg_lsn:

•pg_current_wal_lsn - sent_lsn — объем данных к отправке, который состоит из всех журнальных записей,накопленных на основном узле,но еще не переданных на реплику;

•sent_lsn - write_lsn—объем данных,отправленных с основного узла,но еще не записанных на стороне реплики;

•write_lsn - flush_lsn — объем данных, записанных, но еще не синхронизированных на реплике;

•flush_lsn - replay_lsn—объем данных,готовых для воспроизведения процессом startup.

Полученный объем выражается в байтах и позволяетдовольно наглядно представить масштабыотставанияреплик.Напрактикеотставаниечастовозникаетнаэтапеотправкииливоспро- изведенияжурнала.Частоэтопроисходитиз-затого,чтоврезультатеизменениябольшихобъ- емов данных генерируется много журнальных записей и процессы walsender или walreceiver не справляются с передачей или процессу startup не хватает производительности,чтобы своевременно воспроизводить весь объем журналов.

Следующая группа полей позволяет сразу отслеживать отставание в секундах,показывая приблизительное время,которое потребуется реплике,чтобы «догнать» основной узел:

•write_lag—время,прошедшее между локальной синхронизацией журнала и получением уведомления о том,что изменения записаны (но еще не синхронизированы) на реплике;

•flush_lag—время,прошедшее между локальной синхронизацией журнала и получением уведомления о том,что изменения записаны и синхронизированы на реплике;

•replay_lag—время,прошедшеемеждулокальнойсинхронизациейжурналаиполучением уведомления о том,что изменения записаны,синхронизированы и применены;

•reply_time — отметка времени о получении последнего служебного сообщения от реплики,в котором и содержатся данные по обработке журнала.

Данные поля позволяют оценить задержку, возникающую при подтверждении транзакции в случае синхронной репликации, когда параметр synchronous_commit установлен в одно из значений—remote_write,on или remote_apply.

Остаются еще два поля: sync_priority и sync_state. При асинхронной репликации sync_state всегда равно async. В случае синхронной репликации узлы могут находиться в разных состояниях и выполнять в кластере разные роли. Значение sync означает, что в данный момент реплика работает как синхронная.Если используется синхронная репликация,основанная на приоритетах, значение potential говорит о том, что реплика работает в асинхронном режиме, но является кандидатом на переход в синхронный режим (в этом случае sync_priority показывает приоритет данного узла). Если же используется синхронная репликация, основанная на кворуме, значение quorum означает, что реплика входит в минимально необходимое число узлов, подтвердивших получение изменений. Больше информации о настройке синхронной репликации можно получить из документации1.

1 postgrespro.ru/docs/postgrespro/15/runtime-config-replication#GUC-SYNCHRONOUS-STANDBY-NAMES

С точки зрения поиска и устранения проблем интересными являются поля с адресом,позициями обработки журнала и задержками,которые позволяютточно идентифицировать реплики (особенно если их несколько) и определить, на каких этапах обработки журнала возникают задержки.Поля с позициями журнала можно сразу преобразовать в величину задержек:

# SELECT client_addr, state,

pg_current_wal_lsn() - replay_lsn AS total_lag_bytes, pg_current_wal_lsn() - sent_lsn AS pending_bytes, sent_lsn - write_lsn AS write_lag_bytes,

write_lsn - flush_lsn AS flush_lag_bytes, flush_lsn - replay_lsn AS replay_lag_bytes, write_lag,

flush_lag, replay_lag

FROM pg_stat_replication;

Представление позволяет оценивать величину задержки как в байтах, так и в секундах, показывая, какой объем данных нужно обработать реплике, чтобы «догнать» основной узел,

искольковремениэтозаймет.Ввыводезапросавидно,чтоотставаниерепликинезначительно

исоставляетнесколькомикросекунд,вбайтахзадержкасоставляетвсегооколо17КБ,приэтом данные уже переданы и записаны на реплику,их осталосьтолько синхронизировать и воспроизвести.

На основе величин задержек можно собиратьметрики и строитьграфики,которые будутотображать отставание реплик во времени (рис. 7.1 и 7.2).

Обратите внимание на легенды обоих графиков. Отставание в байтах представлено более подробно и содержитинформацию об объеме журнала,который еще не был отправлен на реплику.Второй любопытный факт связан с тем,что в выбранный момент оба графика показывают разные максимумы отставания. Например, большая часть отставания в байтах находится на этапезаписиизменений,втовремякакотставаниевсекундах—уженаэтапахсинхронизации и воспроизведения. Особенно хорошо это заметно на небольших значениях. Общая картина обоих графиков показывает,что отставание часто появляется на этапах синхронизации и воспроизведения.Это говорит о том,что реплика чуть хуже справляется со своей частью работы.