专栏 | PostgreSQL数据实时同步在哈啰的实践

开源软件联盟PostgreSQL分会 2020-03-17

3105

背景

随着业务的发展，对于实时报表、数据实时搜索、集群同步的需求越来越旺盛，例如多业务的订单搜索、实时统计等。从PostgreSQL实时同步的开源方案主要有bottledwater-pg、Postgres_fdw等，开源的方案中基本处于缺乏维护状态，支持的功能也比较弱，为此哈啰实现了一套基于PostgreSQL逻辑复制槽的实时同步平台Tunnel。

架构设计

PG数据同步的实现原理

replication slots 是从PostgreSQL 9.4开始引入的，引入后我们可以基于复制槽实现更多的迁移同步需求。replication slots保存了逻辑或物理流复制的基础信息。类似MySQL的位点信息。一个逻辑slot创建后，它的相关信息可以通过pg_replication_slots系统视图获取。如果slot为active状态，则可以通过系统视图pg_stat_replication看到slot的实时的状态信息。PostgreSQL的逻辑日志来源于解析WAL日志。

解析WAL成为逻辑数据的过程叫Logical Decoding。Logical Decoding是把WAL日志解析成逻辑日志的过程。这个过程输出的数据格式可以描述为：

1、事务开始任何的变化总是在一个事务中，所以订阅的数据变化的开始是一个事务被启动的消息，他包括了事务ID、LSN、开始时间等信息。

2、数据的变化包括当前事务中修改的数据。即对某些表的insert/update/delete操作来带的数据变化。

一个事务内可以包含任意个表和任意行数据的变化。
输出的数据的格式和对应表的定义和REPLICA IDENTITY相关。

3、事务的提交包括事务提交的 LSN、时间等相关信息。

逻辑流复制利用索引的方式优化传输数据的效率，它们可以按表为单位定制。大致分为三种情况:

如果修改的表有primary key, 则表的变化的逻辑数据只会包括该表变化的列和pk列数据，如果pk列被修改，则还会输出老的pk列数据。
如果修改的表没有primary key，则可以使用alter table指定一个REPLICA index，同时需要这个索引列为非空，其产生的效果和1相同。
如果修改的表不满足上面的两个条件，而又要做同步，可以使用alter table设置这个表的REPLICA IDENTITY为FULL。于是系统在表修改时会记录修改行的所有列，不会做任何的优化。

同步任务的自动下发

同步任务进行申请配置后，任务下发到同步节点整体依赖zookeeper来实现，基于zookeeper的通知机制实现配置的变化监听，从管理节点获取到同步任务信息，执行相应的同步。为了平衡同步节点，通过监控计算同步节点最近有效的同步tps，然后按照贪心算法选择tps最小的任务节点进行下发。

同步任务的高可用

同步任务的高可用也是基于zookeeper实现而成，同步任务节点启动初始化时将机器节点信息注册至zookeeper，同步管理节点监听注册的机器节点，当机器节点发生down机或异常挂掉后，注册至zookeeper的临时节点将发生变更，管理节点监听变化后读取该节点执行的同步任务，将该任务下发至其他可工作的节点。下发时存在下发失败的可能性，需做好下发队列的重试工作。

同步数据的一致性

保证同步数据不丢失主要依赖以下两个方案：

通过复制槽的confirmed_flush_lsn进行消费数据成功的确认，confirmed_flush_lsn是逻辑插槽的consumer已确认接收数据的地址(LSN)，超过此时间的数据将不再可用。
数据发送至kafka，发送成功后flush lsn，通过自动创建消费kafka的任务同步至其他数据源，如ES、Hbase、Hive等，保证同步服务的性能与可靠性。