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

Если реплика PostgreSQL отстаёт, переключение на неё может вернуть старые данные; если оба сервера примут записи после сбоя, получится конфликтующая история. Поэтому совет «просто добавьте реплику» не отвечает на главные вопросы: какую именно настроить, какую потерю данных считать допустимой и кто будет переключать узлы. Ниже — практический выбор для PostgreSQL 16, без обещаний, что репликация сама решит задачи резервного копирования и отказоустойчивости.

Сначала решите, что должна делать реплика

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

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

Физическая репликация передаёт изменения журнала WAL и поддерживает копию всего кластера PostgreSQL. Логическая передаёт изменения выбранных таблиц через публикации и подписки. Это не два взаимозаменяемых переключателя: у каждого способа свои ограничения и своя цена.

Три практических варианта

Асинхронная физическая репликация — обычная отправная точка, если приоритетом стали чтение или дополнительная копия. Синхронную выбирайте не по принципу «надёжнее значит лучше», а после оценки поведения приложения при недоступной реплике. Логическая оправдана, когда действительно нужны выборочный набор таблиц или гибкость на уровне публикаций и подписок.

Реплика отвечает на вопрос, как передать изменения. Резервная копия отвечает на другой вопрос: как восстановиться, если данные уже испорчены или удалены.

Что проверить до запуска

Сверьте версии PostgreSQL на узлах, сетевой доступ, место под данные и требования к совместимости. В PostgreSQL 16 параметры и поведение стоит проверять именно по документации этой версии: для другой основной версии возможны отличия. Отдельно решите, кто имеет право подключаться к реплике, как защищено соединение и где хранятся резервные копии.

• Запишите допустимую потерю данных. Не «почти ноль», а требование бизнеса: какие операции и за какой промежуток времени можно потерять после аварии.
• Проверьте пропускную способность. При высокой нагрузке на запись передача и применение WAL могут отставать. Сеть и диск реплики должны выдерживать поток изменений, а не только обычные запросы на чтение.
• Продумайте отказ и возврат узла. Кто обнаруживает сбой, кто разрешает запись на новом основном сервере и как исключается ситуация, когда оба узла считают себя основными?
• Зафиксируйте ограничение чтения. Приложению, которому сразу после записи нужен актуальный результат, чтение с отстающей реплики может вернуть старое состояние.

Термин: WAL (Write-Ahead Log) — журнал предварительной записи. PostgreSQL фиксирует изменения в WAL, а физическая реплика применяет переданные записи журнала, чтобы поддерживать копию кластера.

Настройте наблюдение, а не только передачу

Статус «соединение установлено» не означает, что реплика успевает за основным сервером. В PostgreSQL 16 проверяйте состояние отправителя через представление pg_stat_replication, а на реплике — приём WAL через pg_stat_wal_receiver. Для оценки задержки смотрите, поступают ли и применяются ли изменения; сравнивайте позиции WAL и учитывайте, что простой перевод разницы в байтах в секунды не всегда показывает реальную свежесть данных.

Следите за нагрузкой на диски и сеть, задержкой применения WAL, состоянием соединения и свободным местом на узлах. Важен и рост журнала, который ещё не может быть удалён. Слоты репликации удерживают WAL, нужный потребителю; если потребитель надолго остановился, место может закончиться. В PostgreSQL 16 для ограничения удержания WAL слотом существует параметр max_slot_wal_keep_size, но его значение выбирают с учётом допустимого отставания: жёсткий предел может привести к тому, что отставший потребитель придётся восстанавливать заново.

Где репликация ломает ожидания

Чтение не всегда свежее

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

Синхронность меняет доступность записи

Синхронный режим не бесплатен: при проблемах со связью подтверждение записи может задерживаться или зависеть от доступности выбранной реплики. Проверьте поведение именно приложения и драйвера при такой ситуации, а не только успешный тест в исправной сети. Уточните, какой режим подтверждения требуется: «синхронная репликация» не означает автоматически, что запрос уже применён и доступен для чтения на другом узле.

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

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

Реплика — не резервная копия

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

Когда что выбирать

• Нужны полная копия и возможность направлять на неё часть чтений — начните с физической асинхронной репликации; измерьте отставание под реальной записью.
• Потеря подтверждённых транзакций недопустима в рамках заданных требований — оцените синхронную физическую репликацию вместе с последствиями отказа реплики и сети.
• Нужны только отдельные таблицы или передача данных в другую систему — рассматривайте логическую репликацию, заранее включив в план схему, начальную загрузку и последовательности.
• Нужно автоматически переключать узлы — добавьте отдельно спроектированное управление отказом и защиту от одновременной записи на два основных сервера. Сам факт наличия реплики этого не обеспечивает.

Что делать дальше

Начните не с настройки параметров, а с короткого испытания на копии вашего приложения: выполните типичную нагрузку на запись, измерьте отставание, затем отключите сеть или реплику и проверьте поведение записи и чтения. Отдельно проведите переключение и восстановление из резервной копии. Зафиксируйте результаты и критерии допустимого сбоя; только после этого выбирайте режим и переносите схему в продакшен.