本文首发于 2020-08-28 20:40:14
《ClickHouse 和他的敌人们》系列文章转载自圈内好友 BohuTANG 的博客,原文链接:
https://bohutang.me/2020/08/2…
以下为注释。
MySQL 实时复制原理篇
几天前 ClickHouse 官网公布了 v20.8.1.4447-testing,这个版本曾经蕴含了 MaterializeMySQL 引擎,实现了 ClickHouse 实时复制 MySQL 数据的能力,感兴趣的敌人能够通过官网安装包来做体验,装置形式参考 https://clickhouse.tech/#quic…,须要留神的是要抉择 testing 分支。
基于位点同步
MaterializeMySQL 在 v20.8.1.4447-testing 版本是基于 binlog 位点模式进行同步的。
每次生产完一批 binlog event,就会记录 event 的位点信息到 .metadata 文件:
Version: 1
Binlog File: mysql-bin.000002
Binlog Position: 328
Data Version: 1
这样当 ClickHouse 再次启动时,它会把 {‘mysql-bin.000002’, 328}
二元组通过协定告知 MySQL Server,MySQL 从这个位点开始发送数据:
s1> ClickHouse 发送 {'mysql-bin.000002', 328} 位点信息给 MySQL
s2> MySQL 找到本地 mysql-bin.000002 文件并定位到 328 偏移地位,读取下一个 event 发送给 ClickHouse
s3> ClickHouse 接管 binlog event 并更新 .metadata 位点
看起来不错哦,然而有个问题:
如果 MySQL Server 是一个集群 (比方1主2从),通过 VIP 对外服务,MaterializeMySQL 的 host 指向的是这个 vip。
当集群主从产生切换后,{binlog-name, binlog-position}
二元组其实是不精确的,因为集群里主从 binlog 不肯定是完全一致的(binlog 能够做 reset 操作)。
s1> ClickHouse 发送 {'mysql-bin.000002', 328} 给集群新主 MySQL
s2> 新主 MySQL 发现本地没有 mysql-bin.000002 文件,因为它做过 reset master 操作,binlog 文件是 mysql-bin.000001
... oops ...
为了解决这个问题,咱们开发了 GTID 同步模式,废除了不平安的位点同步模式,目前已被 upstream merged #PR13820,下一个 testing 版本即可体验。
焦急的话能够本人编译或通过 ClickHouse Build Check for master-20.9.1 下载安装。
基于 GTID 同步
GTID 是 MySQL 复制增强版,从 MySQL 5.6 版本开始反对,目前曾经是 MySQL 支流复制模式。
它为每个 event 调配一个全局惟一 ID 和序号,咱们能够不必关怀 MySQL 集群主从拓扑构造,间接告知 MySQL 这个 GTID 即可,.metadata 变为:
Version: 2
Executed GTID: f4aee41e-e36f-11ea-8b37-0242ac110002:1-5
Data Version: 1
f4aee41e-e36f-11ea-8b37-0242ac110002
是生成 event 的主机 UUID,1-5
是曾经同步的 event 区间。
这样流程就变为:
s1> ClickHouse 发送 GTID:f4aee41e-e36f-11ea-8b37-0242ac110002:1-5 给 MySQL
s2> MySQL 依据 GTID:f4aee41e-e36f-11ea-8b37-0242ac110002:1-5 找到本位置点,读取下一个 event 发送给 ClickHouse
s3> ClickHouse 接管 binlog event 并更新 .metadata GTID 信息
MySQL 开启 GTID
那么,MySQL 侧怎么开启 GTID 呢?减少以下两个参数即可:
--gtid-mode=ON --enforce-gtid-consistency
比方启动一个启用 GTID 的 MySQL docker:
docker run -d -e MYSQL_ROOT_PASSWORD=123 mysql:5.7 mysqld --datadir=/var/lib/mysql --server-id=1 --log-bin=/var/lib/mysql/mysql-bin.log --gtid-mode=ON --enforce-gtid-consistency
注意事项
启用 GTID 复制模式后,metadata Version 会变为 2,也就是老版本启动时会间接报错,database 须要重建。
总结
MaterializeMySQL 引擎还处于不停迭代中,对于它咱们有一个初步的布局:
- 稳定性保障
这块须要更多测试,更多试用反馈 - 索引优化
OLTP 索引个别不是为 OLAP 设计,目前索引转换还是依赖 MySQL 表构造,须要更加智能化 - 可观测性
在 ClickHouse 侧能够不便的查看以后同步信息,相似 MySQLshow slave status
- 数据一致性校验
须要提供形式能够校验 MySQL 和 ClickHouse 数据一致性
MaterializeMySQL 曾经是社区性能,依然有不少的工作要做。期待更多的力量退出,咱们的征途不止星辰大海。
欢送关注我的微信公众号【数据库内核】:分享支流开源数据库和存储引擎相干技术。
题目 | 网址 |
---|---|
GitHub | https://dbkernel.github.io |
知乎 | https://www.zhihu.com/people/… |
思否(SegmentFault) | https://segmentfault.com/u/db… |
掘金 | https://juejin.im/user/5e9d3e… |
开源中国(oschina) | https://my.oschina.net/dbkernel |
博客园(cnblogs) | https://www.cnblogs.com/dbkernel |