Когда говорят «репликация PostgreSQL», в одной фразе часто смешивают два разных механизма: streaming replication (физическая репликация на уровне WAL) и logical replication (логическая репликация на уровне изменений строк). Оба используют WAL, но «читают» и применяют его по-разному, дают разную гибкость и по-разному ведут себя при авариях и failover.
Ниже — практический разбор: как это устроено, где сильные стороны, что происходит с DDL, какие ограничения обычно всплывают в продакшне, и как выбирать механизм под HA, read scaling, миграции и CDC.
Коротко: в чём принципиальная разница
Streaming replication — физическая репликация: вторичный сервер получает поток WAL-записей и воспроизводит их, поддерживая практически идентичную копию всего кластера PostgreSQL. Реплика обычно работает как hot standby (чтение возможно, запись — нет).
Logical replication — логическая репликация: изменения передаются как операции над выбранными таблицами (INSERT/UPDATE/DELETE) из publication на источнике в subscription на приёмнике. Это удобнее для выборочной репликации и миграций с минимальным простоем.
Упрощённо: streaming replication «воспроизводит WAL как есть», а logical replication «передаёт смысл изменений строк» только для выбранных таблиц.
WAL: общий фундамент, но разные «потребители»
WAL (Write-Ahead Log) — журнал предзаписи, на котором держится надёжность PostgreSQL. Оба механизма репликации опираются на WAL, но используют его по-разному:
- Streaming replication забирает WAL сегментами и применяет его на реплике, получая физически согласованную копию всего кластера.
- Logical replication использует логическое декодирование (logical decoding): из WAL извлекаются логические изменения данных, которые применяются к таблицам подписчика.
Практическое следствие: streaming replication по умолчанию реплицирует «всё в кластере», а logical replication позволяет выбирать таблицы, но требует дисциплины вокруг схемы, ключей и режима записи на подписчике.
Streaming replication: как устроено и что даёт
Модель и варианты: async/sync
Streaming replication бывает асинхронной и синхронной:
- Async — primary подтверждает коммит, не дожидаясь реплики. Быстрее, но при аварии primary возможна потеря последних транзакций (RPO > 0).
- Sync — primary ждёт подтверждения от реплики (уровень ожидания зависит от настроек синхронной репликации). Медленнее, но снижает риск потери данных, вплоть до RPO 0 для выбранного стендбая.
На практике это влияет на дизайн failover: с async вы осознанно принимаете риск «последние секунды/минуты потерялись», а с sync — платите latency и должны продумать, что делать при падении синхронной реплики.
Failover и роль WAL-позиции
Streaming replication — базовый кирпич для HA: при падении primary вы продвигаете standby в primary (promote). Ключевой параметр — насколько реплика «догнала» primary по WAL, то есть какой у вас репликационный lag.
Важно: PostgreSQL не выполняет автоматический failover сам по себе. Обычно используют оркестратор (Patroni/repmgr и аналоги) или отлаженные ручные процедуры. Если вы проектируете отказоустойчивость, закладывайте не только репликацию, но и механизм выборов лидера, fencing и проверку split-brain.
Если вы разворачиваете PostgreSQL под репликацию на выделенных ресурсах, чаще удобнее использовать VDS с предсказуемыми IOPS и запасом по диску.
DDL, расширения, системные объекты
Физическая репликация воспроизводит всё, что попадает в WAL: DDL, изменения системных каталогов, создание индексов, эффекты VACUUM и т.д. В итоге primary и standby остаются структурно согласованными в рамках одного кластера.
Обратная сторона — гибкости мало: реплицируется весь кластер целиком, без «а вот эту таблицу не надо».
Типовые сценарии, где streaming replication выигрывает
- HA и быстрый failover для всего кластера.
- Read scaling: несколько read-only реплик под отчёты и фоновые запросы (с учётом лагов).
- Простота эксплуатации: меньше сущностей, нет публикаций/подписок, меньше шансов «логической несовместимости» схем.
Logical replication: publications, subscriptions и особенности применения
Базовые сущности
Логическая репликация строится вокруг двух объектов:
- Publication — набор таблиц и типов операций, изменения по которым будут публиковаться на источнике.
- Subscription — подписка на публикацию на приёмнике, которая забирает и применяет изменения.
Это даёт то, чего нет в streaming replication: выборочную репликацию и возможность собирать отдельные витрины данных без копирования всего кластера целиком.
Начальная синхронизация и догон
Обычно logical replication состоит из двух фаз:
- Initial sync — копирование текущего содержимого таблиц в подписчика.
- Catch-up — применение изменений, которые продолжают поступать через логическое декодирование WAL.
Для миграций это удобно: можно поднять новый кластер заранее, начать репликацию и переключить приложение, когда lag станет приемлемым.
DDL: главный источник сюрпризов
Критично помнить: DDL в logical replication не реплицируется автоматически. Сделали ALTER TABLE на источнике — подписчик сам об этом не «узнает», пока вы не примените изменения схемы отдельно.
Что из этого следует в продакшне:
- Нужен процесс управления схемой: миграции должны применяться согласованно на обеих сторонах.
- Любое расхождение схем быстро приводит к ошибкам применения изменений.
- При частой эволюции схемы операционная нагрузка заметно выше, чем у streaming replication.
Logical replication работает стабильно, когда у вас есть дисциплина: единый процесс миграций, контроль ключей и понятный режим записи на подписчике.
Ограничения, о которые чаще всего спотыкаются
Точные детали зависят от версии PostgreSQL и настроек, но типовые классы проблем повторяются:
- Уникальность для UPDATE/DELETE: подписчик должен однозначно находить строку. Обычно это означает первичный ключ или уникальный индекс (или явная настройка репликационной идентификации, если вы понимаете последствия).
- Конфликты данных: если подписчик не является «чистым приёмником» и вы пишете в те же таблицы локально, получаете расхождения и конфликтные сценарии. Это не мультимастер «из коробки».
- Последовательности: значения sequence часто требуют отдельной стратегии при миграциях и при активной записи, потому что это не «строки таблицы».
- Большие транзакции: способны создавать всплески задержки и раздувать очередь применения.
- Частичная репликация = частичная консистентность: если вы реплицируете не все таблицы, межтабличные инварианты на вашей стороне (особенно если приложение ожидает «всё как в primary»).
Failover в мире logical replication
Для классического HA logical replication обычно менее удобна:
- подписчик — не «полный клон» кластера, а выбранный набор таблиц;
- при переключении ролей нужно перестраивать publications/subscriptions, слоты и маршрутизацию записи;
- сложнее предсказуемо удерживать RPO/RTO, если подписчик нагружен аналитикой или тяжёлым применением изменений.
Использовать logical replication для аварийных сценариев можно, но чаще это «DR/миграционный» инструмент или способ построить специфическую топологию, а не замена физическому HA.
Когда переносите проекты между окружениями и нужен простой запуск без ручной возни с пакетами, часто выручает виртуальный хостинг для тестовых стендов и утилитной обвязки (документация, мониторинг, небольшие сервисы рядом).
Сравнение: что выбрать под задачу
Если цель — HA и прозрачный failover
В большинстве продакшн-сценариев логичнее начинать со streaming replication. Она воспроизводит весь кластер, спокойно «переваривает» DDL, а эксплуатация проще: контролируете lag, выбираете sync/async, отрабатываете promote.
Если у вас ещё и пул соединений, полезно держать под рукой отдельный гайд про режимы подключения и пулинг: настройка PgBouncer для PostgreSQL: режимы, пулы, типовые ошибки.
Если цель — миграция на новый кластер/версию с минимальным простоем
Здесь logical replication часто выигрывает, особенно когда вы хотите перенести только часть данных или сделать постепенное переключение. Но заранее заложите процесс синхронизации DDL и проверку ключей/уникальности.
Если цель — витрина данных, интеграции, CDC
Logical replication удобна, когда вам нужен управляемый поток изменений для части таблиц: витрина, отчётная база, отдельный контур для сервисов, которым нельзя давать прямой доступ к продакшн-кластеру.
Операционные нюансы: lag, слоты и рост диска
Независимо от выбранного подхода, инциденты обычно сводятся к трём вещам: задержка репликации, контроль WAL и последствия деградации сети/диска.
Lag: почему он появляется
- медленный диск на реплике (не успевает применять);
- узкое место по сети;
- всплеск записи на primary;
- длинные транзакции;
- в logical replication — медленное применение из-за индексов, триггеров и конфликтов.
Договоритесь внутри команды о SLO по RPO/RTO и мониторьте lag так же внимательно, как CPU и диск.
WAL retention и риск «забить диск»
У обоих механизмов есть сценарий, когда WAL удерживается дольше ожидаемого:
- в streaming replication — если реплика сильно отстала и primary держит WAL-сегменты, нужные ей для догонки;
- в logical replication — если подписчик не успевает, логический слот удерживает WAL, пока изменения не будут прочитаны и подтверждены.
Это один из самых частых продакшн-инцидентов: место заканчивается «внезапно». Планируйте запас по диску и мониторьте слоты/retention.
Мини-чек: что мониторить руками (и что быстро посмотреть)
Для первичной диагностики часто достаточно пары запросов.
SELECT slot_name, slot_type, active, restart_lsn, confirmed_flush_lsn
FROM pg_replication_slots
ORDER BY slot_name;SELECT pid, state, sync_state, client_addr, sent_lsn, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication
ORDER BY pid;Дальше уже разбирайтесь по ситуации: почему растёт lag, кто не читает слот, нет ли длинных транзакций, хватает ли IOPS, не упирается ли подписчик в индексы.
Практический чек-лист выбора
- Выбирайте streaming replication, если нужен понятный HA, минимум ручной возни с DDL и предсказуемый failover всего кластера.
- Выбирайте logical replication, если нужно выборочно реплицировать таблицы, делать миграции с минимальным простоем или строить витрины/интеграции.
- Комбинируйте, если архитектура сложная: физическая репликация для HA плюс логическая для витрин/сервисов.
Частые ошибки и как их избежать
Ошибка 1: ждать, что logical replication «сам реплицирует DDL»
Не реплицирует. Правило простое: любые изменения схемы — через управляемые миграции, применяемые на обеих сторонах в правильном порядке, с проверкой совместимости.
Ошибка 2: использовать logical replication как «простую замену» streaming replication для failover
Это разные инструменты. Логическая репликация может выручить в DR/миграции, но для быстрого поднятия standby как нового primary без сюрпризов физическая репликация обычно проще и надёжнее.
Ошибка 3: недооценить WAL и ёмкость диска
Удержание WAL из-за отставания реплик или слотов — классика. Планируйте запас, следите за lag, тестируйте деградацию сети и сценарии «подписчик умер на N часов».
Итог
Streaming replication — основной инструмент для HA и масштабирования чтения по модели «весь кластер как есть»: проще DDL, проще failover, меньше логических несостыковок, но нет выборочности.
Logical replication — инструмент гибкости: publications/subscriptions, выборочная репликация, миграции без длительного простоя, витрины и интеграции. Цена — дисциплина вокруг DDL, ключей, конфликтов и внимательное отношение к ограничениям.
Если вы проектируете переключение на уровне инфраструктуры (DNS/маршрутизация, переключение приложений, проверки доступности), полезно заранее продумать внешнюю схему: failover через GeoDNS и взвешенную маршрутизацию: рабочие варианты.
