53.5. Протокол логической потоковой репликации#
53.5. Протокол логической потоковой репликации
Этот раздел описывает протокол логической репликации, который представляет собой поток сообщений, начинающийся с команды репликации START_REPLICATION SLOT slot_name LOGICAL.
Протокол логической потоковой репликации основан на примитивах физической потоковой репликации.
Tantor SE логическое декодирование поддерживает плагины вывода. pgoutput является стандартным плагином, используемым для встроенной логической репликации.
53.5.1. Параметры логической потоковой репликации
Используя команду START_REPLICATION,
pgoutput принимает следующие параметры:
- proto_version
Версия протокола. В настоящее время поддерживаются версии
1,2и3. Требуется указать допустимую версию.Версия
2поддерживается только для серверной версии 14 и выше, и она позволяет потоковую передачу больших транзакций, находящихся в процессе выполнения.Версия
3поддерживается только для серверной версии 15 и выше, и она позволяет потоковую передачу двухфазных коммитов.- publication_names
Список имен публикаций, разделенных запятыми, на которые нужно подписаться (получать изменения). Отдельные имена публикаций рассматриваются как стандартные имена объектов и могут быть заключены в кавычки по мере необходимости. Требуется как минимум одно имя публикации.
- binary
Булевый параметр для использования двоичного режима передачи. Двоичный режим быстрее текстового, но немного менее надежен.
- messages
Булевый параметр для включения отправки сообщений, которые записываются с помощью
pg_logical_emit_message.- streaming
Булевый параметр для включения потоковой передачи незавершенных транзакций. Для его включения требуется минимальная версия протокола 2.
- two_phase
Булевый параметр для включения двухфазных транзакций. Требуется минимальная версия протокола 3, чтобы включить его.
53.5.2. Протокол логической репликации. Сообщения
Сообщения протокола рассматриваются в следующих подразделах. Отдельные сообщения описаны в Раздел 53.9.
Все сообщения верхнего уровня протокола начинаются с байта типа сообщения. Хотя в коде они представлены в виде символа, это знаковый байт без связанной кодировки.
Поскольку протокол потоковой репликации предоставляет длину сообщения, нет необходимости в том, чтобы верхнеуровневые протокольные сообщения встраивали длину в свои заголовки.
53.5.3. Поток сообщений протокола логической репликации
С исключением команды START_REPLICATION и сообщений о ходе воспроизведения, вся информация передается только от сервера к клиенту.
Протокол логической репликации отправляет отдельные транзакции одну за другой. Это означает, что все сообщения между парой сообщений Begin и Commit относятся к одной и той же транзакции. Аналогично, все сообщения между парой сообщений Begin Prepare и Prepare относятся к одной и той же транзакции. Он также отправляет изменения в больших транзакциях между парой сообщений Stream Start и Stream Stop. Последний поток такой транзакции содержит сообщение Stream Commit или Stream Abort.
Каждая отправленная транзакция содержит ноль или более сообщений DML (Insert, Update, Delete). В случае каскадной настройки она также может содержать сообщения Origin. Сообщение Origin указывает, что транзакция произошла на другом узле репликации. Поскольку узел репликации в рамках протокола логической репликации может быть практически чем угодно, единственным идентификатором является имя источника. Это ответственность downstream обрабатывать это по необходимости (если требуется). Сообщение Origin всегда отправляется перед любыми сообщениями DML в транзакции.
Каждое сообщение DML содержит OID отношения, идентифицирующий отношение издателя, с которым было взаимодействие. Перед первым сообщением DML для данного OID отношения будет отправлено сообщение Relation, описывающее схему этого отношения. В дальнейшем будет отправлено новое сообщение Relation, если определение отношения изменилось с момента последнего отправленного сообщения Relation для него. (Протокол предполагает, что клиент способен запомнить эту метаданные для всех необходимых отношений).
Сообщения об отношении идентифицируют типы столбцов по их OID. В случае встроенного типа предполагается, что клиент может локально найти этот OID типа, поэтому дополнительные данные не требуются. Для не встроенного типа OID будет отправлено сообщение Type перед сообщением Relation, чтобы предоставить имя типа, связанное с этим OID. Таким образом, клиент, который должен явно идентифицировать типы столбцов отношения, должен кешировать содержимое сообщений Type и сначала обратиться к этому кешу, чтобы проверить, определен ли OID типа там. Если нет, следует локально найти OID типа.