Архитектура
Эта страница переведена при помощи нейросети GigaChat.
Логическая репликация начинается с копирования снимка данных в базе данных издателя. Как только это будет сделано, изменения на издателе будут отправляться подписчику по мере их возникновения в реальном времени. Подписчик применяет данные в том порядке, в котором были сделаны фиксации на издателе, так что гарантируется транзакционная согласованность для публикаций в рамках одной подписки.
Логическая репликация построена с архитектурой, аналогичной физической потоковой репликации (подробнее смотрите раздел «Трансляция журналов на резервные серверы»). Она реализована процессами «walsender» (передачи WAL) и «apply» (применения). Процесс walsender запускает логическую декодировку WAL и загружает стандартный плагин логической декодировки (pgoutput). Плагин преобразует изменения, прочитанные из WAL, в протокол логической репликации (подробнее смотрите раздел «Протокол логической потоковой репликации»), и фильтрует данные в соответствии со спецификацией публикации. Затем данные непрерывно передаются по протоколу потоковой репликации рабочему процессу apply, который сопоставляет данные с локальными таблицами и применяет отдельные изменения по мере их получения в правильном транзакционном порядке.
Процесс применения на базе данных подписчика всегда выполняется с установленным значением session_replication_role равным replica. Это означает, что по умолчанию триггеры и правила не будут срабатывать у подписчика. Пользователи могут дополнительно выбрать включение триггеров и правил для таблицы, используя команду ALTER TABLE и предложения ENABLE TRIGGER и ENABLE RULE.
Процесс логического реплицирования применяет только триггеры уровня строки, а не операторы. Однако начальная синхронизация таблиц реализована аналогично команде COPY и поэтому вызывает как триггеры уровня строки, так и операторов для INSERT.
Начальный снимок
Исходные данные в существующих таблицах, на которые оформлена подписка, создаются в виде моментальных снимков и копируются параллельно в рамках специального процесса применения. Эти специальные процессы применения представляют собой выделенные рабочие процессы синхронизации таблиц, запускаемые для каждой синхронизируемой таблицы. Каждый процесс синхронизации таблицы создает свой собственный слот репликации и копирует существующие данные. Как только копирование завершится, содержимое таблицы станет доступно другим бэкэндам. После копирования существующих данных рабочий процесс переходит в режим синхронизации, который обеспечивает приведение таблицы в синхронизированное состояние с основным процессом применения путем потоковой передачи любых изменений, произошедших во время первоначального копирования данных, с использованием стандартной логической репликации. В течение этой фазы синхронизации изменения применяются и фиксируются в том же порядке, в котором они произошли на издателе. После завершения синхронизации управление репликацией таблицы возвращается основному процессу применения, где репликация продолжается в обычном режиме.
Параметр публикации влияет только на то, какие операции DML будут реплицированы. Начальная синхронизация данных не учитывает этот параметр при копировании существующих данных таблицы.
Если во время копирования происходит сбой в работе обработчика синхронизации таблиц, обработчик применения обнаруживает сбой и перезапускает обработчик синхронизации таблиц для продолжения процесса синхронизации. Такое поведение гарантирует, что временные ошибки не приведут к необратимому нарушению настройки репликации.