正如上文提到的那樣，在 Canal Instance 啟動的時候，首先會查詢日志管理器中查找上一次的同步位點，如果沒有查詢到，則默認會從最新的位點開始同步，但如果每一次啟動 Instance 都從最后開始同步，其數據完整性無法保證，正確的做法是在數據同步的過程中應該記錄位點并持久化，重新啟動后按照繼續從上一次的位置繼續同步，實現真正的增量同步。

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

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

1.1 類圖

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

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

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

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

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

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

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

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

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

• FailbackLogPositionManager
  帶　failback　機制的日志位點管理器，即可以創建準備兩種日志管理器，例如在構建時可以將 ZooKeeperLogPositionManager 當為主管理器，基于 FileMixedLogPositionManager 當備用日志位點管理器，在寫入日志位點時，嘗試寫入主日志管理器，如果拋出異常，則使用備用日志管理器；查詢位點時先查主日志管理器，如果未查到，則查備用日志管理器。

1.2 日志管理器使用方法

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

 

• MEMORY
  內存

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

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

• META
  基于元數據的管理模式。

• MEMORY_META_FAILBACK
  基于內存與元數據的fallback，其中主日志管理器為 MEMORY。

在生產環境，通常建議使用 MIXED，基于內存與Zookeeper的混合模式。

2、MySQL GTID 掃盲

在 MySQL5.6.x 中引入了 GTID 機制，用于優化主從同步機制，本文不打算詳細介紹 GTID 的方方面面，只是初步認識 GTID，方面在后續實現數據同步方面思考數據一致性如何保證等方案時具備必要的基礎。

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

 

• gtid_executed
  當前MySQL實現已經執行過的事務。在開啟GTID模塊時每執行一個事務會產生一個全局唯一的事務ID。在每一臺MySQL實例上執行的事務何止上億，這個字段要存儲所有已執行的的事務ID，怎么存儲能節省空間就是一個需要解決的問題，稍后再進行展開說明。

• gtid_executed_compression_period
  在MySQL5.7版本專門引入了一個系統表：mysql.gtid_executed，gtid_executed_compression_period 參數就是設置每執行多個事務，對這個表進行壓縮，默認值為1000。

• gtid_mode
  是否開啟gtid模式。

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

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

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

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

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

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

 

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

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