Postgresql 中文操作指南

31.7. Architecture #

逻辑复制从复制发布者数据库中数据的快照开始。一旦完成此操作，发布者上的更改就会实时发送到订阅者。订阅者按在发布者上提交的顺序应用数据，从而保证任何单一订阅内发布事务的一致性。

基于一个与物理流复制相似的架构构建逻辑复制（参见 Section 27.2.5）。它由 walsender 和 apply 进程实现。walsender 进程启动 WAL 的逻辑解码（描述见 Chapter 49）并加载标准逻辑解码输出插件 (pgoutput)。此插件将从 WAL 中读取的更改转换为逻辑复制协议（参见 Section 55.5）并根据发行说明筛选数据。然后，使用流复制协议将数据连续传送到 apply worker，此 worker 将数据映射到本地表，并在收到后按正确的交易顺序应用各个更改。

在订阅数据库中应用进程总是以将 session_replication_role 设为 replica 的方式运行。这意味着，默认情况下，触发器和规则不会在订阅数据库中触发。用户可以选择使用 ALTER TABLE 命令和 ENABLE TRIGGER 、 ENABLE RULE 子句来启用表中的触发器和规则。

逻辑复制应用进程目前仅触发行触发器，而不触发语句触发器。然而，初始表同步的实现类似于 COPY 命令，因此对 INSERT 触发行触发器和语句触发器。

31.7.1. Initial Snapshot #

现有已订阅表中的初始数据被快照并复制到特殊类型的应用进程的并行实例中。此进程将创建自己的复制槽并复制现有数据。一旦复制完成，表内容就会对其他后端可见。一旦复制了现有数据，工作进程便会进入同步模式，该模式通过使用标准逻辑复制流传输在初始数据复制期间发生的所有更改来确保该表与主应用进程达到同步状态。在此同步阶段，按它们在发布者上发生的顺序应用并提交这些更改。一旦同步完成，表的复制控制权就会交还给主应用进程，其中复制将正常继续。

Note

发布 publish 参数仅影响将在哪些 DML 操作中进行复制。初始数据同步在复制现有表数据时不会考虑这个参数。