Репликация PostgreSQL: потоковая или логическая

Сначала выберите, что именно должно копироваться

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

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

Что передаёт каждый механизм

Потоковая репликация доставляет WAL — журнал предварительной записи, куда PostgreSQL фиксирует изменения базы. Резервный сервер применяет эти записи и получает физическую копию кластера. В ней оказываются все базы и таблицы, а не только выбранные.

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

Потоковая репликация копирует состояние всего кластера. Логическая — выбранные изменения. Это не два режима одной и той же резервной копии: у них разные задачи и разные пробелы.

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

Сравнение по задачам и ограничениям

Потоковая: резервный узел целиком

На основном сервере для физической репликации нужен уровень WAL не ниже replica, настроенные слоты или достаточный запас WAL и разрешение на подключение репликационной роли в pg_hba.conf. На резервном сервере должны совпадать основная версия PostgreSQL и архитектурные условия, которые требует выбранный способ восстановления. Для копирования кластера часто используют pg_basebackup.

Пример команды для PostgreSQL 17. Запустите её от пользователя PostgreSQL, укажите пустой каталог данных и замените имена узла и роли своими. Ключ -R создаёт конфигурацию standby; пароль лучше передавать через защищённый файл паролей, а не вписывать в команду.

pg_basebackup -h PRIMARY_HOST -D STANDBY_DATA_DIR -U repl_user -P -R -X stream

Проверка после запуска — на основном сервере в представлении pg_stat_replication появляется соединение резервного узла. Состояние streaming означает, что WAL передаётся; это ещё не проверка автоматического переключения. Потоковая реплика сама по себе не выбирает новый primary и не решает, как приложение переключится на него.

Логическая: публикация и подписка

На издателе включите wal_level = logical и проверьте лимиты слотов и отправителей WAL. Изменение wal_level требует перезапуска PostgreSQL. Роль для подключения должна иметь необходимые права, в том числе доступ к таблицам при первоначальном копировании данных.

На издателе создайте публикацию для нужных таблиц:

CREATE PUBLICATION app_pub FOR TABLE public.orders, public.order_items;

На подписчике заранее создайте таблицы с совместимой схемой, затем оформите подписку. Замените параметры подключения на свои. Для пароля настройте защищённый файл паролей PostgreSQL, не добавляйте секрет в SQL-файл, историю команд или систему контроля версий.

CREATE SUBSCRIPTION app_sub
CONNECTION 'host=PRIMARY_HOST port=5432 dbname=app user=repl_user'
PUBLICATION app_pub;

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

Когда выбирать каждый вариант

• Нужен standby всего кластера для аварийного переключения. Выбирайте потоковую репликацию. Отдельно проектируйте мониторинг, процедуру promotion и переключение приложения.
• Нужны только отдельные таблицы. Выбирайте логическую: она не заставляет копировать весь кластер, но требует синхронизировать схему и контролировать слоты.
• Планируете миграцию на новую основную версию. Логическая репликация может помочь переносить изменения между кластерами, пока идёт переключение. Проверьте поддерживаемые комбинации версий, типы данных и порядок миграции в документации.
• Нужна резервная копия для восстановления удалённых или испорченных данных. Ни потоковая, ни логическая репликация не заменяет независимый бэкап: удаление или ошибочное обновление может попасть и на реплику.

Что ломается на практике

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

У логической репликации слабое место — согласованность структуры и запись на подписчике. Изменения схемы сами не распространяются, а локальные записи могут конфликтовать с входящими изменениями. Не используйте подписчик одновременно как независимый источник записи без продуманной архитектуры разрешения конфликтов. Также проверьте, что ключи строк подходят для идентификации обновлений и удалений: для таблиц без подходящего первичного ключа может понадобиться настроить replica identity.

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

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

Сформулируйте, какие данные должны оказаться на принимающем сервере и для чего: восстановление всего кластера или выборочная доставка изменений. Затем поднимите тестовую реплику на тех же версиях и объёмах, которые планируете использовать, измерьте отставание при обычной и пиковой записи и проверьте восстановление после длительного разрыва связи. Для логической репликации отдельно отработайте изменение схемы; для потоковой — переключение на standby. Это покажет цену выбранного варианта до того, как за неё придётся платить в проде.