[发明专利]基于MySQL的集群同步方法

说明书

本发明提供一种基于MYSQL的集群同步方法，其特征在于，包括：判断更新通知中的GTID是否为MYSQL原生的步骤，如果是，则执行步骤A1～A2，否则执行步骤B：步骤A1：将所述GTID中source_id的部分字符替换成自定义语义信息；步骤A2：推送所述注入了自定义语义信息的更新通知；步骤B1：解析所述GTID，判断所述更新通知的待推送目标是否为所述更新的源集群，如果是，则忽略所述更新通知；如果不是，则推送所述更新通知；所述自定义语义信息中包括所述更新通知所产生的源集群标识。

技术领域

本发明的方法涉及一种数据中心同步系统，尤其涉及基于MYSQL的集群同步方法。

背景技术

以MYSQL为基础搭建数据库系统是目前数据中心常见的解决方案，但对于双活甚至多活集群，不可回避的是数据回环问题。以图1中的双活集群为例：集群A中的一条数据X先被更新，集群B与集群A需要同步，因此定阅彼此的数据变化，前述对X的更新被推送给集群B，集群B进行更新后，又会将更新推送给A……如此无限循环。这里的更新采用广义，包括对数据的改变、新增等需要在集群间进行数据同步的操作，下文中如无特别说明，提到的更新也均采用此定义。

目前上述数据回环问题的解决方案分为两类：一类属于侵入式实现，比如利用MYSQL的Master数据变更时会写入二进制日志(binlog)这一特性，改写MYSQL的binlog生成逻辑，在其中加入自定义标识记录同步信息；另一类属于非侵入式，比如专门维护一张额外的表，用于记录同步信息，或在需要进行数据同步的表中额外添加一个隐藏列用于记录同步信息。。

但以上两类解决方案都有缺陷：侵入式实现方式对开发者要求较高，且容易引起bug等开发风险，如果依赖记录额外的Binlog Query Log Event的方案，又会引起大量存储资源的浪费，对于加入隐藏列的方式，会影响相关业务，带来系统风险。对于专门维护表，会引入额外的网络交互，大大提高网络延迟。

以MYSQL为基础搭建数据库系统还常面临的是幂等问题。所谓幂等问题就是相同条件下对一个业务的操作，不管操作多少次，结果都应当是一样。但在复杂系统中，由于一个业务可能涉及到多个系统，而多个系统可能还是独立部署的，会因为网络等原因导致同一个业务操作多次之后，结果出现不一致。比如订单业务和库存业务，可能部署在两个集群，彼此相互同步。对于一个商品扣减的Binlog Event再被消费一次后或者由于同步链路故障，或者由于网络重传等问题，导致又多次重复拉取消费了这个-1的Binlog Events，进而导致库存扣多了。。

MYSQL本身提供GTID(Global Transaction Identifier)机制解决幂等问题问题：以前述订单和库存业务为例，将对两个业务包裹在一个事务中，共享一个GTID，逻辑上能避免幂等问题。但实践中对于大型事务，如果简单将所有相关业务都包裹在一个事务中，会消耗巨大内存，也会严重阻塞同步流，引起系统可用性问题。

发明内容

鉴于以上所述现有技术的缺点，本发明提供一种基于MYSQL的集群同步方法，其特征在于，包括：判断更新通知中的GTID是否为MYSQL原生的步骤，如果是，则执行步骤A1～A2，否则执行步骤B：步骤A1：将所述GTID中source_id的部分字符替换成自定义语义信息；步骤A2：推送所述注入了自定义语义信息的更新通知；步骤B1：解析所述GTID，判断所述更新通知的待推送目标是否为所述更新的源集群，如果是，则忽略所述更新通知；如果不是，则推送所述更新通知；所述自定义语义信息中包括所述更新通知所产生的源集群标识。

优选地，上述基于MYSQL的集群同步方法中，所述判断更新通知中的GTID是否为MYSQL的方法是判断所述GTID中的Version bit，如果值为1表示MYSQL原生GTID。

优选地，上述基于MYSQL的集群同步方法中，所述步骤A1中还包括对所述GTID中Version bit取反的步骤。