数据库迁移 | DBMotion v23.04 支持异地多活

news2025/1/18 10:52:44

Squids DBMotion新版本支持异地多中心双活同步了。异地多活支持业务在多个数据中心同时操作数据库，能极大地提升高可用性、容错性和用户体验。其中最关键的技术，无疑是数据同步、同步防环和数据冲突解决。Squids DBMotion通过复制数据打标和预置冲突策略，解决了异地多活的数据同步关键问题。

假设你是一个MySQL DBA，你们公司有三个机房：北京、广州和上海。领导要求你提供一个解决方案：让每个地区的客户都就近访问本地的数据库，华北的客户数据存储在北京的数据库，华东的客户数据存储在上海的数据库，华南的客户数据存储在广州的数据库上。这些数据库的数据需要能相互同步，保证数据一致，以便华北的用户出差到上海以后可以就近访问上海数据库上的数据（这些数据是华北这个客户的数据从北京同步到上海的），在上海出差产生的数据同样应该同步回北京。这样客户出差回北京以后，他可以继续访问和更新“最新”的数据。

对应的，你就需要搭建一个异地多活架构来实现数据的就近访问和同步。简单的示意图如下：

这里有两个关键技术问题需要解决：

业务在多个中心产生的变更相互同步，会产生循环复制，如何同步防环。
在多个中心更新数据会有数据冲突，怎么检测冲突和解决冲突。

接下来，将用以上案例来分析一下问题所在，介绍以DBMotion作为第三方工具的解决方案。

01 同步防环

如前所述，华北、华东和华南三中心关键的就是要实现双向同步，保证业务在一个中心写的数据可以复制到另外一个中心。

数据库原生提供的复制，有些是可以搭建双向复制的，但是这种方式只能做到实例级别同步（无法支持表级别过滤或者做对象名映射）、无法定制化修改（需要有内核修改能力并且修改后必须暂停业务以升级数据库），监控和管理不直观（命令行式，操作不便）。一般使用专业的双向同步工具或者其他第三方工具来实现，以保证易用性、易维护性，提供定制化修改和监控管理功能。

DBMotion实现了MySQL和openGauss的双向同步，它不依赖于数据库原生的复制，采用独立的cdc解析模块从源库中获取重做日志并解析，通过sink模块将源库中的变更并行应用到目标库。

如下图所示，如果不做特殊处理，将会出现循环复制的问题。

还是以MySQL为例，上图中两个MySQL实例分别位于华东中心和华南中心，如果通过DBMotion做双向同步，那么在华东中心插入一行数据，通过DBMotion在华南回放，也会插入一行数据；但是反向的DBMotion解析到这条insert的数据，又会将它同步回华东中心。也就产生了循环复制，如果是无主键表，insert不产生唯一约束冲突，这个insert将在华东和华南永续循环复制下去。

DBMotion采用的是类似于server-id打标的方式，对写入华南中心的时候对日志进行标记，保证DBMotion写入的数据，在DBMotion日志解析的时候能够被认出来，避免数据被复制回华东中心。

扩展到多中心后，DBMotion会做额外的处理。在华东中心把从华北中心复制过来的数据和业务所请求的数据统一标记成region1。那么，在华南中心复制过来的业务数据没有标记，而从华东中心复制过来的数据都有标记，就可以将打标的更新成功过滤。

当然，这种同步还是避免不了用户故意搭建的环形复制链路产生循环复制，所以DBMotion支持的异地多活，目前只能支持树形复制，类似于下图的结构。在region-id=6的数据库上插入一笔数据，通过DBMotion同步到region-id=2的节点时，会将2标记为同步到region-id为1和5的节点，并且从1和5同步回来时会自动被过滤掉，之后会依次被同步到3,4;7;8。

总之，“同步防环”可以解决一条更新在多个中心上循环复制的问题，异地双活的关键技术难点“循环复制”，可以通过打标忽略的方式解决。

02 冲突检测和解决

异地多活又称为单元化，前提是业务可以单元化，让客户同时只在一个单元上操作。

如前文中提到的，北京的用户无论是在北京还是在上海，只会在不同的时间点更新自己的数据，不会出现在多个中心同时更新同一笔数据的情况。如果需要在同时在同一个时间点更新同一个数据，如北京和上海的用户同时汇款给广州的客户，就可能同时对广州的客户账户有两个增加余额的操作。

这种同时在多中心操作同一笔数据的方式，需要在业务上严格避免，或在业务架构上使用集中式架构，在同一个中心应对所有单元的更新请求；或对业务进行单元化分拆。

另外，复制延迟也有可能导致冲突，例如北京的客户出差到了上海来更新自己的数据，此时在北京的部分更新还没有同步到上海，那么也会出现类似于两边同时写同一份数据的冲突。

上述数据冲突的问题，都必须在业务或者说在数据库的上层解决。通过数据同步将数据已经写入到数据库后，数据冲突在“下层”是无法解决的，只能检测冲突，提醒客户有冲突发生，并提供相关的冲突解决策略去辅助客户解决这个问题。

DBMotion通过匹配前镜像和后镜像更新报错来发现冲突，目前提供两种机制来处理冲突：

复制链路可以指定冲突错误忽略列表，用户可以指定对部分冲突报错直接忽略报错，类似于MySQL的replica_skip_errors错误。例如：用户需要对Duplicate Key报错进行忽略，可以直接在冲突错误忽略列表中增加1062错误。
复制检测到冲突后，可以按照复制冲突策略来自动处理冲突。

DBMotion复制检测到冲突，目前有三种冲突解决策略可以指定：

报错：DBMotion在检测到冲突以后会报错停止，配合短信和邮件报警。用户收到报错后可以查看并手工解决冲突，点“继续”会让DBMotion断点续传从上次报错的位置继续同步。
忽略：DBMotion在检测到冲突后，只会在日志中记录冲突，忽略错误并继续同步。
覆盖：DBMotion会直接以主键或者唯一键对目标库进行覆盖，保证目标库和源库一致，继续同步。

综上，冲突检测和解决是异地多活面临的通用问题，需要在业务架构上尽量避免。DBMotion在数据库同步的时候提供了两种机制，三种策略来辅助客户检测冲突和设置冲突解决策略。