前言

ClickHouse無疑是目前最火的OLAP解決方案，筆者所在的運維團隊，ClickHouse的數量近兩年增長迅猛。

最近老闆安排了一個任務，要求我調研現在MySQL到ClickHouse的同步工具，方便後面將線上的線上OLTP資料

實時同步給線下的OLAP ClickHouse，這樣業務人員和運營人員基於它進行統計查詢更直觀快速。

目前，市面上的相關工具和產品，主要分為三類：

1. ClickHouse原生提供的MySQL同步工具

2. 命令列式的MySQL to ClickHouse同步工具

3. 介面引導式的MySQL to ClickHouse同步工具

01 ClickHouse原生同步工具

ClickHouse 官方提供了MaterializedMySQL的同步複製工具，它會獲取MySQL的binlog，並重放DDL和DML。

但是這個特性沒有release，官方文件用醒目的字型顯示“This is an experimental feature that should not be used 

in production.”不能用在生產環境中，並且看程式碼也有一段時間沒有更新了。

測試結果如下 ：

• 在MySQL上建立一個表。

mysql> create database db1;
mysql> create table test1 (a INT PRIMARY KEY, b INT);

• 在ClickHouse上新建MaterializeMySQL的表。

## 這裡要專門設定以便clickhouse能使用這個特性
ck> set allow_experimental_database_materialize_mysql=1;   
## 這裡建立連線到user@192.168.1.17:3306/db1的database連線，命名為db1_ck
ck> CREATE DATABASE db1_ck ENGINE = MaterializeMySQL('192.168.1.17:3306', 'db1', 'user', '***');
## 進入db1_ck這個資料庫
ck> se db1_ck;
## 檢視db1_ck庫下的表，可以看到test1這個表
ck> show tables;

• 檢視test1這個表在ck上的表結構。

ck> show create table test1;
CREATE TABLE db1_ck.test1
(
    `a` Int32,
    `b` Nullable(Int32),
    `_sign` Int8 MATERIALIZED 1,
    `_version` UInt64 MATERIALIZED 1,
    INDEX _version _version TYPE minmax GRANULARITY 1
)
ENGINE = ReplacingMergeTree(_version)
PARTITION BY intDiv(a, 4294967)
ORDER BY tuple(a)
SETTINGS index_granularity = 8192

test1表使用的是ReplacingMergeTree引擎，表結構新增了兩個欄位_sign和_version作為隱藏欄位，用於標識該行是否刪除

和版本號。這樣將MySQL的update和delete統一轉換成insert，充分利用ClickHouse快速匯入資料、update和delete慢且容易出問題的特性。內部實現原理的細節和好處，我們將在另外一篇文章裡面介紹。

•在MySQL上操作，看資料會不會同步到ClickHouse上。

mysql> insert into test1 values (1,11),(2,22),(3,33);
mysql> update test1 set b=77 where a=1;
mysql> delete from test1 where a=2;
ck> select * from db1_ck.test1;
┌─a─┬──b─┐
│ 1 │ 77 │
│ 3 │ 33 │
└───┴────┘

可以看到，資料基本都正確地同步到ClickHouse上去了。

02 命令列式同步工具

這一類是利用命令列來實現MySQL同步到ClickHouse的工具，例如Altinity的clickhouse-mysql-data-reader工具，

這個工具也可以實現DML的資料同步。但是安裝和命令列使用太麻煩，而且這個工具2020年就不再更新了，

所以此次沒有進一步深入研究。

03 介面引導式工具——以DBMotion為例

有獨立的web介面來實現MySQL同步到ClickHouse，使用者體驗更方便。類似的國內產品有很多，從簡單性和穩定性來說，

個人偏向於DBMotion。下面就以DBMotion的線上版本為例，介紹一下介面引導式MySQL to ClickHouse的遷移。

遷移任務配置和檢視

•首先，進入DBMotion的頁面，點選免費使用。  

•登入DBMotion的任務列表頁面。

•單擊“新增任務”按鈕，進入“源端目標庫配置”。

為方便展示，這裡選擇的是在公網ECS上建立的MySQL和ClickHouse。

注意：這裡的源庫與目標庫的使用者、許可權，建議按照授權語句的要求，在源庫和目標庫新建使用者，

否則後面的預檢查和遷移有可能會失敗。遷移完成後，就可以將源端和目標端的使用者刪除。

 

•點選“測試連線以進行下一步”，進入“遷移選項配置”頁。

這裡可以展開選擇你要同步的表，選擇併發數和遷移哪些MySQL的表到目標端。  

•最後，使用者確認配置並進行預檢查。

這一步可以看到使用者選擇的是哪些內容，而且預檢查會提前發現一些可能導致遷移失敗的問題 。  

這個確認頁面內容豐富，涵蓋了源庫、目標庫和要遷移的物件的資訊。還會主動預檢查所有可能導致遷移失敗的點，

出現問題時會發出提醒，並給出修復建議，是一個比較方便的功能。

•能看到新建任務成功，點選任務就可以進入任務詳情頁面 。  

•在任務配置頁面，可以看到這次遷移同步任務的源庫、目標庫和遷移物件資訊，之前的預檢查資訊也可以在這裡回顧。

 

遷移詳情主要包括“物件遷移”、“全量遷移”、“增量遷移”和“資料校驗”。

•物件遷移。 

以這兩個測試表為例，將物件同步過去的速度是比較快的。物件遷移，DBMotion具體同步的內容，我們看目標庫上的

表 和資料的時候可以看到。  

•全量遷移。

兩個表的資料不多，同步的速度較快。 

這裡每個步驟都有遷移進度、遷移速度、已遷移時間、預計剩餘時間，對於遷移的進展和大概需要多少時間，一目瞭然。

•增量遷移。 

記錄了同步的binlog位點資訊。

 

•資料校驗。 

這個功能是其他相關產品沒有的功能，會校驗MySQL和ClickHouse的表和資料。對於需要精確匹配的遷移來說，

是一個很實用的功能。 

 

•結束遷移。 

結束遷移是為了關閉增量，保證遷移完成以後，就可以結束遷移了。

•任務日誌。

在遷移報錯的時候，用來檢查到底是哪個環節出現了問題。  

總體來看，這個操作是比較簡單的。只需要 配置好源端、目標端和遷移物件，它就會幫你建立好遷移任務。

任務展示頁面也比較清晰明瞭，同步了哪些內容，資料是否一致都有比較好的展現。

實際遷移結果

接下來，我們來看它的實際遷移結果。

全量遷移

•源庫表結構。 

源庫上test_grant1.test1表的表結構如下： 

 

•目標庫表結構。

遷移完成後，在目標庫裡看，DBMotion新建了兩個schema，test_grant1和test_grant1_ck，並分別在這兩個schema下

新建了test1_ck表和test1表，對應的表結構如下： 

 

這一步，DBMotion應該是參考ClickHouse原生解決方案MaterializedMySQL來實現的。解釋一下：

•test_grant1_ck.test1_ck是ReplacingMergeTree的表，除了a,b兩列以外，還有__version@@和__event_type@@，

對應_version和_sign兩個欄位。

•為了方便使用者使用，在目標庫上專門新建了test_grant1.test1的檢視，讓使用者查詢的時候，看到的資料和源庫一致。

前面的“物件遷移”到底遷移了什麼內容，這裡也有答案了。

增量遷移

我們測試了一下在源庫上做增刪改的操作，在目標庫上檢視同步效果，發現同步延遲基本在秒級別，同步的資料也完全一致。

•源庫增刪改查。

•目標庫檢視資料。

 

這裡可以明顯看到，test_grant1_ck.test1_ck中記錄的是源庫做的所有DML操作，透過檢視合併後，test_grant1.test1查詢

出來的資料跟源庫一模一樣。

PS：B站上有一個DBMotion的介紹影片，不喜歡看文字的，可以看這個影片瞭解一下它的安裝和使用方式。

總結

•MySQL to Clickhouse，目前有ClickHouse原生提供的同步工具、命令列同步工具和介面指引型同步工具。

原生的工具暫時不能用在生產環境，命令列工具使用起來比較繁瑣，介面型相對簡單易用。

•介面型同步工具中，DBMotion相對比較直觀簡單。

•這些工具對DDL、無主鍵表都有一些限制，這些問題我將在另外一篇文章裡面詳細描述。