48.2. 逻辑解码概念

48 .2.1. 逻辑解码

逻辑解码是将对数据库表的所有持久更改提取为一致,易于理解的格式的过程,无需详细了解数据库的内部状态就可以对其进行解释。

在 PostgreSQL 中,逻辑解码是通过将write-ahead log的内容(描述了存储级别的更改)解码为特定于应用程序的形式(例如,Tuples 或 SQL 语句流)来实现的。

48 .2.2. 复制插槽

在逻辑复制的上下文中,插槽代表更改的流,可以按在原始服务器上进行更改的 Sequences 将更改流重放到 Client 端。每个插槽从单个数据库流式传输一系列更改。

Note

PostgreSQL 也有流复制插槽(请参阅Section 26.2.5),但是那里使用的方式有所不同。

复制插槽具有一个在 PostgreSQL 群集中的所有数据库中唯一的标识符。插槽的持久性与使用它们的连接无关,并且是防撞的。

在正常操作中,逻辑插槽将仅发出一次更改。每个插槽的当前位置仅保留在检查点,因此在发生崩溃的情况下,该插槽可能会返回到较早的 LSN,这将导致服务器重新启动时重新发送最近的更改。逻辑解码 Client 端负责避免多次处理同一条消息产生不良影响。Client 可能希望记录他们在解码时看到的最后一个 LSN,并跳过任何重复的数据,或者(当使用复制协议时)请求从该 LSN 开始解码而不是让服务器确定起点。复制进度跟踪功能就是为此目的而设计的,请参阅replication origins

单个数据库可能存在多个独立的插槽。每个插槽都有其自己的状态,从而允许不同的使用者从数据库更改流中的不同点接收更改。对于大多数应用,每个用户都需要一个单独的插槽。

逻辑复制插槽对接收器的状态一无所知。甚至可能有多个不同的接收器在不同的时间使用同一插槽。从最后一个接收者停止消费它们之后,他们就可以获取更改。在任何给定时间,只有一个接收器可以消耗时隙中的更改。

Note

复制插槽在崩溃中持续存在,并且不了解其使用方的状态。即使没有连接使用它们,它们也将防止删除所需的资源。这会浪费存储空间,因为只要复制插槽需要,VACUUM就无法删除系统目录中的必需 WAL 或必需行。因此,如果不再需要插槽,则应将其删除。

48 .2.3. 输出插件

输出插件将数据从预写日志的内部表示形式转换为复制插槽使用者所需的格式。

48 .2.4. 导出快照

使用流复制接口创建新的复制插槽(请参见CREATE_REPLICATION_SLOT)时,将导出快照(请参见Section 9.26.5),快照将准确显示数据库的状态,之后所有更改都将包含在更改流中。通过使用设置 Transaction 快照来读取创建插槽时数据库的状态,可以将其用于创建新副本。然后,可以使用该事务转储该时间点的数据库状态,此后可以使用插槽的内容对其进行更新,而不会丢失任何更改。

并非总是可以创建快照。特别是,当连接到热备用时,它将失败。不需要快照导出的应用程序可以使用NOEXPORT_SNAPSHOT选项取消它。