深入浅出达梦共享存储集群数据同步

简介

题外话：前一阵子一直在做 达梦 DSC 集群数据同步，踩了挺多坑，不过值得庆幸的是最终还是把这件事情搞定了。

达梦 DSC（Data Shared Cluster）是达梦官方提供的一种共享存储的数据库集群系统，支持高可用、高性能及负载均衡。

挑战 1：达梦共享集群归档日志分析

在达梦共享数据集群中，各个节点维护着自己的日志系统，在最开始，打算走老路子：

1. 根据当前 LSN 指定需要挖掘的归档日志。
2. 指定需要挖掘的 LSN 范围。
3. 查询挖掘出来的 Redo SQL。
4. 解析 Redo SQL 转换为增量数据。

在进行到第二步的时候，发现达梦直接报错了，提示"不允许添加重复的日志"，实际上我并没有添加重复的日志。

重新翻阅达梦官方文档，最后发现，在达梦共享存储集群中，每个节点都有着自己的日志系统，但是达梦官方并没有提到该如何对达梦共享存储集群的日志挖掘。

我们沿着这个线索，进行了验证，发现根据节点编号分组后的日志可以分析，而且并不会报错之类的，于是乎，分析日志的步骤：

1. 根据节点号以及当前 LSN 来指定所需要挖掘的归档日志。
2. 指定需要挖掘的 LSN 范围。
3. 查询挖掘出来的 Redo SQL。
4. 解析 Redo SQL 转换为增量数据。

挑战 2：消费多实例日志数据乱序

解决归档日志分析之后，由于在消费不同节点的日志线程是隔离的，如果在多个节点操作同一张表的数据，会导致数据乱序的问题。

再次翻阅达梦文档，达梦文档有提到在故障重启的时候会根据事务提交的 LSN 排序，然后顺序消费排序之后的事务，我们延用达梦故障重启的思路，将多个实例上的事务号根据 LSN 进行排序，于是乎，分析日志的步骤：

1. 根据节点号以及当前 LSN 来指定所需要挖掘的归档日志。
2. 指定需要挖掘的 LSN 范围。
3. 查询挖掘出来的 Redo SQL。
4. 将提交的事务号根据 LSN 号进行排序。
5. 消费已排序完毕的事务的 Redo SQL 并转换为增量数据。

挑战 3：多节点 LSN 不连续

日志数据乱序的问题解决之后，又发现在达梦共享数据集群中 LSN 并不是连续的，对于集群中各个节点的 LSN 是连续的，这就可能会出现，节点 1 的 LSN 是 200 ，而节点 2 的 LSN 已经递增到 1000，这样就会导致任务的 LSN 始终无法递增，始终是节点 1 的 LSN。

翻阅达梦官方文档后，发现达梦 DSC 在不同实例操作不同数据页的时候，并不要求 LSN 连续，当不同节点操作了同一个数据页的时候，会触发一次全局 LSN 强同步。

根据文章中的内容，只能尝试去操作同一条数据，因为并不知道达梦在存储层干了些什么，按照下面这个步骤尝试验证了这段文章的内容：

1. 节点 1 创建一个表结构。
2. 节点 1 进行一些操作（变更数据），使节点 1 和节点 2 的 LSN 差距 5000 以上。
3. 节点 1 对这张表插入一条 ID 为 1 的数据。
4. 节点 2 对这张表将 ID 为 1 的数据删除。
5. 查询节点 1 和节点 2 的 LSN 。

经过这么一套操作下来，惊奇的发现节点 2 的 LSN 延续着节点 1 的 LSN 进行递增，这样就可以完全解决任务 LSN 无法递增的问题。