乐趣区

关于数据库:异地多活基础之数据双向同步进阶篇CloudCanal实战

简述

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

退出移动版