共计 2415 个字符，预计需要花费 7 分钟才能阅读完成。
简述
之前的一篇文章异地多活根底之数据双向同步收回来后，很多用户开始测评该计划，有应用稳固的，但也有用户碰到了一些问题 ( 性能 和GTID 空洞)。为了解决这些问题，咱们在 MySQL 到 MySQL 双向同步计划上又多走了一步。相比之前的计划，劣势显著。
- 不依赖 GTID
- 不依赖事务的程序，可并行
- 对端操作缩小
- 对云数据库 (MySQL) 的广泛反对
- 反对库表列裁剪、映射以及自定义数据处理
技术点
防抵触标记
GTID 防抵触标记蕴含 MySQL 的 server_uuid 和事务号，新计划咱们抉择 binlog 数据标记。
DML 在 Binlog 中失常的事件程序顺次为 QueryEvent(TxBegin)、TableMapEvent、WriteRowEvent(IUD)、QueryEvent(TxEnd) , 如果须要对同步的数据打上标记，除非对 WriteRowEvent 做标记，否则没有可下手的中央。然而要达成这个指标，以咱们的认知来看，除非改引擎代码。
而后，咱们盯上了 MySQL binlog 中一个形容变更行 statement 的事件 RowsQueryLogEvent，这个事件只在关上 MySQL binlog_rows_query_log_events 参数才会呈现，而这个事件能够带上执行 sql 的正文。
为此，咱们设计了 CloudCanal 写入对端时主动带上 /*ccw*/ 标记，这样在 RowsQueryLogEvent 的 sql 语句中也会呈现该标记，在双向同步中，如果遇到这个标记，过滤即可。
新的 DML 事件程序变成了 QueryEvent(TxBegin)、TableMapEvent、RowsQueryLogEvent、WriteRowEvent(IUD)、QueryEvent(TxEnd)。
举个 “ 栗子 ”
筹备 CloudCanal
本次案例应用 docker 社区版, 装置参考点此。
增加数据源
- 本案例采纳 阿里云 RDS for MySQL, 为测试便当起见，2 台数据库都位于 hangzhou 区域
- %(#ea1f1f)[在 RDS 实例详情 -> 参数设置，设置 binlog_rows_query_log_events 为 on]
- 登录 CloudCanal 平台，数据源治理 -> 增加数据源 , 将筹备的数据库逐渐增加进来
- 倡议对数据源进行形容批改，避免配置正反链路时，辨认错数据库
创立正向同步工作
- 工作治理 -> 新建工作
- 双向同步中，正向工作个别指源端有数据，指标端无数据的链路，波及对端数据初始化
第一个页面
- 抉择源端和指标端数据源和相干信息，点击 下一步
第二个页面
- %(#ea1f1f)[抉择 数据同步 ，并且勾选 全量数据初始化]
- 勾选 DDL 同步
- 置灰主动启动，以便创立工作后设置双向同步参数
- 点击 下一步
第三个、第四个页面
- 表、列映射裁剪 … 此处省略
- 点击 下一步
第五个页面
- 点击 确认创立
工作详情 -> 参数设置
- %(#ea1f1f)[设置指标数据源配置 deCycle 参数为 true]
- 此处和 GTID 计划有较大差异, %(#ea1f1f)[不须要开启 enableTransaction 和 gtidMode]
- 失效配置并启动
创立反向同步工作
- 工作治理 -> 新建工作
第一个页面
- 抉择源端和指标端抉择数据源（请和正向工作所选数据源对调 ）和相干信息，点击 下一步
第二个页面
- %(#ea1f1f)[抉择 数据同步 ，并去除 全量数据初始化 勾选]
- 勾选 DDL 同步
- %(#ea1f1f)[置灰主动启动，以便创立工作后设置双向同步参数]
- 点击 下一步
第三、四个页面
- 表、列映射裁剪 … 此处省略
- 点击 下一步
第五个页面
- 点击 确认创立
工作详情 -> 参数设置
- %(#ea1f1f)[设置指标数据源配置 deCycle 参数为 true ]
- 此处和 GTID 计划有较大差异, %(#ea1f1f)[不须要开启 enableTransaction 和 gtidMode]
失效配置并启动
工作同步
- 正向工作和反向工作失常同步, 进行源和指标数据校验, 后果统一
测试
- 源端数据库做数据变更，正向工作监控有变更，反向工作没有(即无循环)
- 指标端数据库做数据变更，反向工作监控有变更，正向工作没有(即无循环)
FAQ
新计划有什么不利因素
须要批改 MySQL 全局变量 binlog_rows_query_log_events 为 on , 这个参数默认是敞开的，相比 GTID 广泛关上，这是不利因素。
再者，binlog 增长绝对疾速，可能带来磁盘增长懊恼，清理 binlog 周期会变短。
最初，对于 CloudCanal 而言，减少了语句文本的内存占用，导致资源损耗加大。
不过绝对于新计划带来的益处 - 性能和稳定性大幅度晋升，咱们认为这些损失是值得的。
新计划除了 MySQL->MySQL 还反对哪些链路？
其余数据源是否存在 DML 语句或者数据可标记，咱们还没来得及深入研究，不过这个实现方向 (数据打标) 咱们认为是比拟敌对的。
总结
本文简略介绍了如何应用 CloudCanal 构建 MySQL->MySQL 双向同步链路降级计划，如果各位有需要，能够尝试应用下咱们的社区版收费体验。
最初，如果各位感觉这篇文章还不错，请点赞、评论加转发吧。
更多精彩
- 5 分钟搞定 MySQL 到 TiDB 迁徙同步 -CloudCanal 实战
- 5 分钟搞定 MySQL 到 ElasticSearch 迁徙同步 -CloudCanal 实战
- 5 分钟搞定 MySQL 到 MySQL 异构在线数据迁徙同步 -CloudCanal 实战
- 5 分钟搞定 MySQL 到 ClickHouse 实时数据同步 -CloudCanal 实战
- MySQL 到 ElasticSearch 实时同步构建数据检索服务的选型与思考
- 构建基于 Kafka 直达的混合云在线数据生态 -cloudcanal 实战
退出 CloudCanal 粉丝群把握一手音讯和获取更多福利，请增加咱们小助手微信：suhuayue001
CloudCanal- 收费好用的企业级数据同步工具，欢送品鉴。
理解更多产品能够查看官方网站：http://www.clougence.com
CloudCanal 社区：https://www.askcug.com/
