怎么解析Canal binlog 日志管理器與GTID

正如上文提到的那樣，在 Canal Instance 啟動的時候，首先會查詢?nèi)罩竟芾砥髦胁檎疑弦淮蔚耐轿稽c，如果沒有查詢到，則默認(rèn)會從最新的位點開始同步，但如果每一次啟動 Instance 都從最后開始同步，其數(shù)據(jù)完整性無法保證，正確的做法是在數(shù)據(jù)同步的過程中應(yīng)該記錄位點并持久化，重新啟動后按照繼續(xù)從上一次的位置繼續(xù)同步，實現(xiàn)真正的增量同步。

詳細(xì)探討 Canal 的幾個日志管理器，并來探究一下 MySQL 的 GTID 機(jī)制。

1、Canal 位點管理（日志管理器）

1.1 類圖

• LogPosition getLatestIndexBy(String destination)
  根據(jù) destination 獲取同步位點，即在 Canal Instance 中同步進(jìn)度是以源實例為最小維度的。

• void persistLogPosition(String destination, LogPosition logPosition)
  持久化同步位點。

Canal 中提供了7種位點管理機(jī)制，分別如下：

• MemoryLogPositionManager
  同步位點存儲在內(nèi)存中，即存放在 Map 中，通常用于測試或結(jié)合其他位點管理，用來提高性能。

• ZooKeeperLogPositionManager
  同步位點存儲在 zookeeper 中，是主流的分布式存儲方案。

• MetaLogPositionManager
  Canal 中的元數(shù)據(jù)存儲方式，即位點信息與元數(shù)據(jù)存放在一起。

• MixedLogPositionManager
  混合日志位點管理器，主要是內(nèi)存與 Zookeeper 的混合方式，在存儲位點時先存入內(nèi)存，然后用線程池異步存儲到 zookeeper 中。

• FileMixedLogPositionManager
  基于內(nèi)存與本地文件的混合日志管理器，存儲位點時首先存入內(nèi)存，然后定時同步到文件中。

• PeriodMixedLogPositionManager
  帶定時功能的基于內(nèi)存與 zookeeper 的混合日志管理器，存儲位點時先寫入內(nèi)存，然后定時同步到 zookeeper。

• FailbackLogPositionManager
  帶　failback　機(jī)制的日志位點管理器，即可以創(chuàng)建準(zhǔn)備兩種日志管理器，例如在構(gòu)建時可以將 ZooKeeperLogPositionManager 當(dāng)為主管理器，基于 FileMixedLogPositionManager 當(dāng)備用日志位點管理器，在寫入日志位點時，嘗試寫入主日志管理器，如果拋出異常，則使用備用日志管理器；查詢位點時先查主日志管理器，如果未查到，則查備用日志管理器。

1.2 日志管理器使用方法

由于 Canal 日志管理器的實現(xiàn)比較簡單，這里就不一一去看源碼了，那這里就重點介紹一下其使用方法。

 

• MEMORY
  內(nèi)存

• ZOOKEEPER
  基于zookeeper，使用該模式還需要通過 zkClusters 設(shè)置 zk 集群的地址。

• MIXED
  混合模式，基于內(nèi)存+Zookeeper + Period，即定時存儲到 zookeeper 中，使用的實現(xiàn)類為MixedLogPositionManager，默認(rèn)為每隔1s持久化一次。

• META
  基于元數(shù)據(jù)的管理模式。

• MEMORY_META_FAILBACK
  基于內(nèi)存與元數(shù)據(jù)的fallback，其中主日志管理器為 MEMORY。

在生產(chǎn)環(huán)境，通常建議使用 MIXED，基于內(nèi)存與Zookeeper的混合模式。

2、MySQL GTID 掃盲

在 MySQL5.6.x 中引入了 GTID 機(jī)制，用于優(yōu)化主從同步機(jī)制，本文不打算詳細(xì)介紹 GTID 的方方面面，只是初步認(rèn)識 GTID，方面在后續(xù)實現(xiàn)數(shù)據(jù)同步方面思考數(shù)據(jù)一致性如何保證等方案時具備必要的基礎(chǔ)。

首先我們可以通過如下命令查看與gtid相關(guān)的屬性。

 

• gtid_executed
  當(dāng)前MySQL實現(xiàn)已經(jīng)執(zhí)行過的事務(wù)。在開啟GTID模塊時每執(zhí)行一個事務(wù)會產(chǎn)生一個全局唯一的事務(wù)ID。在每一臺MySQL實例上執(zhí)行的事務(wù)何止上億，這個字段要存儲所有已執(zhí)行的的事務(wù)ID，怎么存儲能節(jié)省空間就是一個需要解決的問題，稍后再進(jìn)行展開說明。

• gtid_executed_compression_period
  在MySQL5.7版本專門引入了一個系統(tǒng)表：mysql.gtid_executed，gtid_executed_compression_period 參數(shù)就是設(shè)置每執(zhí)行多個事務(wù)，對這個表進(jìn)行壓縮，默認(rèn)值為1000。

• gtid_mode
  是否開啟gtid模式。

• gtid_purged
  已不在 binlog 日志中的事務(wù)ID，Mysql 并不會永久存儲 binlog 日志，而是通過 expire_logs_days 設(shè)置過期時間，單位為天，默認(rèn)為10天。

一個GTID由兩部分組成：server id uuid 與遞增序號，兩者之間用英文冒號隔開，例如上圖中的：1f0eee4c-a66e-11ea-8999-00dbdfe417b8:1。

再來回到 gtid_executed 的存儲問題上，為了減少存儲空間，連續(xù)的gtid可以用進(jìn)行合并，例如  1f0eee4c-a66e-11ea-8999-00dbdfe417b8:1-10，表示連續(xù)代表1-10個事務(wù)。

GTID的生成有自動遞增與手動執(zhí)行模式，自動遞增模式可以在單個Server集群中保證有序，即GTID值越大，說明事務(wù)越后執(zhí)行，但如果進(jìn)行了人工干預(yù)，GTID就不是越大越先執(zhí)行了，舉例如下：

  通過如下命令手動指定gtid：  

set gtid_next='1f0eee4c-a66e-11ea-8999-00dbdfe417b8:10';
begin;
commit;
set gtid_next='AUTOMATIC';

 

  從這里看成，會先使用空洞，其binlog記錄如下。  

  從這里看出，在后續(xù)避免數(shù)據(jù)順序性方面，使用GTID并不是一個十全的方法，基于binlog的寫入時間更為靠譜。