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