亚洲激情专区-91九色丨porny丨老师-久久久久久久女国产乱让韩-国产精品午夜小视频观看

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

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

發布時間:2021-11-17 15:32:12 來源:億速云 閱讀:256 作者:柒染 欄目:大數據

本篇文章給大家分享的是有關怎么解析Canal binlog 日志管理器與GTID,小編覺得挺實用的,因此分享給大家學習,希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。

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

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

 

1、Canal 位點管理(日志管理器)


 
1.1 類圖

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


整個日志管理器由接口 CanalLogPositionManager 定義,主要定義兩個方法:
  • 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 日志管理器的實現比較簡單,這里就不一一去看源碼了,那這里就重點介紹一下其使用方法。

怎么解析Canal binlog 日志管理器與GTID  
CanalInstanceWithManager#initLogPositionManager  
從這里可以看到,Canal 提供了 indexMode 屬性來指定使用哪種日志管理器,其可選項:
  • 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相關的屬性。

怎么解析Canal binlog 日志管理器與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就不是越大越先執行了,舉例如下:

怎么解析Canal binlog 日志管理器與GTID   通過如下命令手動指定gtid:  
set gtid_next='1f0eee4c-a66e-11ea-8999-00dbdfe417b8:10';
begin;
commit;
set gtid_next='AUTOMATIC';
 
怎么解析Canal binlog 日志管理器與GTID  
故這里產生了另外一個事件,其gtid 為 10,下一條語句產生的GTID會是 11 還是 4 呢?  
怎么解析Canal binlog 日志管理器與GTID   從這里看成,會先使用空洞,其binlog記錄如下。  
怎么解析Canal binlog 日志管理器與GTID   從這里看出,在后續避免數據順序性方面,使用GTID并不是一個十全的方法,基于binlog的寫入時間更為靠譜。    

以上就是怎么解析Canal binlog 日志管理器與GTID,小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

汪清县| 锡林郭勒盟| 西城区| 武穴市| 洛扎县| 新密市| 镇沅| 吉首市| 平乡县| 巴马| 永川市| 益阳市| 迁安市| 衡东县| 大埔区| 无棣县| 镇康县| 阳曲县| 平和县| 奉节县| 刚察县| 隆德县| 天镇县| 西乌珠穆沁旗| 天祝| 垦利县| 平原县| 铅山县| 福清市| 临城县| 乌苏市| 绵竹市| 石嘴山市| 全南县| 福建省| 晋城| 犍为县| 安庆市| 清苑县| 天峨县| 鄂尔多斯市|