PostgreSQL 中文参考文档
🌐 英文原版 官方 ↗

54.5. 逻辑流复制协议 #

54.5.1. 逻辑流复制参数
54.5.2. 逻辑复制协议消息
54.5.3. 逻辑复制协议消息流

本节描述逻辑复制协议,它是由 START_REPLICATION SLOT slot_name LOGICAL 复制命令启动的消息流。

逻辑流复制协议构建在物理流复制协议的原语之上。

PostgreSQL 的逻辑解码支持输出插件。 pgoutput 是内建逻辑复制所使用的标准插件。

54.5.1. 逻辑流复制参数 #

通过 START_REPLICATION 命令, pgoutput 接受以下选项:

proto_version

协议版本。目前支持版本 1、2、 3 和 4。必须给出一个有效的版本。

只有服务器版本 14 及以上才支持版本 2, 它允许对大型进行中事务进行流式传输。

只有服务器版本 15 及以上才支持版本 3, 它允许对两阶段提交进行流式传输。

只有服务器版本 16 及以上才支持版本 4, 它允许大型进行中事务的流被并行应用。

publication_names

以逗号分隔的发布名称列表,用于订阅(接收更改)。 各个发布名称被视为标准对象名称,可以按需用引号括起。 必须至少给出一个发布名称。

binary

使用二进制传输模式的布尔选项。二进制模式比文本模式更快, 但健壮性略差。

messages

启用发送由 pg_logical_emit_message 写入的消息的布尔选项。

streaming

启用对进行中事务进行流式传输的选项。有效值为 off(默认值)、on 和 parallel。设置 parallel 会在某些消息中附带额外的信息以供并行化使用。 要把它设为 on 至少需要协议版本 2; 要使用 parallel 值至少需要协议版本 4。

two_phase

启用两阶段事务的布尔选项。要把它打开至少需要协议版本 3。

origin

按来源发送更改的选项。可能的值有: none 表示只发送没有关联来源的更改, any 表示不管来源如何都发送更改。 这可用于避免复制节点之间出现循环 (同一数据被无限复制)。

54.5.2. 逻辑复制协议消息 #

各个协议消息将在后续小节中讨论。各条消息的描述见 Section 54.9。

所有顶层协议消息都以一个消息类型字节开始。 虽然在代码中它被表示为一个字符, 但这是一个没有关联编码的有符号字节。

由于流复制协议提供了消息长度, 顶层协议消息无需在其头部内嵌长度。

54.5.3. 逻辑复制协议消息流 #

除 START_REPLICATION 命令和重放进度消息之外, 所有信息都只从后端流向前端。

逻辑复制协议逐个发送各个事务。 这意味着一对 Begin 与 Commit 消息之间的所有消息都属于同一个事务。 类似地,一对 Begin Prepare 与 Prepare 消息之间的所有消息 也都属于同一个事务。 它还会在一对 Stream Start 与 Stream Stop 消息之间发送 大型进行中事务的更改。该事务的最后一个流 包含一条 Stream Commit 或 Stream Abort 消息。

每个被发送的事务包含零条或多条 DML 消息 (Insert、Update、Delete)。在级联设置中, 它还可以包含 Origin 消息。Origin 消息表明该事务 起源于另一个复制节点。由于逻辑复制协议范畴内的复制节点 几乎可以是任何东西,唯一的标识符就是来源名称。 按需处理它是下游的责任(如果需要)。 在事务的任何 DML 消息之前,总是会先发送 Origin 消息。

每条 DML 消息都包含一个关系 OID,标识被操作的那个发布者关系。 在针对给定关系 OID 的第一条 DML 消息之前, 会先发送一条 Relation 消息,描述该关系的模式。 此后,如果该关系的定义自上次为它发送 Relation 消息以来发生了变化, 就会再发送一条新的 Relation 消息。 (该协议假定客户端能够按需要记住尽可能多关系的这些元数据。)

Relation 消息通过 OID 标识列类型。对于内建类型, 协议假定客户端能够在本地查找该类型 OID,因此不需要额外数据。 对于非内建的类型 OID,会在 Relation 消息之前发送一条 Type 消息, 以提供与该 OID 关联的类型名称。 因此,需要专门识别关系列类型的客户端应当缓存 Type 消息的内容, 并首先查询该缓存,看其中是否定义了该类型 OID; 如果没有,再到本地查找该类型 OID。