Протокол логической потоковой репликации

В этом разделе описывается протокол логической репликации, представляющий собой поток сообщений, который запускается командой репликации START_REPLICATION SLOT имя_слота LOGICAL.

Протокол логической потоковой репликации собирается на примитивах протокола физической потоковой репликации.

Логическое декодирование QHB поддерживает плагины вывода. Для встроенной логической репликации используется стандартный плагин pgoutput.

Параметры логической потоковой репликации

Используя команду START_REPLICATION, pgoutput принимает следующие параметры:

proto_version
Версия протокола. В настоящее время поддерживаются версии 1, 2, 3 и 4. Требуется рабочая версия

Версия 2 поддерживается только для серверов версии 1.5.0 и выше и допускает потоковую передачу больших выполняющихся транзакций.

Версия 3 поддерживается только для серверов версии 1.5.2 и выше и допускает потоковую передачу двухфазных фиксаций.

Версия 4 поддерживается только для серверов версии 1.5.3 и выше и допускает параллельную передачу в потоке больших выполняющихся транзакций.

publication_names
Список разделенных запятыми имен публикаций, на которые следует подписаться (получать их изменения). Имена отдельных публикаций воспринимаются как стандартные имена объектов и при необходимости тоже могут заключаться в кавычки. Требуется хотя бы одно имя публикации.

binary
Логический параметр, включающий режим двоичной передачи. Двоичный режим быстрее текстового, но чуть менее устойчив.

messages
Логический параметр, включающий отправку сообщений, которые пишет функция pg_logical_emit_message.

streaming
Параметр, включающий потоковую передачу выполняющихся транзакций. Допустимые значения: off (по умолчанию), on и parallel. Значение parallel включает отправку дополнительной информации с некоторыми сообщениями, которые будут использоваться для параллелизации. Для включения параметра (on) требуется протокол не ниже версии 2. Для указания значения parallel требуется протокол не ниже версии 4.

two_phase
Логический параметр, включающий двухфазные транзакции. Для его включения требуется протокол не ниже версии 3.

origin
Параметр для отправки изменений по их источнику. Возможные значения: none для отправки только тех изменений, у которых нет связанного источника, или any для отправки изменений независимо от их происхождения. Это можно использовать, чтобы избежать зацикливаний (бесконечной репликации одних и тех же данных) между узлами репликации.

Сообщения протокола логической репликации

Отдельные сообщения протокола рассматриваются в следующих подразделах. Сами сообщения описаны в разделе Форматы сообщений логической репликации.

Все сообщения верхнего уровня начинаются с байта, указывающего на тип сообщения. Хотя он представлен в коде в виде символа, это знаковый байт, с которым не связана никакая кодировка.

Поскольку протокол потоковой репликации предоставляет длину сообщения, нет необходимости указывать длину в заголовках сообщений верхнего уровня.

Поток сообщений протокола логической репликации

За исключением команды START_REPLICATION и сообщений о ходе воспроизведения, весь информационный поток передается от сервера клиенту.

Протокол логической репликации передает отдельные транзакции одну за другой. Это означает, что все сообщения между парой сообщений Begin и Commit относятся к одной транзакции. Аналогично к одной транзакции относятся все сообщения между парой сообщений Begin Prepare и Prepare. Также протокол передает изменения из больших выполняющихся транзакций между парой сообщений Stream Start и Stream Stop. Последний поток для такой транзакции содержит сообщение Stream Commit или Stream Abort.

Каждая передаваемая транзакция содержит ноль или более сообщений DML (Insert, Update, Delete). В случае каскадной схемы она может также содержать сообщения Origin. Это сообщение показывает, что транзакция была запущена в другом узле репликации. Поскольку узел репликации в контексте протокола логической репликации может быть чем угодно, единственным идентификатором является его имя. За верное восприятие этого имени (если это необходимо) отвечают нижестоящие узлы. Сообщение Origin всегда передается перед всеми сообщениями DML в транзакции.

Каждое сообщение DML содержит OID отношения, идентифицирующий целевое отношение на стороне публикации. Перед первым сообщением DML для данного OID отношения будет передано сообщение Relation, описывающее схему этого отношения. Впоследствии, если определение отношения изменится после отправки последнего сообщения Relation, будет передано новое сообщение Relation. (Протокол предполагает, что клиент способен сохранить в памяти эти метаданные для любого требуемого количества отношений.)

В сообщениях Relation типы столбцов определяются их OID. В случае встроенного типа предполагается, что клиент может найти этот OID типа локально, поэтому никакие дополнительные данные не нужны. Для OID не встроенного типа перед сообщением Relation будет передано сообщение Type, предоставляющее имя типа, связанное с этим OID. Таким образом, клиент, которому нужно однозначно идентифицировать типы столбцов в отношении, должен кешировать содержимое сообщений Type, и сначала проверять этот кеш на предмет того, не определен ли там OID типа, а если нет, искать OID типа локально.