之前因為懶，沒有針對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記錄形式：

1. STATEMENT 語句模式（預設）：日誌中記錄了所有的執行的sql語句，從庫在執行的時候，重新執行相應sql即可。但是因為不記錄語句執行的上下文，在從庫執行某些語句（比如儲存過程）的時候，有些語句不一定能成功執行導致丟失資料
2. ROW 行模式：日誌中記錄每一行每個欄位的變化，能清楚記錄每行資料的變化歷史，主從丟失資料的情況大大降低，但是缺點是會產生大量的binlog佔用儲存空間
3. 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

上文中說過binlog中是以event的形式記錄日誌的，所以你可以通過事件命令檢視具體的日誌內容及位置

SHOW BINLOG EVENTS
   [IN 'log_name']
   [FROM pos]
   [LIMIT [offset,] row_count]

比如：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 

如果你沒有資料庫主機的登入許可權，可以選擇使用遠端匯出的方式將遠端的binlog匯出。

# mysqlbinlog -u使用者名稱 -p密碼 -h主機地址 -P埠號 --read-from-remote-server mysql-bin.000001 --base64-output=decode-rows -v > 1.txt

返回資料如下，黑色背景部分為一個事件的完整日誌，紅框標記則為執行的SQL

Canal

canal(https://github.com/alibaba/canal)是阿里出品基於binlog的一款訂閱消費元件，簡單來說也就是它可以訂閱mysql的binlog，並進行讀取消費，以達到資料同步等目的。相較於傳統的觸發器同步資料模式，基於binlog的資料同步方式無疑靈活性、功能性更強。

原理如下：

1. canal模擬mysql slave的互動協議，偽裝自己為mysql slave，向mysql master傳送dump協議
2. mysql master收到dump請求，開始推送binary log給slave(也就是canal)
3. 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