多向异地多活-MySQL实时双向复制( 三 ) _MySQL实时双向

如果将Replicator拉取Binlog类比为Slave的I/O线程，磁盘文件类比为Relay log，Applier类比为Slave的SQL线程，那么Applier是可以采用同样的方式，使用set gtid_next设置经过DRC复制到对端事务的GTID，这样源和目标数据库的GTID set会保持一致，更重要的是可以标识出该事务是经DRC复制过来的。这也是DRC最终采用的破解循环复制的方案。
如下双向复制结构，Replicator Instance1只会同步源MySQL集群uuidSet1中的服务器产生事务，Replicator Instance2只会同步目标MySQL集群uuidSet2中的服务器产生事务。如果业务在源MySQL集群写入一条数据，Replicator Instance1从gtid_event中的GTID解析出uuid属于uuidSet1，那么会持久化到磁盘并发送给Applier Instance1，Applier Instance1接收到事务中包含的所有Event后，执行set gtid_next=GTID，然后通过JDBC将SQL写入目标MySQL，完成单向复制；Replicator Instance2接收到gtid_event后，同样解析出GTID，但是uuid并不属于uuidSet2，这样该条事务就会被过滤，从而避免的循环复制。

文章插图

幂等Applier如果重复接收到相同GTID的事务，由于MySQL会记录已经执行的GTID set，如果该GTID已经被执行，则会自动忽略，这样即使Applier重复应用同一条事务，也不会对业务产生影响。
小结从上面可以看到，在保证数据一致性时，GTID不论是在Replicator和Applier重启后Binlog位点定位，标识Binlog来源避免循环复制，还是Applier重复应用时幂等实现，都起到了至关重要的作用。
3）冲突解决设计上，首先要避免冲突的出现：
1）接入Set化的业务在流量入口处就会根据uid进行分流，同一个用户的流量进入同一个机房；数据接入层中间件DAL同样会采用local-2-local的路由策略。这样同一条记录在2个机房同时被修改的情况很少发生；
2）对于使用自增ID的业务，通过不同机房设置不同的自增ID规则，或者采用分布式全局ID生成方案，避免双向复制后数据冲突。
如果数据确实出现了冲突，2个机房对同一条数据进行的修改，这时需要根据冲突处理策略进行处理：
1）Applier根据默认的冲突处理策略进行处理，接入DRC的表都有一个精确到毫秒自动更新的时间戳，冲突时时间戳靠后的会被采用，进而实现数据的一致；
2）冲突的SQL会被监控记录，连同数据库中的原始数据同时提供给用户，进而自助决定是否需要进行覆盖。
4.3 DDL 支持DDL操作会引起表结构的变更，在复制链路中Applier需要表结构信息解析对应时刻的Binlog Event，当Applier消费速率落后Replicator的发送速率时，就需要历史版本的表结构信息才能够正确解析Binlog Event 。这就引入了表结构设计第一个问题：历史版本如何存储？
为了存储表结构，势必首先要获得表结构，如果从源MySQL直接抓取表结构，由于Binlog是异步发送，就导致抓取到DDL的Binlog时刻，与MySQL上表结构未必能够一一对应，从而引起Applier解析出现问题，进而导致数据不一致。这就引入表结构设计第二个问题：表结构从何处抓取？
业界通用的解决方案是基于独立的第3方数据库进行表结构单独存储管理。数据库本身就是存储工具，Snapshot表和DDL表分别保存表结构快照和DDL变更记录，这样任意时刻的表结构等于Snapshot及其后DDL变更集合，则第一个表结构存储问题顺其自然得以解决；独立数据库镜像一份源数据库的库表结构，每次从Binlog接收到DDL Event后，将解析出的DDL语句直接应用到镜像数据库，随即抓取相应表结构即可，这样就解决了第二个表结构从何处抓取的问题。

文章插图

独立数据库解决方案的缺点是引入外部依赖，降低了系统的可用性，提高了运维成本。
4.3.1 表结构存储和计算针对DDL功能中问题一：
从数据库中查询Snapshot和DDL记录的好处是时间顺序容易确定，能够简单准确的恢复表结构。那么是否有其他存储介质，在保存表结构快照和DDL操作的同时，能够保证时序呢？有，保存Binlog的文件就具有这种特性，DRC采用了这种基于Binlog的表结构文件存储方案。
针对DDL功能中问题二：
镜像数据库是为了实时计算出DDL变更后最新的表结构信息，在存储不使用独立部署的数据库后，DRC引入嵌入式轻量数据库，降低外部依赖和系统运维成本。
这样整体的设计方案如下图所示：