Логическая репликация
Тема дорожной карты · PostgreSQL
Логическая репликация — функция PostgreSQL, реплицирующая отдельные изменения данных (INSERT, UPDATE, DELETE), декодируемые из WAL на логическом уровне, в отличие от физической (потоковой) репликации, копирующей необработанные двоичные WAL-сегменты. Логическая репликация в PostgreSQL использует модель публикация/подписка: издатель выполняет CREATE PUBLICATION my_pub FOR TABLE orders, users, а подписчик подключается командой CREATE SUBSCRIPTION my_sub CONNECTION '...' PUBLICATION my_pub, после чего реляционная база данных транслирует изменения на уровне строк в режиме реального времени. Поскольку логическая репликация работает на уровне DML, а не на уровне блоков, она обеспечивает избирательную репликацию таблиц, обновления между версиями (репликацию с PostgreSQL 15 на 16) и веерную рассылку в гетерогенные системы, например потребителям Kafka через выходные плагины pg_logical или pgoutput. Параметр wal_level должен быть установлен в logical, а max_replication_slots / max_wal_senders настроены соответствующим образом в postgresql.conf для поддержки логической репликации в продуктивной среде реляционной базы данных PostgreSQL.
Как это работает
Логическая репликация копирует данные с 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 до того, как он понадобится.
Типичные ошибки
Ловушки Логическая репликация: расчёт "реплика = бекап" (DELETE на primary мгновенно реплицируется — бекапы + PITR отдельно); replication lag тихо растёт (нет мониторинга); нет автоматического failover (ручной MTTR = часы); реплика отстала слишком сильно, не догоняет (пересборка с нуля). Patroni или managed-предложение; своя HA — долгий путь боли.