repmgr
Тема дорожной карты · PostgreSQL
repmgr — инструмент управления репликацией с открытым исходным кодом для PostgreSQL, упрощающий настройку, мониторинг и управление переключением при сбое в кластерах потоковой репликации PostgreSQL. Он предоставляет набор команд — repmgr primary register, repmgr standby clone, repmgr standby follow — автоматизирующих многошаговый процесс настройки потоковой репликации между основным сервером и одним или несколькими резервными, снижая объём ручных операций администрирования. Демон repmgrd работает на каждом узле кластера, непрерывно отслеживая работоспособность репликации и автоматически повышая резервный сервер до основного при недоступности последнего; настраиваемый узел-свидетель позволяет избежать сценария разделённого мозга. repmgr записывает топологию кластера и историю событий в выделенную схему repmgr внутри PostgreSQL, упрощая аудит событий переключения при сбое и проверку текущего статуса резервных серверов. Для администраторов баз данных, управляющих высокодоступными кластерами PostgreSQL без полноценной платформы оркестрации, repmgr предоставляет проверенное временем лёгковесное решение для управления репликацией и переключением при сбое.
Как это работает
repmgr копирует данные с 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 до того, как он понадобится.
Типичные ошибки
Ловушки repmgr: расчёт "реплика = бекап" (DELETE на primary мгновенно реплицируется — бекапы + PITR отдельно); replication lag тихо растёт (нет мониторинга); нет автоматического failover (ручной MTTR = часы); реплика отстала слишком сильно, не догоняет (пересборка с нуля). Patroni или managed-предложение; своя HA — долгий путь боли.