干货|携程多活动-MySQL实时双向（多方向）复制实践(2)

2）冲突的SQL将与中的原始数据一起被监视和记录，同时提供给用户，然后自行决定是否覆盖它.

DDL操作将导致表结构的更改. 在复制链接中，申请人需要表结构信息来在相应时间解析Binlog事件. 当Applier消耗速率落后于复制器的发送速率时，需要具有历史版本的表结构信息才能做到这一点. 正确解析Binlog事件. 这引入了表结构设计的第一个问题: 如何存储历史版本？

为了存储表结构，必须首先获取表结构. 如果直接从源MySQL获取表结构，则由于Binlog是异步发送的，因此它将获取DDL的Binlog时刻，该时刻可能与MySQL上的表结构不同. 相应地，导致Applier解析问题，从而导致数据不一致. 这引入了表结构设计的第二个问题: 在哪里获取表结构？

业界常见的解决方案基于独立的第三方，用于单独存储和管理表结构. 本身是一种存储工具. Snapshot表和DDL表分别保存表结构快照和DDL更改记录，因此该表结构随时等于Snapshot和后续DDL更改的集合，自然可以解决第一个表结构存储问题；独立镜像源的表结构的副本. 每次从Binlog接收到DDL事件时，将解析的DDL语句直接应用于镜像，然后捕获相应的表结构. 这解决了第二个问题，即在哪里获取表结构.

独立解决方案的缺点是引入了外部依赖关系，这降低了系统的可用性并增加了操作和维护成本.

对于DDL功能中的问题一:

从中查询快照和DDL记录的优点是时间序列易于确定，并且可以简单，准确地恢复表结构. 那么，在保存表结构快照和DDL操作时，是否还有其他存储介质可以保证定时？是的，保存在Binlog中的文件具有此功能，DRC采用这种基于Binlog的表结构文件存储方案.

对于DDL功能中的问题二:

镜像将在DDL实时更改后计算最新的表结构信息. 存储独立部署的后，DRC引入了嵌入式轻量级，以减少外部依赖性以及系统运行和维护成本.

总体设计方案如下图所示:

Binlog文件头将保存自定义表结构快照事件. 从接收到的事件事件中检测到DDL时，它将被保存为自定义DDL事件. 这样，当Applier连接到Replicator时，它将始终根据GTID集将文件定位在需要第一个历史版本表结构的文件上，以便实时还原表结构历史记录，以用于后续的Binlog事件分析.

我们将最小依赖性设置为独立的Jar包服务. 启动每个Replicator实例时，将一起启动一个独立的嵌入式. 还原GTID集时，它将根据表结构快照事件和DDL事件进行重建. 嵌入式中的表结构.

携程内部通过gh-ost释放DDL进行更改. gh-ost将在影子表中执行DDL操作. 影子表中的数据同步后，原始表和影子表将在业务的高峰期切换.

对于gh-ost，有必要在gh-ost更改期间跟踪内部表的所有DDL操作（如_xxx_gho），并在切换时最终检测到重命名操作，保存相应表结构的最新信息，并将其发送给应用程序.

同时，对于由直接执行的DDL操作，您可以直接检测DDL类型的事件.

对于连接到DRC的，在进行DDL更改时，两个的更改可能不同步. 一侧进行DDL更改，而另一侧不进行更改. 对于新列的情况，申请人在确保数据一致的前提下比较新列的值. 如果Binlog中解析的值与该列的默认值一致，则该列将被删除并且数据复制将继续. . 这样，在另一侧添加了DDL更改后，两边的数据最终将保持不变.

DRC核心指标包括复制延迟和数据一致性. 此外，我们还提供BU，应用程序和IDC维度监控:

1）交通和TPS监视警报；

2）监视BU，应用程序和IDC尺寸的警报；

3）DDL更改监控；

4）表结构一致性监控告警；

5）数据冲突监控；

6）GTID设置GAP监控.

此共享重点关注DRC的复制延迟和数据一致性的核心指标，并介绍了复制过程中性能的优化以及如何在各种情况下确保数据一致性. 对于DDL，分别支持gh-ost和直接DDL操作mysql 获取当前毫秒，因此联机表结构更改不会影响数据复制.

后续的DRC工作将着重于高可用性，海设施的建设，以为携程的国际化战略提供数据级别的支持.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-284861-2.html