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

Физическая репликация работает на уровне хранения: страница, смещение, байты. Логическая поднимается на уровень логической модели: таблица, строка, операция INSERT/UPDATE/DELETE.

Источник этих данных один и тот же - WAL. Но чтобы из журнала можно было восстановить «какая строка какой таблицы как изменилась», в него нужно дописать дополнительную информацию. Поэтому логическая репликация требует wal_level = logical - это больше, чем replica: в журнал кладётся достаточно, чтобы декодировать изменения строк, а не только повторить запись страниц.

publisher (wal_level=logical)          subscriber

┌────────────────────────┐            ┌──────────────────┐

│ WAL                     │           │ apply worker     │

│   ↓ logical decoding    │ ──строки──▶│   ↓             │

│ PUBLICATION (таблицы)   │           │ INSERT/UPDATE/   │

│                         │           │   DELETE локально │

└────────────────────────┘            └──────────────────┘

Смена уровня требует рестарта сервера: wal_level нельзя поменять на лету. Это первая практическая засада - архитектуру под логическую репликацию закладывают заранее.

Две стороны объявляются явно. Источник создаёт публикацию - набор таблиц, изменения которых он готов отдавать:

-- на источнике

CREATE PUBLICATION pub_flights FOR TABLE flights;

Приёмник создаёт подписку - подключение к источнику и ссылку на публикацию:

-- на приёмнике; таблица flights уже должна существовать структурно

CREATE SUBSCRIPTION sub_flights

  CONNECTION 'host=primary dbname=lab user=rep password=...'

  PUBLICATION pub_flights;

При создании подписки по умолчанию идёт начальная копия данных (copy_data = true), а затем поток догоняющих изменений. Под каждую подписку источник заводит логический слот репликации - тот же механизм удержания WAL, что в физической репликации, со всеми его рисками (забытый слот копит журнал).

Прогресс видно с обеих сторон: pg_stat_subscription на приёмнике, pg_replication_slots и pg_stat_replication на источнике.

Чтобы реплицировать UPDATE или DELETE, приёмнику надо понять, какую строку менять. Эту роль играет replica identity - набор колонок, однозначно определяющий строку. По умолчанию это первичный ключ.

ALTER TABLE flights REPLICA IDENTITY FULL;  -- если нет PK: вся строка как ключ

У таблицы без первичного ключа и без явно заданной replica identity INSERT реплицируется, а UPDATE и DELETE - нет (источнику нечем опознать строку). Это тихая потеря изменений, которую легко не заметить, пока данные на сторонах не разойдутся.

Здесь живёт большинство сюрпризов. Логическая репликация везёт DML по перечисленным таблицам - и почти ничего сверх этого. Запомни этот список, он спасает от ночных инцидентов:

• DDL не реплицируется. ALTER TABLE ... ADD COLUMN на источнике не доедет. Добавишь колонку только на источнике - apply на приёмнике встанет, не найдя её. Схему меняют согласованно руками на обеих сторонах.
• Последовательности не синхронизируются. Значение serial / identity на приёмнике живёт своей жизнью. После переключения на приёмник легко словить конфликт первичного ключа: новая вставка возьмёт значение, которое уже занято реплицированными строками.
• TRUNCATE едет, только если он явно включён в публикацию.
• Объекты вне таблиц (последовательности как объекты, представления, функции) логическая репликация не переносит.

Правило простое: логическая репликация - про строки конкретных таблиц, а не про «всю базу целиком». Всё остальное - твоя забота.

Приёмник - самостоятельный кластер, и он принимает запись не только от репликации, но и от своих клиентов. Это создаёт конфликты, которых в физической репликации быть не может (там standby не пишет вообще).

Прилетела реплицированная вставка с ключом, который на приёмнике уже занят локальной строкой - apply-воркер не может её применить и останавливается. Репликация по этой подписке встаёт целиком, пока конфликт не разрешат вручную: либо убрать мешающую строку, либо пропустить проблемную транзакцию. В логе приёмника - ошибка нарушения уникальности с указанием подписки.

Ключевое отличие от физической репликации: там standby не может «не суметь» применить журнал, он всегда повторяет байты. Здесь apply выполняет настоящие SQL-операции, и любая из них может упереться в локальное состояние.

Логическую репликацию легко настроить в обе стороны: пусть оба сервера и публикуют, и подписываются друг на друга, и пишем в любой. На демонстрации это работает и выглядит как бесплатный multi-master.

В проде оно ломается на первом конфликте. Два узла независимо выдали одинаковый id разным строкам (последовательности-то не общие) - apply встал на нарушении ключа. Одну строку обновили на обоих узлах сразу - встроенного разрешения «кто прав» у PostgreSQL нет, репликация по подписке остановилась. Без аккуратной настройки origin изменение ходит по кругу.

Вывод не «нельзя», а «это полноценная распределённая система со своей политикой разрешения конфликтов, а не галочка в конфиге». Настоящий multi-master берут отдельным решением. Подробный разбор - в главе про распределённые ловушки и в distributed-pitfalls.

Два механизма решают разные задачи, и выбор почти всегда однозначен, если задать правильный вопрос.

Бери физическую, когда нужна точная копия всего кластера: горячий резерв на failover, разгрузка чтения на полную копию, простой надёжный HA. Одна версия, всё или ничего, минимум сюрпризов.

Бери логическую, когда нужна гибкость хранения:

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

Если слышишь «нам нужна копия ради надёжности» - это физическая. Если «нам нужно перелить вот эти таблицы вон туда, возможно в другую версию» - логическая. Про сам журнал, из которого оба механизма берут изменения - глава о потоковой репликации и streaming-replication.