Механизм быстрой остановки системного процесса walsender логической репликации

Для минимизации временных затрат на обработку оставшихся после вызова pg_ctl stop WAL-записей в ядре postgres реализовано решение для быстрой остановки БД при активном логическом декодировании логического слота. Вводятся два параметра:

Параметр	Тип данных	Допустимые значения	Перезагрузка	Значение по умолчанию	Описание
fast_logical_walsender_stop	bool	false/true	Требуется reload	false	Если флаг в значении true, то используется быстрая остановка walsender для логической репликации. Если false, то ванильное поведение
fast_logical_walsender_stop_timeout	int	0s - 1000000s	Требуется reload	30s	Параметр, устанавливающий тайм-аут, по истечении которого walsender для логической репликации будет остановлен даже при оставшейся задержке к обработке. Активируется только если fast_logical_walsender_stop = true

В данной реализации, при выполнении команды pg_ctl stop процесс walsender будет отправлять оставшиеся WAL-записи в течение установленного тайм-аута (fast_logical_walsender_stop_timeout). Если по истечении этого времени отправка не завершена, репликация будет прервана, и walsender будет остановлен сигналом SIGTERM, который будет отправлен процессом checkpointer.

После перезапуска сервера процесс репликации восстановится с той позиции LSN, с которой он был прерван.

Сохранение слота логической репликации при управлении кластером

Позиция LSN, с которой необходимо возобновить логическое декодирование, сохраняется в слоте репликации. Также приложение может ее указывать в команде START_REPLICATION. Наибольшее из этих двух значений используется для начала логического декодирования.

Для возобновления репликации с той же позиции необходимо обеспечивать сохранность слота репликации.

В силу того, что позиция слота может отставать после переключения ролей кластера (на реплику слот синхронизируется с определенным интервалом Pangolin Manager), приложение должно понимать, какие декодированные транзакции оно уже приняло ранее.

Для обеспечения сохранности слота его следует описать в DCS-конфигурации Pangolin Manager (секции slots, ignore_slots). Тогда этот слот создается, управляется и синхронизируется на реплику самим Pangolin Manager, который обеспечивает сохранность слота в случае сбоев. В этом случае postgresql не удаляет WAL-файлы, для которых еще не было выполнено логическое декодирование.

Если слот неизвестен Pangolin Manager, то он может быть им удален, например, при рестарте кластера или выходе компонента из паузы.

Также слот может создаваться самим приложением с помощью команды CREATE_REPLICATION_SLOT. В этом случае приложение несет ответственность за управление слотом.

Перед использованием функциональности остановки процесса walsender логической репликации может потребоваться протестировать приложение на способность обрабатывать остановку логического декодирования со стороны сервера и зависимость от сохранности слота логической репликации.

В standalone-конфигурации без Pangolin Manager постоянный слот логической репликации не пропадет при рестарте postgresql.