原文出自：https://bohutang.me/2020/08/26/clickhouse-and-friends-mysql-gtid-replication/
最後更新: 2020-09-03
<MySQL實時複製原理篇>
幾天前 ClickHouse 官方發佈了 v20.8.1.4447-testing(https://github.com/ClickHouse/ClickHouse/releases/tag/v20.8.1.4447-testing)，這個版本已經包含了 MaterializeMySQL 引擎，實現了 ClickHouse 實時複製 MySQL 數據的能力，感興趣的朋友可以通過官方安裝包來做體驗，安裝方式參考: https://clickhouse.tech/#quick-start，需要注意的是要選擇 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 是一個集羣(比如１主２從)，通過 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 (https://github.com/ClickHouse/ClickHouse/pull/13820)，下一個 testing 版本即可體驗。
着急的話可以自己編譯或通過 ClickHouse Build Check for master-20.9.1 (https://clickhouse-builds.s3.yandex.net/0/2b8ad576cc3892d2d760f3f8b670adf17db0c2a0/clickhouse_build_check/report.html) 下載安裝。
基於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 已經是社區功能，仍然有不少的工作要做。期待更多的力量加入，我們的征途不止星辰大海。
全文完。
Enjoy ClickHouse :)
葉老師的「MySQL核心優化」大課已升級到MySQL 8.0，掃碼開啓MySQL 8.0修行之旅吧
本文分享自微信公衆號 - 老葉茶館（iMySQL_WX）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。