Failover logical slots в PostgreSQL 17: что меняется для высокой доступности логической репликации

Логическая репликация удобна для аналитики, CDC и синхронизации между регионами. Но как только срабатывает автоматическое переключение на standby, потребитель репликации теряет слот и перестаёт получать изменения. В PostgreSQL 17 эту проблему решают на уровне ядра: в нём появились failover logical slots — логические слоты, способные пережить promotion физической реплики.

Разберём, как устроен механизм, что нужно настроить для надёжной работы и какие ограничения остаются.

Проблема: что ломается с логической репликацией при failover до PostgreSQL 17

Как работают логические слоты на primary

Логический replication slot на мастере хранит позицию чтения в WAL. Потребитель подключается к primary и последовательно считывает изменения. Пока primary жив, слот гарантирует, что сервер не удалит WAL‑сегменты, ещё не обработанные подписчиком.

Почему после переключения на standby слот теряется

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

Типичные обходные решения и их цена

До появления failover‑слотов применяли два подхода: повторное создание слота с пересъёмом всех данных заново или внешние инструменты, отслеживающие позицию LSN и вручную корректирующие слот после аварии. Оба варианта увеличивали время восстановления и создавали риск потери согласованности. Для CDC‑конвейеров это означало ручные вмешательства и долгие простои.

Что такое failover logical slots в PostgreSQL 17

Параметр failover при создании слота

Теперь при вызове pg_create_logical_replication_slot можно указать дополнительный аргумент failover. Если он установлен в true, сервер помечает слот как способный к переключению. Именно такие слоты синхронизируются с физическими репликами.

Серверный параметр sync_replication_slots

Ключевой переключатель версии 17 — sync_replication_slots. Когда на primary и standby он выставлен в on, запускается slot sync worker — фоновый процесс, который регулярно забирает с мастера метаданные failover‑слотов и поддерживает их локальные копии в согласованном состоянии.

Slotsync worker: как синхронизируются метаданные и позиции LSN

Worker подключается к primary через стандартный протокол репликации, запрашивает список failover‑слотов и их LSN‑позиции. Если слот отсутствует на standby, он создаётся; если существует — обновляется. Благодаря этому после promotion потребитель продолжает чтение ровно с той же позиции, на которой остановился. Полная перезагрузка данных не требуется.

Что нужно настроить для работы failover‑слотов

Обязательные условия на standby

Failover‑слоты работают только в связке с физической streaming‑репликацией. Минимальный набор параметров на standby:

• primary_slot_name — имя физического слота, через который реплика получает WAL с primary. Без него слот‑синхронизация не сможет удерживать нужную позицию.
• hot_standby_feedback = on — сообщает мастеру о старейших активных транзакциях на standby, предотвращая преждевременную очистку строк.
• sync_replication_slots = on — запускает сам механизм синхронизации.

Дополнительные параметры для защиты от «обгона» standby

Чтобы логический потребитель не потреблял WAL быстрее, чем физическая реплика успевает его доставить, PostgreSQL 17 предлагает настройки, ограничивающие продвижение слота. Суть проста: primary не даст failover‑слоту уйти вперёд дальше, чем это разрешено для указанных физических слотов. Так исключается ситуация, при которой после failover на standby отсутствует часть WAL‑сегментов.

Особенности primary_conninfo на реплике

primary_conninfo на standby должен содержать корректную строку подключения, включая dbname. Это нужно, чтобы slot sync worker мог аутентифицироваться и запрашивать данные с primary. Без правильно указанного имени базы синхронизация не стартует.

Как проверить, что слот синхронизирован

Представление pg_replication_slots на standby теперь содержит атрибуты, показывающие, какие слоты являются failover и синхронизированы для безопасного переключения. Выполните запрос на реплике и убедитесь, что интересующий слот присутствует, а его флаги соответствуют ожиданиям.

Что это меняет для HA‑архитектуры

Логическая репликация без потерь при смене мастера

Главное последствие: promotion standby больше не требует ручного восстановления логических слотов. Потребитель переподключается к новому primary, находит failover‑слот и продолжает чтение без пропусков. Риск дублирования или потерь при правильной настройке сводится к минимуму.

Поведение CDC‑инструментов

Инструменты вроде Debezium или Kafka Connect, использующие плагин pgoutput, могут прозрачно пережить переключение. Достаточно корректной конфигурации кластера — дополнительной логики внутри коннектора не требуется.

Ограничения: работа только с физическими streaming‑репликами

Failover‑слоты синхронизируются исключительно на физические standby. Логические реплики и каскадные схемы в этом механизме не участвуют. Если архитектура предполагает несколько уровней репликации, failover‑слоты разворачивают непосредственно на узлах, которые могут стать новым primary.

Облачные управляемые сервисы

В некоторых облачных сервисах, например Azure Database for PostgreSQL 17+, поддержка failover‑слотов реализована нативно. При включении sync_replication_slots и hot_standby_feedback логические слоты автоматически синхронизируются между узлами в рамках HA‑конфигурации. Информацию о поддержке в AWS RDS или Google Cloud SQL на момент написания стоит уточнять в документации провайдеров.

Практические соображения и подводные камни

Влияние на задержку доставки WAL

Slot sync worker создаёт дополнительный сетевой обмен между standby и primary. По предварительным данным, накладные расходы должны оставаться умеренными, однако на высоконагруженных системах стоит закладывать небольшой прирост нагрузки на сеть и CPU.

Обратная совместимость при переходе с PG16 на PG17

Failover‑слоты — функция только семнадцатой версии. При апгрейде через pg_upgrade старые логические слоты не становятся failover автоматически. Их придётся пересоздать с флагом failover = true уже после перехода. Сам процесс миграции планируйте с учётом того, что sync_replication_slots нужно включить и протестировать в новом окружении до того, как полагаться на него в продакшене.

Мониторинг и алертинг

В pg_stat_replication и pg_replication_slots на обоих узлах появляются новые индикаторы. Мониторинг должен отслеживать:

• присутствие failover‑слотов на standby и актуальную позицию LSN;
• состояние slot sync worker — нет ли отставаний;
• корректность hot_standby_feedback и отсутствие конфликтов очистки.

Рекомендуется добавить алерты на случай, если синхронизация слотов прервётся дольше заданного порога.

FAQ

1. Что такое failover слот в PostgreSQL 17?
Логический replication slot, созданный с параметром failover = true. Его метаданные и позиция LSN автоматически синхронизируются между primary и физической репликой.

2. Чем он отличается от обычного логического слота?
Обычный слот существует только на узле, где создан, и исчезает при failover. Failover‑слот «живёт» сразу на primary и standby, сохраняя непрерывность позиции.

3. Обязан ли я включать sync_replication_slots на primary?
Да, параметр должен быть включён как на primary, так и на standby, чтобы синхронизация запустилась.

4. Работает ли failover слот с логической репликой?
Нет. Механизм рассчитан исключительно на физические streaming‑реплики.

5. Какие минимальные параметры нужны на standby?
primary_conninfo (включая dbname), primary_slot_name, hot_standby_feedback = on и sync_replication_slots = on.

6. Можно ли превратить существующий слот в failover‑слот?
Нет. Нужно создать новый слот с failover = true и перенастроить потребителя.

7. Что будет, если hot_standby_feedback выключен, а sync_replication_slots включён?
Синхронизация формально может работать, но без обратной связи standby не удержит старые версии строк, что приведёт к конфликтам очистки и возможным сбоям после failover.

8. Поддерживают ли облачные сервисы эту функцию?
Azure Database for PostgreSQL 17+ поддерживает нативно. По другим провайдерам уточняйте в официальной документации.

Вывод

PostgreSQL 17 закрывает давний пробел в логической репликации. Теперь при переключении на физическую реплику потребитель не теряет слот и продолжает чтение без пересъёма данных. Ключевые элементы: флаг failover, параметр sync_replication_slots и фоновый slot sync worker.

Для корректной работы нужна внимательная настройка физической репликации: обязательное включение hot_standby_feedback, правильный primary_conninfo и тестирование поведения при failover до ввода в эксплуатацию. Если вы строите HA‑архитектуру с логической репликацией на PostgreSQL 17, эту возможность стоит включать по умолчанию.

Источники

• Failover Logical Slots - Ensuring High Availability of Logical ...
• Failover Replication Slots with Postgres 17
• Setting Up Failover Slots in PostgreSQL-17
• PostgreSQL 17 Logical Replication: Failover Slots and Row Filtering
• PGConf India 2025: Failover Slots in PostgreSQL-17: by Nisha Moond from Fujitsu
• PostgreSQL: Documentation: 17: E.11. Release 17