Чем отличаются streaming replication и logical replication? Когда что использовать?

Физическая (streaming) репликация

Streaming replication — побайтовая передача WAL-сегментов с мастера на реплику. Реплика воспроизводит те же страницы данных, что и мастер. Результат — точная физическая копия всего кластера, включая системные таблицы, роли и настройки.

Ключевые характеристики:

• Работает на уровне блоков/страниц, не строк.
• Реплика доступна только на чтение (hot standby) или вообще недоступна (warm standby).
• Реплицируется весь экземпляр PostgreSQL — нельзя выбрать отдельные таблицы или базы.
• Минимальная задержка: реплика отстаёт ровно настолько, насколько сеть позволяет передать WAL.
• Используется для аварийного переключения (failover) и read-реплик.

-- на мастере: создаём replication slot
SELECT pg_create_physical_replication_slot('replica1');

-- recovery.conf / postgresql.conf на реплике (Postgres 12+)
-- primary_conninfo = 'host=master port=5432 user=replicator password=...'
-- primary_slot_name = 'replica1'
-- hot_standby = on

Логическая репликация

Logical replication работает на уровне строк и операций (INSERT/UPDATE/DELETE). Мастер декодирует WAL через output plugin (pgoutput по умолчанию) и отправляет логический поток изменений подписчику.

Ключевые характеристики:

• Можно реплицировать отдельные таблицы, а не весь кластер.
• Подписчик может быть другой версии PostgreSQL (полезно при обновлениях).
• Подписчик остаётся полноценным read-write узлом — можно писать в нереплицируемые таблицы.
• Не реплицируются DDL-изменения, последовательности, большие объекты.
• Требует wal_level = logical на источнике.

-- на издателе (publisher)
ALTER SYSTEM SET wal_level = logical;
-- после перезапуска:
CREATE PUBLICATION my_pub FOR TABLE orders, products;

-- на подписчике (subscriber)
CREATE SUBSCRIPTION my_sub
  CONNECTION 'host=publisher dbname=mydb user=replicator password=...'
  PUBLICATION my_pub;

-- проверка состояния
SELECT * FROM pg_stat_subscription;

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

• Streaming replication — HA/failover, read-реплики для масштабирования чтения, резервное копирование через pg_basebackup. Минимальная задержка, максимальная надёжность.
• Logical replication — zero-downtime мажорные обновления PostgreSQL (10 -> 17), шардинг данных между кластерами, ETL без внешних инструментов, реплицирование подмножества таблиц в аналитическую БД, интеграция с Debezium/Kafka через CDC.
• Оба режима можно сочетать: streaming для HA, logical для аналитики.

Подводные камни

• Replication slots при streaming: если реплика надолго отключается, слот удерживает WAL-сегменты, что переполняет pg_wal и ронит мастер. Мониторьте pg_replication_slots.active и pg_wal_lsn_diff.
• wal_level = logical требует перезапуска кластера — нельзя применить через pg_reload_conf().
• Логическая репликация не переносит DDL: ALTER TABLE на мастере нужно вручную применять на подписчике до или одновременно с изменением схемы.
• Sequences не реплицируются логически — после failover возможны конфликты первичных ключей, если подписчик начинает генерировать ID.
• Большие транзакции при логической репликации буферизуются на диске подписчика (logical_decoding_work_mem), что замедляет применение.
• Фильтрация строк в PUBLICATION (WHERE-условие) работает только с Postgres 15+ — в более старых версиях нельзя частично реплицировать таблицу.
• hot_standby_feedback: при streaming, если не включить, долгие запросы на реплике могут получать ошибку «snapshot too old» при очистке мастером.

• Считать logical replication HA-заменой physical standby.
• Не мониторить replication slots.
• Забывать DDL и sequences при logical.

• Просит use cases для каждого режима.
• Проверяет WAL vs logical changes.
• Уточняет replica identity и lag.