Failover
Тема дорожной карты · PostgreSQL
Повышение резервного сервера в PostgreSQL — процесс преобразования резервного сервера потоковой репликации в новый основной; это ключевая операция в любом сценарии переключения при сбое, когда основной сервер становится недоступен. В PostgreSQL 12 и новее резервный сервер идентифицируется наличием файла standby.signal в каталоге данных; выполнение pg_ctl promote или вызов SELECT pg_promote() удаляет этот файл и заставляет резервный сервер завершить воспроизведение WAL и открыться для соединений на чтение-запись. Автоматическое переключение при сбое — когда демон мониторинга обнаруживает сбой основного сервера и запускает повышение резервного без ручного вмешательства — обеспечивается инструментами repmgr, Patroni или pgpool-II, являющимися стандартными компонентами высокодоступного администрирования баз данных PostgreSQL. После повышения бывшие резервные серверы должны быть перенастроены для следования новому основному с использованием pg_rewind (для эффективной ресинхронизации с хронологией нового основного) и обновлённых параметров primary_conninfo. Планирование и регулярное тестирование процедур повышения резервного сервера — включая переключение DNS или балансировщика нагрузки — является критически важной дисциплиной администрирования баз данных для минимизации целевого времени восстановления в продуктивных средах PostgreSQL.
Как это работает
Failover копирует данные с primary на одну или несколько реплик. У Postgres есть streaming replication (WAL-записи по сети, обычно sub-second lag), logical replication (publish/subscribe на уровне таблицы, кросс-версионно, меньше фич). Реплики могут быть read-only "hot standby", обслуживая чтения; асинхронные (быстрые, можно потерять последние секунды при failover) или синхронные (zero data loss, медленнее запись). Инструменты: Patroni для HA-оркестрации, pgBackRest для бекапа + restore-as-replica.
Когда применять
Минимум одну streaming-реплику для любой production БД — служит failover-таргетом и местом для read-heavy запросов вне primary. Синхронная репликация — для финансовых/критичных данных, готовых обменять ~10ms write latency на zero data loss. Logical replication — для cross-version обновлений или выборочной репликации таблиц. Тестируйте failover до того, как он понадобится.
Типичные ошибки
Ловушки Failover: расчёт "реплика = бекап" (DELETE на primary мгновенно реплицируется — бекапы + PITR отдельно); replication lag тихо растёт (нет мониторинга); нет автоматического failover (ручной MTTR = часы); реплика отстала слишком сильно, не догоняет (пересборка с нуля). Patroni или managed-предложение; своя HA — долгий путь боли.