Репликацию PostgreSQL на сервере: частые ошибки и решения

MAATRIX

Репликацию PostgreSQL на сервере настроить несложно, а вот эксплуатировать её без сюрпризов — отдельное умение. Ниже — разбор частых ошибок: реплика перестала подключаться, отставание растёт, слот репликации забивает диск WAL-логами, конфликт таймлайнов после промоута и опасность split-brain. Для каждой проблемы сначала решение, потом причина — чтобы починить быстро и не потерять данные. Это критично: ошибки репликации часто тихие и всплывают в худший момент, когда мастер уже упал.

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

В логе реплики появляется could not connect to the primary server или FATAL: password authentication failed for user "replicator". Репликация встала, потому что реплика не может достучаться до мастера. Проверьте по порядку. Первое — сеть и порт: с реплики выполните проверку доступности мастера по порту 5432. Второе — роль репликации: на мастере убедитесь, что роль replicator существует и имеет атрибут REPLICATION.

Третье, и самое частое, — pg_hba.conf на мастере. Для репликации нужна отдельная строка с базой replication, а не именем вашей базы:

host    replication   replicator   10.0.0.6/32   scram-sha-256

Если этой строки нет или адрес реплики не совпадает, мастер откажет в подключении. После правки перезагрузите конфигурацию мастера через sudo systemctl reload postgresql. Проверьте также метод аутентификации: если пароль был задан для md5, а стоит scram, переустановите пароль роли на мастере.

Отставание реплики растёт

Реплика подключена, но lag постоянно увеличивается — она не успевает за мастером. Сначала измерьте отставание на реплике:

sudo -u postgres psql -c "SELECT now() - pg_last_xact_replay_timestamp() AS lag;"

Причин у растущего отставания несколько. Первая — слабый диск на реплике: она физически не успевает применять журнал так же быстро, как мастер его генерирует. Здесь помогает только более быстрый SSD или менее нагруженный сервер под реплику. Вторая — тяжёлые долгие запросы на самой реплике: в режиме hot standby длинный SELECT может конфликтовать с применением WAL и тормозить его. Параметры max_standby_streaming_delay и hot_standby_feedback управляют этим компромиссом.

Третья причина — сетевая задержка или узкий канал между мастером и репликой, особенно если они в разных локациях на большом расстоянии. При интенсивной записи канал может не вытягивать поток WAL. Если отставание стабильно большое, это сигнал: либо реплике мало ресурсов, либо сеть между серверами слишком медленная для вашего объёма записи.

Слот репликации забивает диск на мастере

Внезапно на мастере кончается место, хотя данных вроде бы не прибавилось. Классическая причина — «мёртвый» слот репликации. Если реплика отключилась (упала, пересоздаётся, удалена), а слот на мастере остался, PostgreSQL продолжает копить WAL-сегменты, ожидая, что реплика их заберёт, — и так до заполнения диска. Проверьте слоты и их активность:

sudo -u postgres psql -c "SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained FROM pg_replication_slots;"

Колонка active = f и большое значение retained означают, что слот держит гору WAL, а реплика к нему не подключена. Чтобы эта ситуация не повторялась, можно ограничить максимальный объём WAL, который слот вправе удерживать, параметром max_slot_wal_keep_size на мастере: тогда при превышении лимита слот будет помечен недействительным, но диск останется цел, а мастер продолжит работу. Это разумная страховка на боевом мастере — потеря отставшей реплики менее болезненна, чем падение основного сервера из-за переполнения. Если реплика действительно мертва и не вернётся, удалите слот:

sudo -u postgres psql -c "SELECT pg_drop_replication_slot('replica1');"

После удаления мастер очистит накопленный WAL и место освободится. Это одна из самых частых причин ночных инцидентов «мастер лёг из-за переполнения диска», и лечится она за минуту, если знать, где смотреть. На будущее — мониторьте неактивные слоты.

Конфликт таймлайнов после промоута

После того как вы повысили реплику до мастера (promote), старая реплика или новый резерв не могут к ней подключиться, в логе — requested starting point is ahead или упоминание разных timeline. Дело в том, что промоут создаёт новую «линию времени» (timeline): бывшая реплика начала свою историю WAL, отличную от старого мастера. Другие серверы, которые следовали за старым мастером, теперь на другой ветке.

Правильное решение — пересоздать отставшие серверы как реплики нового мастера через pg_basebackup, чтобы они получили актуальную копию и правильный таймлайн. В простых схемах это самый надёжный путь. Инструменты вроде pg_rewind умеют «доворачивать» старый мастер до нового без полной пересборки, что экономит время на больших базах, но требуют аккуратности и включённого wal_log_hints или контрольных сумм. Для небольших баз проще пересоздать реплику заново.

Опасность split-brain

Самая опасная ситуация в репликации — split-brain, когда после аварии оба сервера считают себя мастером и оба принимают запись. Данные расходятся, и слить их обратно без потерь почти невозможно. Обычно это происходит так: мастер завис, вы повысили реплику, а потом старый мастер ожил и продолжил принимать запись от части приложений.

Правило простое и жёсткое: после промоута реплики старый мастер должен быть гарантированно выведен из работы — остановлен, отключён от приложений и пересоздан как реплика нового мастера, прежде чем снова принимать трафик. Никогда не допускайте, чтобы два сервера одновременно писали. Для автоматизации failover с защитой от split-brain существуют Patroni и repmgr — они используют распределённый консенсус и «ограждение» (fencing), чтобы старый мастер не мог вернуться в строй как писатель. Если репликация критична для бизнеса, такие инструменты оправданы.

Надёжная схема требует минимум двух серверов, желательно в разных локациях. В MAATRIX можно арендовать VPS под мастер и реплику PostgreSQL в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не требуется.

Частые вопросы