Canal
Canal原理
原理相對比較簡單：
- canal模擬mysql slave的交互協議，偽裝自己為mysql slave，向mysql master發送dump協議
- mysql master收到dump請求，開始推送binary log給slave(也就是canal)
- canal解析binary log對象(原始為byte流)
Canal架構
Canal集群
大致步驟：
- canal server要啟動某個canal instance時都先向zookeeper進行一次嘗試啟動判斷 (實現：創建EPHEMERAL節點，誰創建成功就允許誰啟動)
- 創建zookeeper節點成功后，對應的canal server就啟動對應的canal instance，沒有創建成功的canal instance就會處於standby狀態
- 一旦zookeeper發現canal server A創建的節點消失后，立即通知其他的canal server再次進行步驟1的操作，重新選出一個canal server啟動instance.
- canal client每次進行connect時，會首先向zookeeper詢問當前是誰啟動了canal instance，然后和其建立鏈接，一旦鏈接不可用，會重新嘗試connect.
Canal數據流程
相關問題:
canal過濾數據的單位是數據庫，可以過濾到表:
| 參數名字 |
參數說明 |
默認值 |
| canal.instance.filter.regex (白名單) |
mysql 數據解析關注的表，Perl正則表達式. 多個正則之間以逗號(,)分隔，轉義符需要雙斜杠(\\)
1. 所有表：.* or .*\\..* 5. 多個規則組合使用：canal\\..*,mysql.test1,mysql.test2 (逗號分隔) |
.*\\..* |
| canal.instance.filter.black.regex (黑名單) |
mysql 數據解析表的黑名單，表達式規則見白名單的規則 |
無 |
Canal單實例和多實例:instance對應於一個數據隊列(1個server對應1..n個instance)(canal官方文檔--簡介)
Canal集群僅僅是為了可靠性:為了減少對mysql dump的請求，不同server上的instance要求同一時間只能有一個處於running，其他的處於standby狀態。(針對同一主備)
(canal官方文檔--簡介)
Otter
Otter原理
原理描述：
1. 基於Canal開源產品，獲取數據庫增量日志數據。
2. 典型管理系統架構，manager(web管理)+node(工作節點)
a. manager運行時推送同步配置到node節點
b. node節點將同步狀態反饋到manager上
3. 基於zookeeper，解決分布式狀態調度的，允許多node節點之間協同工作.
Otter架構
名詞解釋
- Pipeline：從源端到目標端的整個過程描述，主要由一些同步映射過程組成
- Channel：同步通道，單向同步中一個Pipeline組成，在雙向同步中有兩個Pipeline組成
- DataMediaPair：根據業務表定義映射關系，比如源表和目標表，字段映射，字段組等
- DataMedia : 抽象的數據介質概念，可以理解為數據表/mq隊列定義
- DataMediaSource : 抽象的數據介質源信息，補充描述DateMedia
- ColumnPair : 定義字段映射關系
- ColumnGroup : 定義字段映射組
- Node : 處理同步過程的工作節點，對應一個jvm
Otter分布式架構
由於單節點容易導致宕機時數據丟失,所以可以將多個Node綁定到同一Zookeeper集群,在宕機時重新選舉工作節點,實現高可用。
Otter完整搭建圖
Otter完整搭建需要otter數據庫,zookeeper集群,Manager管理組件和Node工作組件。otter運行時數據保存在單獨的otter數據庫,zookeeper實現高可用,Node完成同步數據的工作。
Otter操作
安裝完成后打開manager地址例如:http://172.16.0.3:8080,默認用戶名密碼是admin/admin
單向同步配置:
前提條件: 數據庫表結構相同
