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