之前因為懶，沒有針對otter做更多的解釋和說明，在使用過程中，也發現了一些問題，此次補上一個完整的文檔，方便大家使用。
Otter是基於cannal開源的，canal又是基於mysql binlog的產品。我們就從binlog說起
binlog
mysql的binlog日志是被設計用來作主從備份或者數據恢復用的。binlog是The Binary Log的簡稱，意思就是二進制的日志文件（可以點擊https://dev.mysql.com/doc/refman/5.6/en/binary-log.html了解）。binlog中以二進制的形式記錄了數據庫的”events（事件）”即數據庫結構及表數據發生的變化。以下這張圖就反應了主從庫之間使用binlog進行同步的過程：
mysql提供了三種不同的binlog記錄形式：
- STATEMENT 語句模式（默認）：日志中記錄了所有的執行的sql語句，從庫在執行的時候，重新執行相應sql即可。但是因為不記錄語句執行的上下文，在從庫執行某些語句（比如存儲過程）的時候，有些語句不一定能成功執行導致丟失數據
- ROW 行模式：日志中記錄每一行每個字段的變化，能清楚記錄每行數據的變化歷史，主從丟失數據的情況大大降低，但是缺點是會產生大量的binlog占用存儲空間
- MIX 混合模式：在 Mixed 模式下，MySQL 會根據執行的每一條具體的 SQL 語句來區分對待記錄的日志形式，也就是在 statement 和 row 之間選擇一種。比如遇到表結構變更的時候就會以 statement 模式來記錄，如果 SQL 語句確實就是 update 或者 delete 等修改數據的語句，那么還是會記錄所有行的變更。目前這種模式其實就是由mysql來選擇到底用哪種模式記錄，可以點此了解https://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html
你可以通過以下命令查看自己的mysql的binlog情況：
//查看自己的mysql是否打開了binlog選項
show variables like 'log_bin' //查看binlog的格式 show variables like 'binlog_format' //獲取binlog列表 show binary logs //或者 show master logs //查看正在寫入的binlog show master status- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
上文中說過binlog中是以event的形式記錄日志的，所以你可以通過事件命令查看具體的日志內容及位置
SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]- 1
- 2
- 3
- 4
比如：SHOW BINLOG EVENTS LIMIT 1
- Log_name:日志文件名
- Pos:事件起始位置
- Event_type：事件類型
- End_log_pos結束位置
mysqlbinlog工具
如果binlog的格式是STATEMENT，以上show binlog event的方式是可以看到sql語句的，但是如果row模式的話，沒法看到，只能通過mysqlbinlog工具進行查看，mysqlbinlog也是mysql dba常用的備份恢復數據的工具。
該工具需要登錄到數據庫主機使用
mysqlbinlog [options] log_file - 1
具體的選項參考：https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html
如果你沒有數據庫主機的登錄權限，可以選擇使用遠程導出的方式將遠端的binlog導出。
# mysqlbinlog -u用戶名 -p密碼 -h主機地址 -P端口號 --read-from-remote-server mysql-bin.000001 --base64-output=decode-rows -v > 1.txt- 1
返回數據如下，黑色背景部分為一個事件的完整日志，紅框標記則為執行的SQL
Canal
canal(https://github.com/alibaba/canal)是阿里出品基於binlog的一款訂閱消費組件，簡單來說也就是它可以訂閱mysql的binlog，並進行讀取消費，以達到數據同步等目的。相較於傳統的觸發器同步數據模式，基於binlog的數據同步方式無疑靈活性、功能性更強。
原理如下：
- canal模擬mysql slave的交互協議，偽裝自己為mysql slave，向mysql master發送dump協議
- mysql master收到dump請求，開始推送binary log給slave(也就是canal)
- canal解析binary log對象(原始為byte流)
canal服務端：
這張圖表示了canal服務端的模塊划分
- server代表一個canal運行實例，對應於一個jvm
- instance對應於一個數據隊列（也就是一個數據庫的binlog訂閱者） （1個server對應1..n個instance)
instance下的子模塊：
- eventParser (數據源接入，模擬slave協議和master進行交互，協議解析)
- eventSink (Parser和Store鏈接器，進行數據過濾，加工，分發的工作)
- eventStore (數據存儲)
- metaManager (增量訂閱&消費信息管理器)
canal客戶端：
canal客戶端可以向服務器端進行消息訂閱消費，服務器端的解析后的數據存在eventStore中，而客戶端的工作就是從eventStore中訂閱消費。
好了，我們已經對canal大概了解了，下一篇文檔我們進入我們的正題otter