自 PostgreSQL 9.4 ，终于支持了逻辑流复制。本篇文章为大家带来这部分的技术细节的分析。 ## 1\. 背景 PostgreSQL 9.4 对逻辑流复制的支持具有相当的意义。我们可以用该技术完成很多企业级的需求。 1. PostgreSQL 的大版本升级，由于可以使用流复制做增量数据同步，所以停机服务时间会非常短。 2. PostgreSQL 自定义逻辑拆库。由于是逻辑数据，所以很容易自定义分发规则。例如按表拆，逻辑分表，白名单，黑名单等等。 3. PostgreSQL 增量同步到其他异构数据库，例如 PG 同步到 Mysql；PG 同步到 Oracle。 4. 逻辑主备同步，逻辑多节点同时可写集群。 ## 2\. 名词解析 | Logical Decoding | PostgreSQL 的逻辑日志来源于解析物理 WAL 日志。 解析 WAL 成为逻辑数据的过程叫 Logical Decoding。 | | Replication Slots | 保存逻辑或物理流复制的基础信息。类似 Mysql 的位点信息。 一个 逻辑 slot 创建后，它的相关信息可以通过 pg_replication_slots 系统视图获取。 如果它在 active 状态，则可以通过系统视图 pg_stat_replication 看到一些 slot 的实时的状态信息。 | | Output Plugins | PostgreSQL 的逻辑流复制协议开放一组可编程接口，用于自定义输数据到客户端的逻辑数据的格式。 这部分实现使用插件的方式被内核集成和使用，称作 Output Plugins。 | | Exported Snapshots | 当一个逻辑流复制 slot 被创建时，系统会产生一个快照。客户端可以通过它订阅到数据库任意时间点的数据变化。 | ## 3\. 逻辑流复制输出的数据格式 Logical Decoding 是把 WAL 日志解析成逻辑日志的过程。这个过程输出的是数据格式可以描述为： 1. 事物开始 任何的变化总是在一个事物中，所以订阅的数据变化的开始是是一个事物被启动的消息，他包括了事物 ID，LSN，开始时间等信息。 2. 数据的变化 包括当前事物中修改的数据。即对某些表的 insert update delete 操作来带的数据变化。 * 一个事物内可以包含任意个表和任意行数据的变化。 * 输出的数据的格式和对应表的定义和索引相关，详细信息看后面文章的描述。 3. 事物的提交 包括事物提交的 LSN，时间等相关信息。 ## 4\. Output Plugins 需要完成的工作 上一节的内容提到的数据需要通过 Output Plugins 确定最终的数据格式，再发送给客户端。 这部分的接口表现为下列回调函数： 1. LogicalDecodeStartupCB startup_cb; 2. LogicalDecodeBeginCB begin_cb; 3. LogicalDecodeChangeCB change_cb; 4. LogicalDecodeCommitCB commit_cb; 5. LogicalDecodeShutdownCB shutdown_cb; 函数 1，5 是分配和清理插件所需的内存结构。此外的 2，3，4 三个回调函数完全对应上一节中的三个部分。 开发者可以根据需求实现这一组函数。 ### 4.1 技术细节 毫无疑问，定制逻辑数据格式成为了 Output Plugins 的关键。根据不同的需求产生的数据也会有显著的不同。 1. 发送的数据可以是普通字符串，也可以是二进制字符串。为了客户端解析数据更容易，通常使用二进制字符串表达数据。 2. 如果做同构数据库数据同步，传输的数据可以比较简单。原因是可以使用内部数据直接表达变化的数据。 3. 如果要做异构数据库同步，情况会复杂一些。目前的方案是把增量数据组合成通用 SQL，再写入到异构数据库中。这样就需要给出转换数据成 SQL 语句的所有信息。在变化的数据本身外，还需要包括表名，列名，列数据类型，索引信息等等。 4. 针对不同数据库的特殊字符，还需要处理转译字符的问题。 5. 针对表中的长字段，需要优化。如果不修改这些大字段，可以选择不传输它们。 ### 4.2 REPLICA IDENTITY 如何影响数据的格式 逻辑流复制利用索引的方式优化传输数据的效率，它们可以按表为单位定制。大致分为三种情况: 1. 如果修改的表有 primary key, 则表的变化的逻辑数据只会包括该表变化的列和pk列数据，如果 pk 列被修改，则还会输出老的 pk 列数据。 2. 如果修改的表没有 primary key，则可以使用 alter table 指定一个 REPLICA index，同时需要这个索引列为非空，其产生的效果和 1 相同。 3. 如果修改的表不满足上面的两个条件，而又要做同步，可以使用 alter table 设置这个表的 REPLICA IDENTITY 为 FULL。于是系统在表修改时会记录修改行的所有列，不会做任何的优化。 很明显，给对应的表设置 PK 或指定索引，在数据同步时效率更高。我们可以安需定制同步策略。在实现功能的过程中需要考虑这部分变化。 ## 5\. 总结 逻辑流复制特性对 PostgreSQL 意义重大，目前已经有很多相关的数据同步产品应运而生，比如 2nd quadrant 公司的 BDR/UDR。也有公司调整了已有产品原有的技术方案，使用逻辑流复制为增量数据的同步方案，比如 EDB 公司的 xDB。阿里云 RDS 团队也利用该特性推出了 PostgreSQL 的数据迁移服务，并且开源了相关代码。 最后，我们期待更多相关产品的出现。 谢谢！