选择 打开 改范围 完整检索页
受支持版本: 当前版本 (18) / 17 / 16 / 15 / 14
开发版本: 19 / devel
不受支持的版本: 13 / 12 / 11 / 10
当前 PostgreSQL 版本不在支持生命周期内。
您可以参阅当前版本的对应页面,或其他在上面列出的活跃大版本。

53.5. 逻辑复制协议 #

本节介绍逻辑复制协议,它是一种以复制命令START_REPLICATION SLOT slot_name LOGICAL开始的消息流。

逻辑复制协议构建在物理流复制协议的底层机制之上。

53.5.1. 逻辑复制参数 #

逻辑复制的START_REPLICATION命令接受以下参数:

proto_version

协议版本。目前仅支持版本 1

publication_names

要订阅(接收变更)的发布名称列表,以逗号分隔。各个发布名称按标准对象名称处理,可以按需以相同方式加引号。

53.5.2. 逻辑复制协议消息 #

各种协议消息将在后续小节中分别讨论。每种消息的具体格式见Section 53.9

所有顶层协议消息都以一个消息类型字节开头。虽然它通常写作字符代码,但本质上它是一个与任何字符编码无关的有符号字节。

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

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

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

逻辑复制协议逐个发送事务。这意味着,一对 Begin 和 Commit 消息之间的所有消息都属于同一个事务。

每个被发送的事务都包含零条或多条 DML 消息(插入、更新、删除)。在级联场景下,它还会包含 Origin 消息。Origin 消息表示该事务产生于另一个复制节点。由于逻辑复制协议中的复制节点可以是任意实现,因此唯一标识符就是该源头的名称。下游是否以及如何处理这一信息,由其自行决定。Origin 消息总是在事务中的任何 DML 消息之前发送。

每条 DML 消息都包含一个关系 OID,用于标识被操作的发布者关系。在某个关系 OID 的第一条 DML 消息之前, 会先发送一条 Relation 消息,描述该关系的模式。之后,如果该关系的定义自上次发送 Relation 消息以来发生了变化, 就会再发送一条新的 Relation 消息。(协议假定客户端能够缓存所需关系的元数据。)

Relation 消息通过 OID 标识列类型。对于内置类型,假定客户端可以在本地查找该类型的 OID,因此无需额外数据。 对于非内置类型 OID,会在 Relation 消息之前发送一条 Type 消息,以提供与该 OID 关联的类型名称。 因此,需要明确识别关系列类型的客户端应缓存 Type 消息内容,并先检查该缓存中是否已经定义了对应的类型 OID; 若没有,再在本地查找该类型 OID。