：基于MySQL binlog的增量數(shù)據(jù)同步全解析)
1. 先搞清楚canal到底在解決什么問題如果說這兩年數(shù)據(jù)同步領(lǐng)域哪個組件最值得花一個星期認真學(xué)一遍我的答案一定是canal。這名字你可能在簡歷上見過在招聘JD里見過甚至在同事的代碼評審里被吐槽過但真要問你它到底是干嘛的很多人的回答其實是模糊的嗯就是同步MySQL數(shù)據(jù)的——差不多對但不夠準確。我換個說法你就明白了canal做的是MySQL增量數(shù)據(jù)訂閱也就是監(jiān)聽MySQL的binlog日志每當(dāng)數(shù)據(jù)庫里發(fā)生insert、update、delete操作canal就能像裝了竊聽器一樣在毫秒級把這個變更事件推給你。注意關(guān)鍵詞是增量——它不是全量復(fù)制不是每天導(dǎo)一次數(shù)據(jù)而是從你部署那一刻開始實時關(guān)注每一條新變化。那它解決的到底是什么問題我舉個最常見的場景。你們系統(tǒng)里肯定有一張熱點表比如商品信息、用戶資料、配置數(shù)據(jù)業(yè)務(wù)方讀得很頻繁。為了扛住流量你引入了Redis做緩存查詢走緩存寫操作更新數(shù)據(jù)庫。聽起來沒問題但更新數(shù)據(jù)庫的同時同步緩存這一步寫法稍微不嚴謹就會出現(xiàn)緩存和數(shù)據(jù)庫不一致的臟數(shù)據(jù)。常見的做法有幾種雙寫、定時任務(wù)全量刷新、消息隊列異步通知。雙寫邏輯侵入業(yè)務(wù)代碼定時任務(wù)有延遲且浪費資源消息隊列異步通知倒是好但你需要手動把每一次數(shù)據(jù)變更封裝成消息發(fā)出去代碼量不小。canal的思路是我不碰你的業(yè)務(wù)代碼我在數(shù)據(jù)庫這一側(cè)偷聽binlog把變更事件統(tǒng)一抓出來再推給你的下游。無論你是想去同步緩存、同步到ES、同步到數(shù)據(jù)倉庫還是同步到另一個MySQL都不需要改業(yè)務(wù)代碼。這個解耦的價值用過的人都懂——只需要一次配置全公司的數(shù)據(jù)消費方都能受益。對小白來說canal最友好的一點是它自帶一個客戶端訂閱模型你只要能寫Java代碼幾行就能跑通一個Demo完全不需要一開始就理解它的存儲原理。但如果你想用好它光是會跑肯定不夠因為真正的坑全在細節(jié)里binlog格式?jīng)]配對、位點丟失導(dǎo)致重復(fù)消費、和多個訂閱端搶數(shù)據(jù)……這些問題我用后面幾個章節(jié)慢慢展開。順便說一句canal項目的名稱來自canal這個英文單詞中文意思是運河、水道寓意很直白數(shù)據(jù)從MySQL流向下游的通道。這個比喻特別貼切你越往后用越會覺得它真的就像一條管道把數(shù)據(jù)庫的血液輸送到各個需要的地方。2. 安裝前的三個關(guān)鍵開關(guān)JDK、binlog和權(quán)限安裝canal本身不難難的是準備工作。很多小白按照網(wǎng)上的教程一步步來結(jié)果客戶端連不上、收不到消息回頭一看全是配套環(huán)境沒弄對。所以這一章我把安裝前置條件拆成三個開關(guān)每個都要提前確認壞了哪一個都會讓你后面抓狂。2.1 第一個開關(guān)JDK版本canal的server端是Java寫的所以你機器上得有JDK。這里有個坑需要你避一下canal 1.1.x系列用JDK 8沒問題但如果你用的是比較新的canal 1.1.7版本或者想跑源碼調(diào)試建議直接用JDK 11。我遇到過用JDK 8跑新版本canal啟動的時候報了一些奇怪的并發(fā)類加載錯誤看起來像是代碼問題其實是編譯目標版本太高導(dǎo)致的。裝好之后確認一下版本java -version正常情況下你會看到類似openjdk version 1.8.0_***或openjdk version 11.0.***的輸出。如果你的機器上存在多個JDK建議用export JAVA_HOME/path/to/jdk指定清楚避免canal的啟動腳本拿到錯誤的版本。2.2 第二個開關(guān)MySQL必須開啟binlogcanal的工作原理是偽裝成MySQL的從節(jié)點向主庫請求binlog日志。所以你的MySQL必須開啟binlog這是整個鏈條的源頭。修改MySQL配置文件Linux下一般是/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf[mysqld] log-binmysql-bin binlog-formatROW server-id1這三行缺一不可尤其第二行binlog-formatROW。我見過有人在測試環(huán)境用了默認的STATEMENT格式結(jié)果canal解析出來一堆SQL語句根本拿不到精確的行級變更數(shù)據(jù)。因為canal的核心輸出是某行某個字段從舊值變成了新值而這種結(jié)構(gòu)化信息只有ROW格式才完整保留。改完之后記得重啟MySQLservice mysqld restart或者systemctl restart mysqld。然后進入MySQL命令行驗證SHOW VARIABLES LIKE log_bin; SHOW VARIABLES LIKE binlog_format;兩個結(jié)果都符合預(yù)期這個開關(guān)才算真正打開。還有一個細節(jié)容易被忽略server-id不能和canal實例配置的server-id重復(fù)。我用一個真實的踩坑經(jīng)歷說明第一次部署的時候我隨手給canal設(shè)置了server-id1和MySQL自己的server-id沖突結(jié)果canal連接主庫時直接被拒日志里報ERROR: Got error 1236。這個問題排查了很久才定位到因為報錯信息很不直觀。所以提前規(guī)劃好MySQL給一個server-idcanal給另一個比如101、102這種互不干擾。2.3 第三個開關(guān)MySQL授權(quán)賬號canal需要用一個專門的MySQL賬號連接主庫這個賬號要有REPLICATION SLAVE和REPLICATION CLIENT權(quán)限。很多人在這步直接用root賬號倒也能跑通但從規(guī)范角度不推薦尤其到了生產(chǎn)環(huán)境最少權(quán)限原則是底線。創(chuàng)建賬號的SQL如下CREATE USER canal% IDENTIFIED BY canal123; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO canal%; FLUSH PRIVILEGES;這里給%是允許任意主機連接實際生產(chǎn)建議限定為運行canal的那臺機器IP安全第一。另外注意如果數(shù)據(jù)庫里已有的表結(jié)構(gòu)比較復(fù)雜canal在解析DDL事件時可能還需要訪問表定義所以順手把SELECT權(quán)限也加上。這三件事做完環(huán)境準備基本就緒。老實說這個過程十分鐘都用不了但價值遠超十分鐘——它決定了你后面所有排查動作能不能有一個干凈的基礎(chǔ)。3. 一條數(shù)據(jù)從MySQL到客戶端的完整路徑很多教程上來就讓你裝canal、跑Demo等你跑通了還是一頭霧水它到底是怎么拿到數(shù)據(jù)的這一章我從原理層面完整講一遍大概需要你花五分鐘耐心讀讀完之后你就擁有了排查問題的底層地圖遇到任何詭異現(xiàn)象都能知道往哪個環(huán)節(jié)去查。3.1 先理解MySQL主從復(fù)制是怎么回事canal的核心機制其實是在模仿MySQL的從庫。MySQL的主從復(fù)制過程很簡單主庫把每一次變更寫入binlog從庫連接到主庫請求從某個binlog位點開始的數(shù)據(jù)拿到之后在本地重放。canal做的事情和從庫一模一樣只不過它拿到這些日志之后重放的不是SQL而是把日志解析成結(jié)構(gòu)化的數(shù)據(jù)變更事件交給下游程序處理。這個過程涉及binlog里的幾個概念我用大白話解釋一下binlog文件MySQL落盤生成的日志文件比如mysql-bin.000001達到一定大小后自動切換下一個文件。binlog位點position一條日志在文件中的偏移量它是唯一的?？蛻舳嘶謴?fù)消費時只要記住上次消費到的position就能從斷點繼續(xù)。GTID全局事務(wù)ID是比position更高級的定位方式不依賴具體文件名和偏移量。新版本canal推薦用GTID模式主從切換時能自動適應(yīng)。3.2 canal內(nèi)部的三段式流水線canal從拿到binlog到吐出數(shù)據(jù)內(nèi)部經(jīng)歷了三個核心階段第一階段抓取Parser。canal偽裝成從庫向MySQL發(fā)送dump協(xié)議請求。MySQL就會從指定的binlog位點開始把日志一條條推送給canal。這個階段最純粹只負責(zé)拿。第二階段解析Sink。拿到的binlog是事件流需要解析。比如一個UPDATE事件會解析出舊值before和新值after這個是canal最有價值的輸出——下游可以直接拿到{id: 1, name: 舊值}變成{id: 1, name: 新值}這樣的JSON數(shù)據(jù)而不需要自己拼SQL去反查。第三階段存儲Store。解析完成后事件會寫入一個內(nèi)存環(huán)形隊列等待客戶端來拉取。canal內(nèi)置了一個基于內(nèi)存的存儲組件默認容量是16384個事件客戶端消費速度跟不上時事件會在內(nèi)存里排隊排滿了之后才會出現(xiàn)丟數(shù)據(jù)或者阻塞的情況。整個鏈條如下圖所示文字版MySQL binlog → canal Server 抓取 → 解析 → 內(nèi)存隊列 → 客戶端(Client) 拉取 → 你的業(yè)務(wù)代碼/ES/Redis...3.3 你眼里的canal組件Server、Instance和Client實際部署時你會接觸到幾個概念這里一次性講清楚避免后續(xù)被配置項繞暈canal Server一個獨立運行的Java進程核心服務(wù)。canal InstanceServer內(nèi)部的一個邏輯實例每個Instance對應(yīng)一個MySQL數(shù)據(jù)源。一個Server可以配置多個Instance每個Instance有獨立的配置、獨立的訂閱位點、獨立的隊列。canal Client你寫的消費端程序通過TCP協(xié)議從Server拉取數(shù)據(jù)。打個比方Server是餐廳Instance是廚房里的一個灶臺——每個灶臺對應(yīng)一個供應(yīng)商MySQLClient是來吃飯的顧客。一個餐廳有多個灶臺很正常每個灶臺負責(zé)炒不同的菜互不干擾。從部署角度小白剛開始只需要一個Server、一個Instance、一個Client后面需要訂閱多個庫或者對接多套下游時再考慮多Instance。4. 跑通第一個Demo用Java代碼訂閱一條insert前面講了那么多理論和準備這一章我們真正動手。我用一臺Linux機器做演示canal部署包從官方GitHub Release頁面下載最新穩(wěn)定版即可解壓后目錄結(jié)構(gòu)大致如下/canal ├── bin ├── conf │ ├── canal.properties │ ├── example │ │ └── instance.propertiesconf/canal.properties是全局配置conf/example是默認實例的配置目錄instance.properties是實例級配置。4.1 修改實例配置先改instance.properties這是核心# MySQL主庫地址 canal.instance.master.address127.0.0.1:3306 # 連接MySQL的賬號密碼 canal.instance.dbUsernamecanal canal.instance.dbPasswordcanal123 # 訂閱的數(shù)據(jù)庫和表*表示所有 canal.instance.filter.regextest\\..* # 位點定位方式 canal.instance.gtidfalse重點說明一下filter.regex這個配置。它的格式是數(shù)據(jù)庫名\\..*比如我只想訂閱test庫的所有表就寫test\\..*想訂閱test庫下的user表就寫test\\.user想訂閱多個庫用|分隔。這個正則很容易寫錯因為Java字符串本身也要轉(zhuǎn)義所以\\.寫成\\.而不是\.。我見過有人照抄配置把轉(zhuǎn)義符弄丟了結(jié)果canal直接不輸出任何數(shù)據(jù)查了半天才發(fā)現(xiàn)是正則匹配問題。4.2 修改全局配置再看canal.properties重點確認以下幾項canal.port11111 canal.destinationsexample canal.instance.global.modetcpcanal.port是客戶端連接的TCP端口默認11111不用改。canal.destinations指定啟動哪些實例默認example對應(yīng)conf目錄下的example文件夾。canal.instance.global.modetcp表示消費端通過TCP直連方式拉取數(shù)據(jù)——這是最簡單的方式后面聊MQ模式時再說。4.3 啟動Servercd /canal/bin ./startup.sh啟動后看日志確認沒有異常tail -f /canal/logs/canal/canal.log如果看到canal server is running now之類的字樣并且沒有報錯說明Server起來了。再檢查實例狀態(tài)tail -f /canal/logs/example/example.log正常情況下能看到start successful。這里有個新手最容易遇到的情況日志里顯示canal is starting然后卡住不動多半是MySQL連接沒通去查example.log里有沒有connect timeout或者Access denied字樣。4.4 寫一個最小客戶端canal官方提供了一個客戶端庫canal.client用Maven引入dependency groupIdcom.alibaba.otter/groupId artifactIdcanal.client/artifactId version1.1.7/version /dependency然后寫一個最簡單的Java類核心邏輯是建立連接 → 拉取消息 → 解析事件 → 打印變更內(nèi)容。import com.alibaba.otter.canal.client.CanalConnector; import com.alibaba.otter.canal.client.CanalConnectors; import com.alibaba.otter.canal.protocol.Message; import com.alibaba.otter.canal.protocol.CanalEntry; import com.alibaba.otter.canal.protocol.CanalEntry.EntryType; import java.net.InetSocketAddress; import java.util.List; public class CanalDemo { public static void main(String[] args) { // 連接canal server CanalConnector connector CanalConnectors.newSingleConnector( new InetSocketAddress(127.0.0.1, 11111), example, // instance名稱 , // 無認證時填空 ); connector.connect(); // 訂閱所有表這里要和instance的filter.regex對應(yīng) connector.subscribe(test\\..*); while (true) { // 一次拉取100條不設(shè)置超時 Message message connector.getWithoutAck(100); long batchId message.getId(); if (batchId -1 || message.getEntries().isEmpty()) { // 沒有數(shù)據(jù)睡1秒再試 try { Thread.sleep(1000); } catch (InterruptedException e) {} continue; } for (CanalEntry.Entry entry : message.getEntries()) { if (entry.getEntryType() ! EntryType.ROWDATA) { continue; } CanalEntry.RowChange rowChange CanalEntry.RowChange.parseFrom(entry.getStoreValue()); CanalEntry.EventType eventType rowChange.getEventType(); for (CanalEntry.RowData rowData : rowChange.getRowDatasList()) { if (eventType CanalEntry.EventType.INSERT) { System.out.println(INSERT: rowData.getAfterColumnsList()); } else if (eventType CanalEntry.EventType.UPDATE) { System.out.println(UPDATE before: rowData.getBeforeColumnsList()); System.out.println(UPDATE after: rowData.getAfterColumnsList()); } else if (eventType CanalEntry.EventType.DELETE) { System.out.println(DELETE: rowData.getBeforeColumnsList()); } } } // 確認消費成功 connector.ack(batchId); } } }這段代碼看著有點長但核心就三件事連接、拉取、確認。所有canal客戶端的骨架都是這個模式你以后無論用Spring Boot封裝還是寫其他語言的客戶端都逃不開這個套路。4.5 實測驗證運行上面的Java類然后在MySQL里執(zhí)行INSERT INTO test.user (name, age) VALUES (張三, 25);立刻就能在控制臺看到類似下面的輸出INSERT: [name: 張三, age: 25]看到這一行你的canal入門第一個Demo就算真正跑通了。從這一刻起任何數(shù)據(jù)庫變更都會實時出現(xiàn)在你的消費端面前剩下的就是你怎么利用這些數(shù)據(jù)了。5. 小白最容易踩的五個坑含完整排查思路說實話canal的部署和Demo真的很簡單但越是這種看起來簡單的組件越容易在細節(jié)上翻車。這一章我把自己和周圍人踩過的坑整理出來每一項都附上排查鏈路而不是直接給結(jié)論——因為下次你遇到的可能只是個相似但不完全一樣的問題思路比答案更重要。5.1 坑一binlog格式不是ROW解析結(jié)果全是SQL現(xiàn)象客戶端能連上能收到消息但解析出來的RowData是空的只有SQL語句。排查鏈路第一步回到MySQL執(zhí)行SHOW VARIABLES LIKE binlog_format;如果結(jié)果是STATEMENT或MIXED基本就是問題所在。第二步修改配置為ROW重啟MySQL。第三步重新執(zhí)行一條INSERT看canal是否輸出結(jié)構(gòu)化的列值。根因只有ROW格式才會記錄每一行變更的具體列值STATEMENT格式記錄的是原始SQL文本canal無法從中還原出行級別數(shù)據(jù)。5.2 坑二server-id沖突導(dǎo)致連接被拒現(xiàn)象canal日志里出現(xiàn)ERROR: Got error 1236或者直接連接不上MySQL。排查鏈路第一步檢查MySQL的server-idSELECT server_id;第二步檢查canal的canal.instance.properties里有沒有canal.instance.mysql.slaveId配置項這個值默認是123456。如果和MySQL的server-id一樣就改成一個不同的值比如654321。第三步重啟canal實例觀察日志。根因MySQL主從復(fù)制機制要求每個從節(jié)點的server-id必須全局唯一。canal偽裝成一個從節(jié)點如果它的server-id和MySQL主庫相同主庫會認為這是我自己直接拒絕復(fù)制請求。這里插一句生產(chǎn)中很多人會忽略這個參數(shù)因為它的默認值看起來沒存在感。建議部署清單里專門加一行確認slaveId與所有MySQL節(jié)點均不重復(fù)。5.3 坑三位點丟失導(dǎo)致重復(fù)消費或漏消費現(xiàn)象canal重啟后客戶端收到了之前已經(jīng)處理過的舊數(shù)據(jù)或者直接跳過了部分數(shù)據(jù)。排查鏈路第一步確認canal的meta信息存儲在哪里。默認情況下位點存在內(nèi)存中Server重啟就會丟失從當(dāng)前最新位置開始消費。如果你需要持久化要在canal.properties里配置canal.instance.global.spring.xmlclasspath:spring/memory-instance.xml改為file-instance.xml可以把meta寫到本地文件。第二步檢查客戶端代碼是否正確ack。只get不ack重啟后會從上次ack的位置重新拉取產(chǎn)生重復(fù)消費ack太快也可能出問題如果先ack再處理業(yè)務(wù)邏輯處理失敗時數(shù)據(jù)就再也拉不回來了這是至少一次語義下最常見的取舍。第三步設(shè)計消費冪等。無論位點多可靠分布式環(huán)境下重復(fù)消費幾乎不可避免所以消費端的冪等才是最終兜底。根因canal的位點機制是經(jīng)典的有且至少一次消費語義重復(fù)消費是常態(tài)漏消費是因為位點推進到了業(yè)務(wù)成功之前。5.4 坑四多個客戶端實例同時消費同一個instance現(xiàn)象多個服務(wù)實例都連了同一個canal destination結(jié)果每條數(shù)據(jù)只被其中一個實例收到而不是每個實例都收到。排查鏈路第一步確認你的業(yè)務(wù)訴求是廣播還是負載均衡。canal不保證多個client同時消費時每個client都能拿到全量數(shù)據(jù)默認是競爭消費——一條數(shù)據(jù)只會給一個client。第二步如果確實需要多個下游分別消費同一份數(shù)據(jù)可以有三種方案一是每個下游對應(yīng)一個獨立的instance二是通過MQ模式發(fā)布訂閱三是使用canal的CanalMQStarter配多個不同的group。根因canal的tcp模式的定位是一個destination對應(yīng)一個消費組多個client是在消費組內(nèi)競爭拉取不是復(fù)制分發(fā)。5.5 坑五DDL事件和事務(wù)邊界導(dǎo)致的數(shù)據(jù)異常現(xiàn)象執(zhí)行ALTER TABLE之后消費端收到的數(shù)據(jù)突然解析失敗或者一個事務(wù)內(nèi)的多變更變得不完整。排查鏈路第一步檢查消費端是否處理了EntryType.ROWDATA之外的事件。DDL事件屬于ENTRY_TYPE的其他類型如果你在消費端直接跳過所有非ROWDATA事件DDL對下游可能造成結(jié)構(gòu)不一致。第二步開啟canal的并行消費時要注意事務(wù)一致性。如果下游是數(shù)據(jù)庫或緩存建議按事務(wù)邊界整體提交避免同一個事務(wù)的變更被拆到不同地方執(zhí)行。根因canal按事務(wù)為單位讀取binlog但消費端如果并行處理事務(wù)邊界會被人為拆散。這五個坑基本覆蓋了我見過的90%小白問題。說實話每個坑背后都對應(yīng)一個理解盲區(qū)不是性能問題不是bug而是對canal是怎么工作的理解不到位。所以每次出問題先回到第3章的原理圖里定位是在哪個環(huán)節(jié)排查速度會快很多。6. 進階思路從單機Demo走向生產(chǎn)環(huán)境Demo跑通、坑也避開之后你可能會問那真實項目里一般怎么用這一章我講三個最常用的落地方向以及小白從單機走向生產(chǎn)時需要補的功課。6.1 實戰(zhàn)方向一數(shù)據(jù)庫變更同步到Redis這是canal最常見的用法。假設(shè)你的商品表product里有價格字段價格變了緩存也得變。傳統(tǒng)做法是改業(yè)務(wù)代碼在更新數(shù)據(jù)庫后刪除緩存用canal之后消費端收到UPDATE事件直接從JSON里提取最新值執(zhí)行SET key value或者刪除緩存。業(yè)務(wù)代碼零侵入。要注意兩點第一canal發(fā)來的是列名值的結(jié)構(gòu)不是SQL所以你需要自己把變更映射成業(yè)務(wù)對象這個映射邏輯一般寫在消費端一個獨立模塊里第二如果變更頻繁要注意給緩存加防抖比如1秒內(nèi)同一行的多次變更合并成一次刷緩存避免抖動。6.2 實戰(zhàn)方向二異構(gòu)數(shù)據(jù)同步到Elasticsearch把MySQL的數(shù)據(jù)同步到ES做全文檢索也是高頻場景。流程大致是canal監(jiān)聽MySQL變更 → 消費端把變更拼成ES文檔 → 調(diào)用ES的index/update接口。這里有個常見的設(shè)計問題ES里可能需要寬表比如訂單文檔里要包含用戶名、商品名而這些字段來自其他表。如果只訂閱訂單表拿不到關(guān)聯(lián)信息。解決思路有兩個一是訂閱多張表在消費端做內(nèi)存關(guān)聯(lián)二是讓業(yè)務(wù)方寫出包含所有所需字段的預(yù)聚合表canal只訂閱這一張。第二個方案更簡單可靠推薦小白先這么做。6.3 從單機到集群三個生產(chǎn)級配置生產(chǎn)環(huán)境不可能只跑一個單機canal但我也要提醒你一開始別急著上集群先把下面三件事做好比盲目加機器更有價值。第一個是位點持久化。前面說過默認位點在內(nèi)存在Server重啟就丟。生產(chǎn)環(huán)境務(wù)必配置成file模式或zookeeper模式。我用的是file模式最簡單但要注意磁盤空間和文件權(quán)限。第二個是訂閱粒度收斂。開發(fā)環(huán)境訂閱所有庫所有表沒問題生產(chǎn)環(huán)境一定要用filter.regex收窄到具體業(yè)務(wù)庫和表不然會白白消耗大量性能還可能把其他團隊的數(shù)據(jù)變更也帶進你的消費邏輯。第三個是監(jiān)控告警。canal是實時鏈路一旦它停了下游全部數(shù)據(jù)滯后。至少要做到進程存活監(jiān)控、消費延遲監(jiān)控canal有delayed指標、客戶端積壓消息數(shù)監(jiān)控。這些指標都可以通過JMX或者集成到現(xiàn)有監(jiān)控系統(tǒng)里別等業(yè)務(wù)方來問為什么數(shù)據(jù)還沒同步過來你才發(fā)現(xiàn)問題。至于集群模式canal支持多Server ZooKeeper的HA方案多個instance由ZK協(xié)調(diào)一臺掛了自動切換到另一臺。這個配置本身不復(fù)雜但我建議在你的業(yè)務(wù)真正需要高可用之前先把單機的監(jiān)控和運維做扎實因為集群也解決不了消費端邏輯的bug。7. 最后的實用建議這一章不聊原理、不聊配置就說一些零散但真實的經(jīng)驗。第一開發(fā)環(huán)境一定要把binlog打開。我見過不少團隊本地MySQL默認沒開binlog結(jié)果canal跑不起來排查半天發(fā)現(xiàn)是本地環(huán)境的鍋。你可以在MySQL配置里直接默認開啟對開發(fā)環(huán)境性能影響微乎其微。第二消費端一定要做冪等。不管你用哪種位點配置重復(fù)消費都是可能發(fā)生的所以消費邏輯必須能反復(fù)執(zhí)行而結(jié)果一致。比如同步到ES用文檔ID做upsert天然冪等同步到Redis覆蓋寫本來就冪等同步到另一個MySQL用主鍵做INSERT ... ON DUPLICATE KEY UPDATE就能保證不炸。第三binlog里的時間字段要小心。canal解析出的時間字段默認是字符串格式時區(qū)可能有偏移。如果你發(fā)現(xiàn)同步的數(shù)據(jù)在時間上差了8個小時去檢查canal的時區(qū)配置。第四測試的時候別只測INSERT。我見過有人Demo只驗證了insert就以為一切正常結(jié)果上線后update和delete全沒處理數(shù)據(jù)越差越多。測試至少覆蓋增刪改三種事件最好再測一個事務(wù)里多條變更的順序性。最后說一句掏心窩的話canal入門真的不難難的是你要理解它和業(yè)務(wù)系統(tǒng)的邊界在哪里。它能幫你解決數(shù)據(jù)同步但它不會幫你把下游的消費邏輯寫好也不會幫你兜住消費端拋出的異常。把它當(dāng)成一個可靠的數(shù)據(jù)搬運工真正干活的內(nèi)容還是要靠你精心設(shè)計消費端來處理。我用canal做了好幾個項目的增量同步從最開始照貓畫虎跑通Demo到現(xiàn)在能快速定位各種奇怪問題最大的感受就是工具本身只是管道關(guān)鍵還是對數(shù)據(jù)變化鏈路有一顆敬畏之心。希望你也能順著這篇文章跑通自己的第一個Demo然后在這個基礎(chǔ)上一步步把數(shù)據(jù)流動做得更穩(wěn)、更優(yōu)雅。 Canal實戰(zhàn)：基于MySQL binlog的增量數(shù)據(jù)同步全解析
1. 先搞清楚canal到底在解決什么問題如果說這兩年數(shù)據(jù)同步領(lǐng)域哪個組件最值得花一個星期認真學(xué)一遍我的答案一定是canal。這名字你可能在簡歷上見過在招聘JD里見過甚至在同事的代碼評審里被吐槽過但真要問你它到底是干嘛的很多人的回答其實是模糊的嗯就是同步MySQL數(shù)據(jù)的——差不多對但不夠準確。我換個說法你就明白了canal做的是MySQL增量數(shù)據(jù)訂閱也就是監(jiān)聽MySQL的binlog日志每當(dāng)數(shù)據(jù)庫里發(fā)生insert、update、delete操作canal就能像裝了竊聽器一樣在毫秒級把這個變更事件推給你。注意關(guān)鍵詞是增量——它不是全量復(fù)制不是每天導(dǎo)一次數(shù)據(jù)而是從你部署那一刻開始實時關(guān)注每一條新變化。那它解決的到底是什么問題我舉個最常見的場景。你們系統(tǒng)里肯定有一張熱點表比如商品信息、用戶資料、配置數(shù)據(jù)業(yè)務(wù)方讀得很頻繁。為了扛住流量你引入了Redis做緩存查詢走緩存寫操作更新數(shù)據(jù)庫。聽起來沒問題但更新數(shù)據(jù)庫的同時同步緩存這一步寫法稍微不嚴謹就會出現(xiàn)緩存和數(shù)據(jù)庫不一致的臟數(shù)據(jù)。常見的做法有幾種雙寫、定時任務(wù)全量刷新、消息隊列異步通知。雙寫邏輯侵入業(yè)務(wù)代碼定時任務(wù)有延遲且浪費資源消息隊列異步通知倒是好但你需要手動把每一次數(shù)據(jù)變更封裝成消息發(fā)出去代碼量不小。canal的思路是我不碰你的業(yè)務(wù)代碼我在數(shù)據(jù)庫這一側(cè)偷聽binlog把變更事件統(tǒng)一抓出來再推給你的下游。無論你是想去同步緩存、同步到ES、同步到數(shù)據(jù)倉庫還是同步到另一個MySQL都不需要改業(yè)務(wù)代碼。這個解耦的價值用過的人都懂——只需要一次配置全公司的數(shù)據(jù)消費方都能受益。對小白來說canal最友好的一點是它自帶一個客戶端訂閱模型你只要能寫Java代碼幾行就能跑通一個Demo完全不需要一開始就理解它的存儲原理。但如果你想用好它光是會跑肯定不夠因為真正的坑全在細節(jié)里binlog格式?jīng)]配對、位點丟失導(dǎo)致重復(fù)消費、和多個訂閱端搶數(shù)據(jù)……這些問題我用后面幾個章節(jié)慢慢展開。順便說一句canal項目的名稱來自canal這個英文單詞中文意思是運河、水道寓意很直白數(shù)據(jù)從MySQL流向下游的通道。這個比喻特別貼切你越往后用越會覺得它真的就像一條管道把數(shù)據(jù)庫的血液輸送到各個需要的地方。2. 安裝前的三個關(guān)鍵開關(guān)JDK、binlog和權(quán)限安裝canal本身不難難的是準備工作。很多小白按照網(wǎng)上的教程一步步來結(jié)果客戶端連不上、收不到消息回頭一看全是配套環(huán)境沒弄對。所以這一章我把安裝前置條件拆成三個開關(guān)每個都要提前確認壞了哪一個都會讓你后面抓狂。2.1 第一個開關(guān)JDK版本canal的server端是Java寫的所以你機器上得有JDK。這里有個坑需要你避一下canal 1.1.x系列用JDK 8沒問題但如果你用的是比較新的canal 1.1.7版本或者想跑源碼調(diào)試建議直接用JDK 11。我遇到過用JDK 8跑新版本canal啟動的時候報了一些奇怪的并發(fā)類加載錯誤看起來像是代碼問題其實是編譯目標版本太高導(dǎo)致的。裝好之后確認一下版本java -version正常情況下你會看到類似openjdk version 1.8.0_***或openjdk version 11.0.***的輸出。如果你的機器上存在多個JDK建議用export JAVA_HOME/path/to/jdk指定清楚避免canal的啟動腳本拿到錯誤的版本。2.2 第二個開關(guān)MySQL必須開啟binlogcanal的工作原理是偽裝成MySQL的從節(jié)點向主庫請求binlog日志。所以你的MySQL必須開啟binlog這是整個鏈條的源頭。修改MySQL配置文件Linux下一般是/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf[mysqld] log-binmysql-bin binlog-formatROW server-id1這三行缺一不可尤其第二行binlog-formatROW。我見過有人在測試環(huán)境用了默認的STATEMENT格式結(jié)果canal解析出來一堆SQL語句根本拿不到精確的行級變更數(shù)據(jù)。因為canal的核心輸出是某行某個字段從舊值變成了新值而這種結(jié)構(gòu)化信息只有ROW格式才完整保留。改完之后記得重啟MySQLservice mysqld restart或者systemctl restart mysqld。然后進入MySQL命令行驗證SHOW VARIABLES LIKE log_bin; SHOW VARIABLES LIKE binlog_format;兩個結(jié)果都符合預(yù)期這個開關(guān)才算真正打開。還有一個細節(jié)容易被忽略server-id不能和canal實例配置的server-id重復(fù)。我用一個真實的踩坑經(jīng)歷說明第一次部署的時候我隨手給canal設(shè)置了server-id1和MySQL自己的server-id沖突結(jié)果canal連接主庫時直接被拒日志里報ERROR: Got error 1236。這個問題排查了很久才定位到因為報錯信息很不直觀。所以提前規(guī)劃好MySQL給一個server-idcanal給另一個比如101、102這種互不干擾。2.3 第三個開關(guān)MySQL授權(quán)賬號canal需要用一個專門的MySQL賬號連接主庫這個賬號要有REPLICATION SLAVE和REPLICATION CLIENT權(quán)限。很多人在這步直接用root賬號倒也能跑通但從規(guī)范角度不推薦尤其到了生產(chǎn)環(huán)境最少權(quán)限原則是底線。創(chuàng)建賬號的SQL如下CREATE USER canal% IDENTIFIED BY canal123; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO canal%; FLUSH PRIVILEGES;這里給%是允許任意主機連接實際生產(chǎn)建議限定為運行canal的那臺機器IP安全第一。另外注意如果數(shù)據(jù)庫里已有的表結(jié)構(gòu)比較復(fù)雜canal在解析DDL事件時可能還需要訪問表定義所以順手把SELECT權(quán)限也加上。這三件事做完環(huán)境準備基本就緒。老實說這個過程十分鐘都用不了但價值遠超十分鐘——它決定了你后面所有排查動作能不能有一個干凈的基礎(chǔ)。3. 一條數(shù)據(jù)從MySQL到客戶端的完整路徑很多教程上來就讓你裝canal、跑Demo等你跑通了還是一頭霧水它到底是怎么拿到數(shù)據(jù)的這一章我從原理層面完整講一遍大概需要你花五分鐘耐心讀讀完之后你就擁有了排查問題的底層地圖遇到任何詭異現(xiàn)象都能知道往哪個環(huán)節(jié)去查。3.1 先理解MySQL主從復(fù)制是怎么回事canal的核心機制其實是在模仿MySQL的從庫。MySQL的主從復(fù)制過程很簡單主庫把每一次變更寫入binlog從庫連接到主庫請求從某個binlog位點開始的數(shù)據(jù)拿到之后在本地重放。canal做的事情和從庫一模一樣只不過它拿到這些日志之后重放的不是SQL而是把日志解析成結(jié)構(gòu)化的數(shù)據(jù)變更事件交給下游程序處理。這個過程涉及binlog里的幾個概念我用大白話解釋一下binlog文件MySQL落盤生成的日志文件比如mysql-bin.000001達到一定大小后自動切換下一個文件。binlog位點position一條日志在文件中的偏移量它是唯一的?？蛻舳嘶謴?fù)消費時只要記住上次消費到的position就能從斷點繼續(xù)。GTID全局事務(wù)ID是比position更高級的定位方式不依賴具體文件名和偏移量。新版本canal推薦用GTID模式主從切換時能自動適應(yīng)。3.2 canal內(nèi)部的三段式流水線canal從拿到binlog到吐出數(shù)據(jù)內(nèi)部經(jīng)歷了三個核心階段第一階段抓取Parser。canal偽裝成從庫向MySQL發(fā)送dump協(xié)議請求。MySQL就會從指定的binlog位點開始把日志一條條推送給canal。這個階段最純粹只負責(zé)拿。第二階段解析Sink。拿到的binlog是事件流需要解析。比如一個UPDATE事件會解析出舊值before和新值after這個是canal最有價值的輸出——下游可以直接拿到{id: 1, name: 舊值}變成{id: 1, name: 新值}這樣的JSON數(shù)據(jù)而不需要自己拼SQL去反查。第三階段存儲Store。解析完成后事件會寫入一個內(nèi)存環(huán)形隊列等待客戶端來拉取。canal內(nèi)置了一個基于內(nèi)存的存儲組件默認容量是16384個事件客戶端消費速度跟不上時事件會在內(nèi)存里排隊排滿了之后才會出現(xiàn)丟數(shù)據(jù)或者阻塞的情況。整個鏈條如下圖所示文字版MySQL binlog → canal Server 抓取 → 解析 → 內(nèi)存隊列 → 客戶端(Client) 拉取 → 你的業(yè)務(wù)代碼/ES/Redis...3.3 你眼里的canal組件Server、Instance和Client實際部署時你會接觸到幾個概念這里一次性講清楚避免后續(xù)被配置項繞暈canal Server一個獨立運行的Java進程核心服務(wù)。canal InstanceServer內(nèi)部的一個邏輯實例每個Instance對應(yīng)一個MySQL數(shù)據(jù)源。一個Server可以配置多個Instance每個Instance有獨立的配置、獨立的訂閱位點、獨立的隊列。canal Client你寫的消費端程序通過TCP協(xié)議從Server拉取數(shù)據(jù)。打個比方Server是餐廳Instance是廚房里的一個灶臺——每個灶臺對應(yīng)一個供應(yīng)商MySQLClient是來吃飯的顧客。一個餐廳有多個灶臺很正常每個灶臺負責(zé)炒不同的菜互不干擾。從部署角度小白剛開始只需要一個Server、一個Instance、一個Client后面需要訂閱多個庫或者對接多套下游時再考慮多Instance。4. 跑通第一個Demo用Java代碼訂閱一條insert前面講了那么多理論和準備這一章我們真正動手。我用一臺Linux機器做演示canal部署包從官方GitHub Release頁面下載最新穩(wěn)定版即可解壓后目錄結(jié)構(gòu)大致如下/canal ├── bin ├── conf │ ├── canal.properties │ ├── example │ │ └── instance.propertiesconf/canal.properties是全局配置conf/example是默認實例的配置目錄instance.properties是實例級配置。4.1 修改實例配置先改instance.properties這是核心# MySQL主庫地址 canal.instance.master.address127.0.0.1:3306 # 連接MySQL的賬號密碼 canal.instance.dbUsernamecanal canal.instance.dbPasswordcanal123 # 訂閱的數(shù)據(jù)庫和表*表示所有 canal.instance.filter.regextest\\..* # 位點定位方式 canal.instance.gtidfalse重點說明一下filter.regex這個配置。它的格式是數(shù)據(jù)庫名\\..*比如我只想訂閱test庫的所有表就寫test\\..*想訂閱test庫下的user表就寫test\\.user想訂閱多個庫用|分隔。這個正則很容易寫錯因為Java字符串本身也要轉(zhuǎn)義所以\\.寫成\\.而不是\.。我見過有人照抄配置把轉(zhuǎn)義符弄丟了結(jié)果canal直接不輸出任何數(shù)據(jù)查了半天才發(fā)現(xiàn)是正則匹配問題。4.2 修改全局配置再看canal.properties重點確認以下幾項canal.port11111 canal.destinationsexample canal.instance.global.modetcpcanal.port是客戶端連接的TCP端口默認11111不用改。canal.destinations指定啟動哪些實例默認example對應(yīng)conf目錄下的example文件夾。canal.instance.global.modetcp表示消費端通過TCP直連方式拉取數(shù)據(jù)——這是最簡單的方式后面聊MQ模式時再說。4.3 啟動Servercd /canal/bin ./startup.sh啟動后看日志確認沒有異常tail -f /canal/logs/canal/canal.log如果看到canal server is running now之類的字樣并且沒有報錯說明Server起來了。再檢查實例狀態(tài)tail -f /canal/logs/example/example.log正常情況下能看到start successful。這里有個新手最容易遇到的情況日志里顯示canal is starting然后卡住不動多半是MySQL連接沒通去查example.log里有沒有connect timeout或者Access denied字樣。4.4 寫一個最小客戶端canal官方提供了一個客戶端庫canal.client用Maven引入dependency groupIdcom.alibaba.otter/groupId artifactIdcanal.client/artifactId version1.1.7/version /dependency然后寫一個最簡單的Java類核心邏輯是建立連接 → 拉取消息 → 解析事件 → 打印變更內(nèi)容。import com.alibaba.otter.canal.client.CanalConnector; import com.alibaba.otter.canal.client.CanalConnectors; import com.alibaba.otter.canal.protocol.Message; import com.alibaba.otter.canal.protocol.CanalEntry; import com.alibaba.otter.canal.protocol.CanalEntry.EntryType; import java.net.InetSocketAddress; import java.util.List; public class CanalDemo { public static void main(String[] args) { // 連接canal server CanalConnector connector CanalConnectors.newSingleConnector( new InetSocketAddress(127.0.0.1, 11111), example, // instance名稱 , // 無認證時填空 ); connector.connect(); // 訂閱所有表這里要和instance的filter.regex對應(yīng) connector.subscribe(test\\..*); while (true) { // 一次拉取100條不設(shè)置超時 Message message connector.getWithoutAck(100); long batchId message.getId(); if (batchId -1 || message.getEntries().isEmpty()) { // 沒有數(shù)據(jù)睡1秒再試 try { Thread.sleep(1000); } catch (InterruptedException e) {} continue; } for (CanalEntry.Entry entry : message.getEntries()) { if (entry.getEntryType() ! EntryType.ROWDATA) { continue; } CanalEntry.RowChange rowChange CanalEntry.RowChange.parseFrom(entry.getStoreValue()); CanalEntry.EventType eventType rowChange.getEventType(); for (CanalEntry.RowData rowData : rowChange.getRowDatasList()) { if (eventType CanalEntry.EventType.INSERT) { System.out.println(INSERT: rowData.getAfterColumnsList()); } else if (eventType CanalEntry.EventType.UPDATE) { System.out.println(UPDATE before: rowData.getBeforeColumnsList()); System.out.println(UPDATE after: rowData.getAfterColumnsList()); } else if (eventType CanalEntry.EventType.DELETE) { System.out.println(DELETE: rowData.getBeforeColumnsList()); } } } // 確認消費成功 connector.ack(batchId); } } }這段代碼看著有點長但核心就三件事連接、拉取、確認。所有canal客戶端的骨架都是這個模式你以后無論用Spring Boot封裝還是寫其他語言的客戶端都逃不開這個套路。4.5 實測驗證運行上面的Java類然后在MySQL里執(zhí)行INSERT INTO test.user (name, age) VALUES (張三, 25);立刻就能在控制臺看到類似下面的輸出INSERT: [name: 張三, age: 25]看到這一行你的canal入門第一個Demo就算真正跑通了。從這一刻起任何數(shù)據(jù)庫變更都會實時出現(xiàn)在你的消費端面前剩下的就是你怎么利用這些數(shù)據(jù)了。5. 小白最容易踩的五個坑含完整排查思路說實話canal的部署和Demo真的很簡單但越是這種看起來簡單的組件越容易在細節(jié)上翻車。這一章我把自己和周圍人踩過的坑整理出來每一項都附上排查鏈路而不是直接給結(jié)論——因為下次你遇到的可能只是個相似但不完全一樣的問題思路比答案更重要。5.1 坑一binlog格式不是ROW解析結(jié)果全是SQL現(xiàn)象客戶端能連上能收到消息但解析出來的RowData是空的只有SQL語句。排查鏈路第一步回到MySQL執(zhí)行SHOW VARIABLES LIKE binlog_format;如果結(jié)果是STATEMENT或MIXED基本就是問題所在。第二步修改配置為ROW重啟MySQL。第三步重新執(zhí)行一條INSERT看canal是否輸出結(jié)構(gòu)化的列值。根因只有ROW格式才會記錄每一行變更的具體列值STATEMENT格式記錄的是原始SQL文本canal無法從中還原出行級別數(shù)據(jù)。5.2 坑二server-id沖突導(dǎo)致連接被拒現(xiàn)象canal日志里出現(xiàn)ERROR: Got error 1236或者直接連接不上MySQL。排查鏈路第一步檢查MySQL的server-idSELECT server_id;第二步檢查canal的canal.instance.properties里有沒有canal.instance.mysql.slaveId配置項這個值默認是123456。如果和MySQL的server-id一樣就改成一個不同的值比如654321。第三步重啟canal實例觀察日志。根因MySQL主從復(fù)制機制要求每個從節(jié)點的server-id必須全局唯一。canal偽裝成一個從節(jié)點如果它的server-id和MySQL主庫相同主庫會認為這是我自己直接拒絕復(fù)制請求。這里插一句生產(chǎn)中很多人會忽略這個參數(shù)因為它的默認值看起來沒存在感。建議部署清單里專門加一行確認slaveId與所有MySQL節(jié)點均不重復(fù)。5.3 坑三位點丟失導(dǎo)致重復(fù)消費或漏消費現(xiàn)象canal重啟后客戶端收到了之前已經(jīng)處理過的舊數(shù)據(jù)或者直接跳過了部分數(shù)據(jù)。排查鏈路第一步確認canal的meta信息存儲在哪里。默認情況下位點存在內(nèi)存中Server重啟就會丟失從當(dāng)前最新位置開始消費。如果你需要持久化要在canal.properties里配置canal.instance.global.spring.xmlclasspath:spring/memory-instance.xml改為file-instance.xml可以把meta寫到本地文件。第二步檢查客戶端代碼是否正確ack。只get不ack重啟后會從上次ack的位置重新拉取產(chǎn)生重復(fù)消費ack太快也可能出問題如果先ack再處理業(yè)務(wù)邏輯處理失敗時數(shù)據(jù)就再也拉不回來了這是至少一次語義下最常見的取舍。第三步設(shè)計消費冪等。無論位點多可靠分布式環(huán)境下重復(fù)消費幾乎不可避免所以消費端的冪等才是最終兜底。根因canal的位點機制是經(jīng)典的有且至少一次消費語義重復(fù)消費是常態(tài)漏消費是因為位點推進到了業(yè)務(wù)成功之前。5.4 坑四多個客戶端實例同時消費同一個instance現(xiàn)象多個服務(wù)實例都連了同一個canal destination結(jié)果每條數(shù)據(jù)只被其中一個實例收到而不是每個實例都收到。排查鏈路第一步確認你的業(yè)務(wù)訴求是廣播還是負載均衡。canal不保證多個client同時消費時每個client都能拿到全量數(shù)據(jù)默認是競爭消費——一條數(shù)據(jù)只會給一個client。第二步如果確實需要多個下游分別消費同一份數(shù)據(jù)可以有三種方案一是每個下游對應(yīng)一個獨立的instance二是通過MQ模式發(fā)布訂閱三是使用canal的CanalMQStarter配多個不同的group。根因canal的tcp模式的定位是一個destination對應(yīng)一個消費組多個client是在消費組內(nèi)競爭拉取不是復(fù)制分發(fā)。5.5 坑五DDL事件和事務(wù)邊界導(dǎo)致的數(shù)據(jù)異常現(xiàn)象執(zhí)行ALTER TABLE之后消費端收到的數(shù)據(jù)突然解析失敗或者一個事務(wù)內(nèi)的多變更變得不完整。排查鏈路第一步檢查消費端是否處理了EntryType.ROWDATA之外的事件。DDL事件屬于ENTRY_TYPE的其他類型如果你在消費端直接跳過所有非ROWDATA事件DDL對下游可能造成結(jié)構(gòu)不一致。第二步開啟canal的并行消費時要注意事務(wù)一致性。如果下游是數(shù)據(jù)庫或緩存建議按事務(wù)邊界整體提交避免同一個事務(wù)的變更被拆到不同地方執(zhí)行。根因canal按事務(wù)為單位讀取binlog但消費端如果并行處理事務(wù)邊界會被人為拆散。這五個坑基本覆蓋了我見過的90%小白問題。說實話每個坑背后都對應(yīng)一個理解盲區(qū)不是性能問題不是bug而是對canal是怎么工作的理解不到位。所以每次出問題先回到第3章的原理圖里定位是在哪個環(huán)節(jié)排查速度會快很多。6. 進階思路從單機Demo走向生產(chǎn)環(huán)境Demo跑通、坑也避開之后你可能會問那真實項目里一般怎么用這一章我講三個最常用的落地方向以及小白從單機走向生產(chǎn)時需要補的功課。6.1 實戰(zhàn)方向一數(shù)據(jù)庫變更同步到Redis這是canal最常見的用法。假設(shè)你的商品表product里有價格字段價格變了緩存也得變。傳統(tǒng)做法是改業(yè)務(wù)代碼在更新數(shù)據(jù)庫后刪除緩存用canal之后消費端收到UPDATE事件直接從JSON里提取最新值執(zhí)行SET key value或者刪除緩存。業(yè)務(wù)代碼零侵入。要注意兩點第一canal發(fā)來的是列名值的結(jié)構(gòu)不是SQL所以你需要自己把變更映射成業(yè)務(wù)對象這個映射邏輯一般寫在消費端一個獨立模塊里第二如果變更頻繁要注意給緩存加防抖比如1秒內(nèi)同一行的多次變更合并成一次刷緩存避免抖動。6.2 實戰(zhàn)方向二異構(gòu)數(shù)據(jù)同步到Elasticsearch把MySQL的數(shù)據(jù)同步到ES做全文檢索也是高頻場景。流程大致是canal監(jiān)聽MySQL變更 → 消費端把變更拼成ES文檔 → 調(diào)用ES的index/update接口。這里有個常見的設(shè)計問題ES里可能需要寬表比如訂單文檔里要包含用戶名、商品名而這些字段來自其他表。如果只訂閱訂單表拿不到關(guān)聯(lián)信息。解決思路有兩個一是訂閱多張表在消費端做內(nèi)存關(guān)聯(lián)二是讓業(yè)務(wù)方寫出包含所有所需字段的預(yù)聚合表canal只訂閱這一張。第二個方案更簡單可靠推薦小白先這么做。6.3 從單機到集群三個生產(chǎn)級配置生產(chǎn)環(huán)境不可能只跑一個單機canal但我也要提醒你一開始別急著上集群先把下面三件事做好比盲目加機器更有價值。第一個是位點持久化。前面說過默認位點在內(nèi)存在Server重啟就丟。生產(chǎn)環(huán)境務(wù)必配置成file模式或zookeeper模式。我用的是file模式最簡單但要注意磁盤空間和文件權(quán)限。第二個是訂閱粒度收斂。開發(fā)環(huán)境訂閱所有庫所有表沒問題生產(chǎn)環(huán)境一定要用filter.regex收窄到具體業(yè)務(wù)庫和表不然會白白消耗大量性能還可能把其他團隊的數(shù)據(jù)變更也帶進你的消費邏輯。第三個是監(jiān)控告警。canal是實時鏈路一旦它停了下游全部數(shù)據(jù)滯后。至少要做到進程存活監(jiān)控、消費延遲監(jiān)控canal有delayed指標、客戶端積壓消息數(shù)監(jiān)控。這些指標都可以通過JMX或者集成到現(xiàn)有監(jiān)控系統(tǒng)里別等業(yè)務(wù)方來問為什么數(shù)據(jù)還沒同步過來你才發(fā)現(xiàn)問題。至于集群模式canal支持多Server ZooKeeper的HA方案多個instance由ZK協(xié)調(diào)一臺掛了自動切換到另一臺。這個配置本身不復(fù)雜但我建議在你的業(yè)務(wù)真正需要高可用之前先把單機的監(jiān)控和運維做扎實因為集群也解決不了消費端邏輯的bug。7. 最后的實用建議這一章不聊原理、不聊配置就說一些零散但真實的經(jīng)驗。第一開發(fā)環(huán)境一定要把binlog打開。我見過不少團隊本地MySQL默認沒開binlog結(jié)果canal跑不起來排查半天發(fā)現(xiàn)是本地環(huán)境的鍋。你可以在MySQL配置里直接默認開啟對開發(fā)環(huán)境性能影響微乎其微。第二消費端一定要做冪等。不管你用哪種位點配置重復(fù)消費都是可能發(fā)生的所以消費邏輯必須能反復(fù)執(zhí)行而結(jié)果一致。比如同步到ES用文檔ID做upsert天然冪等同步到Redis覆蓋寫本來就冪等同步到另一個MySQL用主鍵做INSERT ... ON DUPLICATE KEY UPDATE就能保證不炸。第三binlog里的時間字段要小心。canal解析出的時間字段默認是字符串格式時區(qū)可能有偏移。如果你發(fā)現(xiàn)同步的數(shù)據(jù)在時間上差了8個小時去檢查canal的時區(qū)配置。第四測試的時候別只測INSERT。我見過有人Demo只驗證了insert就以為一切正常結(jié)果上線后update和delete全沒處理數(shù)據(jù)越差越多。測試至少覆蓋增刪改三種事件最好再測一個事務(wù)里多條變更的順序性。最后說一句掏心窩的話canal入門真的不難難的是你要理解它和業(yè)務(wù)系統(tǒng)的邊界在哪里。它能幫你解決數(shù)據(jù)同步但它不會幫你把下游的消費邏輯寫好也不會幫你兜住消費端拋出的異常。把它當(dāng)成一個可靠的數(shù)據(jù)搬運工真正干活的內(nèi)容還是要靠你精心設(shè)計消費端來處理。我用canal做了好幾個項目的增量同步從最開始照貓畫虎跑通Demo到現(xiàn)在能快速定位各種奇怪問題最大的感受就是工具本身只是管道關(guān)鍵還是對數(shù)據(jù)變化鏈路有一顆敬畏之心。希望你也能順著這篇文章跑通自己的第一個Demo然后在這個基礎(chǔ)上一步步把數(shù)據(jù)流動做得更穩(wěn)、更優(yōu)雅。