关于clickhouse:源码分析-ClickHouse和他的朋友们11MySQL实时复制之GTID模式

本文首发于 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 侧能够不便的查看以后同步信息，相似 MySQL show slave status
• 数据一致性校验
  须要提供形式能够校验 MySQL 和 ClickHouse 数据一致性

MaterializeMySQL 曾经是社区性能，依然有不少的工作要做。期待更多的力量退出，咱们的征途不止星辰大海。

欢送关注我的微信公众号【数据库内核】：分享支流开源数据库和存储引擎相干技术。