Логическая и физическая репликация — два принципиально разных инструмента. Физическая копирует байты и даёт точное посекторное зеркало. Логическая пересылает изменения строк, позволяя выходить далеко за рамки простого клонирования инстанса. Вопрос не в том, какой способ «лучше вообще», а в том, какой закрывает конкретную задачу. Давайте разберём, в каких сценариях гибкость логической репликации перевешивает простоту физической, и где логика становится безальтернативной.
Чем логическая репликация отличается от физической на уровне механизма
Чтобы понять, когда логика побеждает, нужно чётко представлять, что происходит под капотом. Обе технологии используют один и тот же журнал упреждающей записи (WAL), но распоряжаются им по-разному.
Что делает физическая репликация: побайтовое копирование WAL
Физическая (streaming) репликация передаёт WAL-сегменты на реплику в бинарном виде. Реплика применяет их побайтово, воссоздавая точную копию первичного сервера на уровне файлов данных. Это означает полное совпадение: те же табличные пространства, та же структура страниц, те же внутренние идентификаторы. Реплика становится «standby» — её можно использовать только для чтения, и она бинарно совместима с мастером. Малейшее расхождение в версии СУБД, архитектуре процессора или операционной системе ломает весь механизм.
Что делает логическая репликация: декодирование WAL в изменения строк
Логическая репликация берёт WAL и прогоняет его через логический декодер. На выходе получается не набор байтов, а поток операций над строками: вставка, обновление, удаление. При этом учитывается репликационная идентичность (обычно первичный ключ) — именно по ней определяется, какую строку нужно изменить на подписчике. Такой подход разрывает жёсткую связь с физическим форматом хранения. Подписчик сам решает, как именно применить изменение, и хранить данные он может совершенно иначе. Главное — корректно передать логику модификации.
Почему разница в механизме определяет сценарии использования
Из побайтового копирования вытекает зеркало «один в один»: идеально для аварийного восстановления и распределения нагрузки на чтение. Но при этом нельзя обновить мажорную версию без полного пересоздания реплики, нельзя выбрать только часть таблиц, нельзя перенести данные на другую платформу.
Декодирование в строки ломает зеркальность, но взамен даёт массу свободы. Можно реплицировать только нужные таблицы, переходить между разными версиями PostgreSQL, комбинировать Linux и Windows в одной связке и строить сложные топологии, где подписчик сам является источником данных для кого-то ещё. Всё, что завязано на гибкость и избирательность — вотчина логической репликации.
Гибкость, которой нет у физической репликации
Три свойства логической репликации напрямую вытекают из её модели «издатель–подписчик» и полностью меняют картину по сравнению с физической.
Избирательная репликация: только нужные таблицы, только нужные данные
Физическая репликация тащит за собой весь кластер целиком — каждую таблицу, каждый индекс, каждую системную каталожную запись. Логическая позволяет создать публикацию, в которую вы включаете ровно те таблицы, которые нужны подписчику. Например, в аналитическом контуре можно оставить только факты продаж, а в микросервисном окружении — только справочники. На подписчике допустимы свои индексы, свои права доступа и дополнительные столбцы, не участвующие в репликации. Вы не тащите мусор и не плодите ненужную нагрузку.
Кросс-версионность и кроссплатформенность: репликация между разными мажорными версиями и ОС
Это самый сильный козырь логической репликации. Так как протокол оперирует логическими изменениями, а не бинарными структурами, больше не важно, что у мастера PostgreSQL 13 на CentOS, а у подписчика — PostgreSQL 16 на Ubuntu или даже Windows. Логическая репликация работает между разными мажорными версиями без каких-либо ухищрений. Именно этот механизм лежит в основе онлайн-обновлений с минимальным простоем. Физическая репликация на такое неспособна — она требует полной бинарной совместимости.
Модель «издатель–подписчик»: гибкие топологии, отсутствие жёсткой привязки к зеркалу
В физической репликации связь жёсткая: мастер и standby. Каскады возможны, но standby всегда остаётся копией мастера. Логическая репликация вводит понятия публикации (набор таблиц) и подписки (направленный запрос на получение изменений). Один сервер может быть издателем для десятка подписчиков, и одновременно подписчиком другой публикации. Это рождает топологии fan-out, где одна база рассылает изменения множеству потребителей. При этом подписчик не обязан быть «read-only» — он может вести свою собственную запись в локальные таблицы, что недоступно для физической реплики.
Конкретные ситуации, когда стоит выбрать логику, а не физику
Перейдём к практическим сценариям, где логическая репликация однозначно выигрывает.
Мажорное обновление PostgreSQL без останова (rolling upgrade)
Традиционный pg_upgrade требует полной остановки старого сервера на время конвертации данных. Логическая репликация превращает этот процесс в почти бесшовный. Разворачивается новый инстанс целевой версии. На старом создаётся публикация на нужные таблицы, на новом — подписка. Идёт начальная синхронизация и непрерывный поток изменений. Когда отставание сокращается до минимума, приложение коротко переключается на новый сервер, а старая подписка удаляется. Время простоя сокращается до секунд, необходимых для переключения, и не зависит от объёма базы. Это классический и рекомендуемый способ переезда на новую мажорную версию без длительного даунтайма.
Миграция между дата-центрами, облаками или платформами (Linux на Windows и обратно)
Переезжаете с on-premise на облако? У вас часть окружения на Linux, а разработческая песочница на Windows? Логическая репликация не замечает разницы. Можно поднять подписчика в любом совместимом окружении, натравить подписку на мастер, и данные потекут независимо от операционной системы, архитектуры и даже облачного провайдера. Это же спасает при смене аппаратной платформы или переносе в контейнерную среду без заморочек с бинарной совместимостью.
Частичная репликация: подписчик может иметь собственную структуру и даже запись
Представьте центральный офис с полной базой и филиалы, которым нужны только свои региональные данные. Логическая репликация позволяет создать публикацию с фильтром строк по таблице заказов, где region_id соответствует конкретному филиалу. Каждый филиал подписывается на свою порцию данных и может вести локальный учёт в собственных таблицах, не мешая центральному мастеру. Или другой сценарий: на подписчике-отчёте вы добавляете материализованные представления и свои агрегаты, которые никому не реплицируются. Физическая реплика на такое не способна — она обязана быть точной копией мастера.
Нулевое влияние на standby: когда нельзя трогать физическую реплику
Бывает, что физическая реплика уже выполняет важную роль: держит горячий резерв для аварийного переключения, работает под аналитическими запросами или является источником бэкапов. Вторгаться в этот тонко настроенный механизм ради миграции не хочется. Логическая репликация в этом смысле «паразитирует» на мастере через WAL, не трогая физические реплики вообще. Вы спокойно настраиваете публикацию, подписчик забирает изменения, а standby продолжают получать WAL в обычном режиме и не подозревают о существовании ещё одного потребителя. Риск сломать физическую репликацию нулевой.
О чём нельзя забывать, выбирая логическую репликацию
Логическая репликация мощна, но не всесильна. Есть несколько принципиальных ограничений, игнорируя которые легко получить неожиданные проблемы в production.
DDL не реплицируются — что это значит на практике
Команды изменения структуры (ALTER TABLE, CREATE INDEX и т.п.) не передаются через логический слот. Если вы добавили столбец на мастере, на подписчике придётся выполнить этот ALTER вручную. Новая таблица, созданная на мастере, не появится на подписчике сама, пока вы не добавите её в публикацию и не создадите вручную на целевой стороне. При активной разработке это означает необходимость синхронизации схем вне репликации — собственными скриптами или внешними инструментами управления миграциями.
Не все типы данных и операции попадают в поток (sequences, large objects)
Поток декодированного WAL передаёт вставки, обновления и удаления строк. Значения последовательностей (sequence) не реплицируются, потому что это не строки, а отдельные объекты. Если ваш подписчик должен генерировать собственные ключи из той же последовательности, будьте готовы к коллизиям. Также не реплицируются большие объекты (large objects) и изменения в некоторых системных каталогах. При планировании репликации стоит заранее проверить, все ли нужные сущности войдут в выбранную публикацию.
Потенциальный конфликт первичных ключей при частичной репликации
Если подписчик не только получает данные, но и вставляет свои, возможна ситуация, когда вставка на подписчике занимает первичный ключ, который через мгновение придёт от мастера. Результатом станет конфликт, и репликация для этой подписки встанет. Решений несколько: использовать разные диапазоны ключей для разных локаций, настраивать авторазрешение конфликтов или проектировать схему так, чтобы подписчик никогда не вставлял в ту же таблицу, которую реплицирует. Но сам факт того, что конфликт возможен, требует внимания на этапе проектирования.
Часто задаваемые вопросы о логической репликации
Можно ли использовать логическую репликацию для полного аварийного восстановления?
Нет. Логическая репликация не создаёт полной бинарной копии кластера: не переносит настройки, учётные записи, последовательности и системные объекты. Для disaster recovery по-прежнему нужна физическая реплика или выверенная стратегия резервного копирования.
Реплицируются ли изменения схем данных (DDL) автоматически?
Нет. DDL не попадают в логический поток. Все изменения структуры нужно применять на подписчике отдельно. При этом таблицы, участвующие в репликации, должны иметь одинаковую структуру строк (совпадающие столбцы) на обеих сторонах.
Поддерживается ли репликация только отдельных столбцов таблицы?
Нет. Логическая репликация реплицирует всю строку целиком, ориентируясь на репликационную идентичность. Фильтровать можно только на уровне целых таблиц, но не столбцов. Если какие-то столбцы нужно скрыть от подписчика, их стоит вынести в отдельную таблицу, которая не попадает в публикацию.
Что делать, если на подписчике уже есть данные с конфликтующими первичными ключами?
Конфликт вызовет ошибку и приостановит репликацию. Чтобы избежать этого, перед настройкой подписки нужно либо очистить соответствующие таблицы на подписчике, либо организовать непересекающиеся диапазоны ключей, либо использовать механизмы разрешения конфликтов, доступные в расширенных настройках. Но проще всего не допускать конфликтов на уровне схемы.
Насколько сильно логическая репликация нагружает мастер по сравнению с физической?
Логическое декодирование WAL требует дополнительных ресурсов CPU и памяти на мастере. При большом потоке изменений нагрузка может быть заметно выше, чем при простой пересылке WAL на физическую реплику. Точных универсальных цифр здесь нет — всё зависит от конкретной нагрузки и железа. Свежих сравнительных бенчмарков в открытом доступе на момент публикации не найдено, но по общему правилу логическая репликация более прожорлива.
Можно ли настроить логическую репликацию между разными версиями PostgreSQL без танцев с бубном?
Да, именно для этого она и создавалась. Достаточно, чтобы версии на обеих сторонах поддерживали логическую репликацию (начиная с PostgreSQL 10). Протокол обратно совместим: более старый мастер и более новый подписчик — типичный рабочий сценарий.
Подходит ли логическая репликация для передачи только изменений в реальном времени (CDC), без начальной синхронизации?
Да. При создании подписки можно указать, что начальная синхронизация таблиц (копирование существующих данных) не требуется. Тогда репликация начнёт передавать только изменения, произошедшие с момента создания слота. Это классический паттерн для интеграции с внешними системами, ожидающими только дельту.
Вывод
Логическая репликация — не замена физической, а её дополнение для случаев, где зеркало бессильно. Как только задача выходит за рамки «сделай точную копию для отказоустойчивости», логика становится инструментом выбора. Мажорные обновления без простоя, миграции между дата-центрами и платформами, избирательная синхронизация отдельных таблиц, построение хитроумных топологий — всё это требует модели «издатель–подписчик», а не побайтового копирования.
Однако сила гибкости оборотной стороной имеет ограничения: DDL не реплицируются, последовательности и большие объекты не передаются, а конфликты ключей на частично реплицируемых таблицах могут испортить жизнь. Взвешивая эти факторы, можно безошибочно выбрать ту репликацию, которая точно подходит под текущий архитектурный контекст. Если нужна простая устойчивость к сбоям — оставляйте физику. Если нужна свобода манёвра — используйте идеи из логической репликации. Она того стоит.
.svg.webp){kind=logo}
