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