30.7. Архитектура#
30.7. Архитектура
Логическая репликация начинается с копирования снимка данных на базе данных издателя. После этого изменения на издателе отправляются на подписчика по мере их возникновения в реальном времени. Подписчик применяет данные в порядке, в котором были сделаны коммиты на издателе, чтобы обеспечить транзакционную согласованность для публикаций в рамках любой отдельной подписки.
Логическая репликация построена с архитектурой, аналогичной физической
потоковой репликации (см. Раздел 26.2.5). Она
реализована процессами “walsender” и “apply”.
Процесс walsender запускает логическое декодирование (описано
в Глава 47) WAL и загружает стандартный
плагин вывода логического декодирования (pgoutput). Плагин
преобразует изменения, прочитанные
из WAL, в протокол логической репликации
(см. Раздел 53.5) и фильтрует данные
в соответствии со спецификацией публикации. Затем данные непрерывно
передаются с использованием протокола потоковой репликации рабочему процессу apply,
который сопоставляет данные с локальными таблицами и применяет отдельные изменения по мере их
получения, в правильном транзакционном порядке.
Процесс применения на подписной базе данных всегда выполняется с
session_replication_role
установленным в replica. Это означает, что по умолчанию
триггеры и правила не будут срабатывать на подписчике. Пользователи могут по желанию включить
триггеры и правила на таблице с помощью команды
ALTER TABLE
и предложений ENABLE TRIGGER и ENABLE RULE.
Процесс применения логической репликации в настоящее время запускает только триггеры строк, а не триггеры операторов. Однако, начальная синхронизация таблиц реализована как команда COPY и, следовательно, запускает как триггеры строк, так и триггеры операторов для INSERT.
30.7.1. Начальный снимок
Все исходные данные в существующих подписанных таблицах снимаются и копируются в параллельный экземпляр специального процесса применения. Этот процесс создает свой собственный слот репликации и копирует существующие данные. Как только копирование завершено, содержимое таблицы становится видимым для других бэкендов. После копирования существующих данных рабочий процесс переходит в режим синхронизации, который гарантирует, что таблица достигает синхронизированного состояния с основным процессом применения путем потоковой передачи любых изменений, произошедших во время копирования исходных данных, с использованием стандартной логической репликации. Во время этой фазы синхронизации изменения применяются и коммитятся в том же порядке, в котором они произошли на издателе. После завершения синхронизации управление репликацией таблицы возвращается основному процессу применения, где репликация продолжается как обычно.
Примечание
Параметр публикации publish влияет только на то, какие операции DML будут тиражированы. При синхронизации начальных данных этот параметр не учитывается при копировании существующих данных таблицы.