简述
之前的一篇文章异地多活根底之数据双向同步收回来后,很多用户开始测评该计划,有应用稳固的,但也有用户碰到了一些问题 ( 性能 和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/