Debezium的增量快照

来源:https://www.cnblogs.com/greatsql/archive/2022/11/20/16908710.html
-Advertisement-
Play Games

GreatSQL社區原創內容未經授權不得隨意使用,轉載請聯繫小編並註明來源。 GreatSQL是MySQL的國產分支版本,使用上與MySQL一致。 作者: 如常 Debezium Incremental snapshotting Introduction CDC(Change-Data-Captur ...


  • GreatSQL社區原創內容未經授權不得隨意使用,轉載請聯繫小編並註明來源。
  • GreatSQL是MySQL的國產分支版本,使用上與MySQL一致。
  • 作者: 如常

Debezium Incremental snapshotting

Introduction

CDC(Change-Data-Capture)正被廣泛應用於數據緩存、更新查詢索引、創建派生視圖、異構數據同步等場景,Debezium 作為 CDC 的代表項目之一,它收集資料庫中的事務日誌(變化事件)並以統一的事件流格式輸出(支持「Kafka Connect」及「內嵌到程式中」兩種應用形式)。

資料庫的事務日誌往往會進行定期清理,這就導致了僅使用事務日誌無法涵蓋所有的歷史數據信息,因此 Debezium 在進行事件流捕獲前通常會執行 consistent snapshot(一致性快照) 以獲取當前資料庫中的完整數據。預設情況下,事件流的捕獲會在 consistent snapshot 完成之後 開啟,不同數據量情況下,這個過程可能會耗費數小時乃至數天,並且一旦這個過程由於某些異常因素停止,那重新開啟後,它將從頭開始執行。

為瞭解決一致性快照的這些痛點問題,Debezium 提出了一個新的設計方案,併在 DDD-3 中詳細介紹了該方案的核心理論,借鑒了 DBLog 中的思想,使用一種基於 Watermark 的框架,實現了 Incremental snapshotting

Incremental snapshotting 的優勢

  • 在任何時間都可以觸發快照的動作,除了在捕獲事件流前進行一次完整的快照外,在下游數據備份、丟失、恢復的場景中,往往也需要進行快照操作;
  • 快照可在執行過程中「掛起」和「恢復」,並且恢復執行後可定位到掛起前的位置,無需再從頭開始;
  • 在執行快照時,不需要暫停事件流的捕獲,也就是說快照可以和事件捕獲同時執行,互不影響,保證了事件流的低延遲性;
  • 無鎖,保證了在快照的同時資料庫依然能夠寫入。

下麵詳細介紹 DBLog 論文中的方案。

DBLog

  • DBLog 使用基於 Watermark 的方法,它能在直接使用 select from 對資料庫進行快照的同時捕獲資料庫的變化事件流,並使用相同的格式對 select 快照和事務日誌捕捉進行輸出。這意味著 DBLog 可選擇在任意時刻開始執行快照,而不僅限於事件日誌捕獲開始前。
  • DBLog 同時支持快照的掛起和恢復,歸功於它將數據按 chunk 進行劃分,並且在外部系統(如 Zookeeper)中存儲最近一次執行完成的 chunk。
  • DBLog 的輸出通常為 Kafka,支持將輸出結果落庫和使用 API 獲取。
  • DBLog 支持高可用,使用主備的方式保證同一時間會有一個活躍的實例處於正常工作狀態,多個備用實例處於等待狀態,一但工作中的實例發生異常,備用實例將會激活,替代原實例工作。

DBLog 的架構如下圖所示:

下麵將詳細介紹 DBLog 的事務日誌捕獲和快照機制。

事務日誌捕獲( Transaction log capture)

事務日誌捕獲依賴於資料庫的支持,如 MySQL 和 PostgreSQL 都提供了 replication 協議,DBLog 將作為資料庫主節點的一個從節點,資料庫主節點在事務執行完成後會向 replication 從節點發送事務日誌(經由 TCP)。通常的事務日誌中包含 createupdatedelete 類型的事件,DBLog 對這些事件進行處理,最終包裝為一種統一的格式輸出,輸出的結果將包含各 column 在事務發生時的狀態(事務發生前後的值),每個事件的包裝都會以一個 8-byte 且嚴格單調遞增的 LSN(Log Sequence Number)標識,該 LSN 表示該事件在事務日誌中的偏移量。上述處理後的輸出結果將會存儲在 DBLog 進程的記憶體中,由另外的輔助線程將這些結果搬運到最終的目的地(如 Kafka、DB 等)。

事務日誌中還包含了 schema 變化相關的事件,需要妥善處理,但不是本文討論的重點,這裡暫且忽略不提。

完整狀態捕獲(Full state capture)

事務日誌由於定期清理等原因,通常無法保存當前資料庫的所有歷史狀態,而在許多應用場景(如同步)中,都需要保證能完整重現源庫的所有數據,這就需要提供一種擴展的 Full state capture 機制。一種較為直觀的手段是對每個表建立相應的 copy 表,並將原表中的數據按批(Chunk)寫入到 copy 表中,這些寫入操作就會按照正確的順序產生一系列的事務日誌事件,在後續處理中就可以正確消費到這些事件(此時正常的事務事件可以同時生成)。這種方式的缺點在於需要消耗 IO 和磁碟空間,雖然可以使用諸如 MySQL bloackhole engine 規避,但實現方式依賴於資料庫提供商的特性,沒有泛用性。

DBLog 提供了一種更為通用且對源庫影響較小策略,它無需將所有的源表中的數據寫入到事務日誌中,而是採用分批處理的方式,以 Chunk 為單位將源表中的數據查詢出來(嚴格要求每次查詢都以主鍵排序),將這些數據處理成為 DBLog 中的事件結果,並添加到該過程中產生的正常事務事件結果之後。執行過程中需要在外部存儲(如 Zookerper)中存儲上一個已完成的 Chunk 的最後一行的主鍵值,這樣當這個過程被掛起後,就可以根據這個主鍵值恢復定位到最近一次執行成功的位置。

下圖為 Chunk 的示例,該表中的主鍵為 c1,且查詢時按 c1 進行排序,Chunk size 為 3。當執行 Chunk2 的查詢時,會從存儲中取出一個表示 Chunk1 最後一行數據的主鍵 4,而後執行的 Chunk2 查詢就會增加條件 c1 > 4。

由於在查詢 Chunk 過程中,正常的事務事件仍然同時在產生和執行,為了保證這個過程中不會發生「新數據」被「舊數據」覆蓋的情況,每個 Chunk 在與正常事件合併前需要進行特殊處理。核心演算法就是在正常的事務事件流中人為插入 Watermark 事件以標記 Chunk 的起止位置,Watermark 就是我們在源端庫中創建的一張特殊的表,它由唯一的名稱標識,保證不與現有的任何表名衝突,這個表中僅存儲 一行一列 的數據,該記錄中的數據為一個永不重覆的 UUID,這樣每當對這個記錄進行 update 時,就會在事務日誌中產生一條有 UUID 標識的事件,這個事件就稱為 watermark event

下麵演算法就是整個 Full state capture 的核心步驟:

Algorithm: Watermark-based Chunk Selection
Input: table

(1) pause log event processing
    lw := uuid(), hw := uuid()
(2) update watermark table set value = lw
(3) chunk := select next chunk from table
(4) update watermark table set value = hw
(5) resume log event processing
    inwindow := false
    // other steps of event processing loop
    while true do
    e := next event from changelog
    if not inwindow then
        if e is not watermark then
            append e to outputbuffer
        else if e is watermark with value lw then
            inwindow := true
    else
        if e is not watermark then
(6)         if chunk contains e.key then
                remove e.key from chunk
            append e to outputbuffer
        else if e is watermark with value hw then
(7)         for each row in chunk do
                append row to outputbuffer
    // other steps of event processing loop
...

該演算法流程會一直迴圈,直至表中的所有數據都被處理完成。

  • 步驟 1 暫停當前的正常事件日誌捕獲並生成兩個 UUID: lwhw。註意這裡是暫停 DBLog 對事件的捕獲,而不是暫停源端資料庫的日誌寫入,這個暫停過程中仍然可以有很多的寫入事件發生,這個暫停的過程較為短暫,在步驟 5 中會恢復;
  • 步驟 2 和步驟 4 分別使用步驟 1 中生成 lwhw 去修改 Watermark 表中的記錄,這將會在事務日誌中記錄兩個 update 事件;
  • 步驟 3 查詢某一個 Chunk 中的所有記錄,並將查詢的結果 chunk 保存在記憶體中,這個操作被夾在兩個 watermark 的更新操作之間,後續的處理流程就可以以這兩個位置為依據標識出哪些事件是在這次 Chunk 查詢過程中發生的;
  • 步驟 5 開始,恢復正常的事件日誌捕獲,並迴圈遍歷每個按順序捕獲到的事件,如果事件發生在 lw 前,則直接添加到輸出結果的記憶體中;
  • 如果事件 e 進入到了 lwhw 的區間中,則會在步驟 3 中的結果 chunk 中剔除與 e 具有相同主鍵的記錄,lwhw 視窗內到達的事件表示在查詢 Chunk 過程中有更「新」的數據達到,因此剔除掉 chunk 結果中的「舊數據」,保證「新數據」能夠被最終結果應用;
  • 如果事件 e 已經超過了 hw,則直接將 chunk 結果中剩餘的所有記錄附加到輸出結果末尾。

下麵以一個具體的例子來演示一下演算法的過程:

上圖中以 k1-k6 表示一張表中的主鍵值,change log 中的每個事務日誌事件也以主鍵標識為對該行數據的修改,步驟 1-4 與演算法中的步驟編號相對應。圖中表示了某次 Chunk 的查詢過程,暫停事件日誌捕獲後,先後執行了步驟 2-4,在記憶體中產生了一個 chunk 結果,併在源資料庫的事務日誌中記錄了兩條 watermark。

上圖中是步驟 5-7 的過程,我們以主鍵作為依據,從 chunk 結果中剔除了 LH 視窗中修改數據事件對應的相關記錄。

最終,將剩餘的 chunk 結果附加到 H 之後,就完成了一個 Chunk 的選擇過程。

總結

本文詳細介紹了 Debezium 的 Incremental snapshot 的實現基礎——DBLog,它在原有的 CDC 基礎上使用一種基於 Watermark 的框架,擴展了 Full state capture 的功能,能夠在事務日誌事件捕獲開啟的同時執行快照,支持掛起和恢復操作,且用戶能在任何時間點開啟該快照操作。


Enjoy GreatSQL

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 一 演算法複雜度 演算法複雜度分為時間複雜度和空間複雜度。時間複雜度是指執行演算法所需要的計算工作量;而空間複雜度是指執行這個演算法所需要的記憶體空間。 演算法的複雜性體運行該演算法時的電腦所需資源的多少,電腦資源最重要的是時間和空間(即寄存器)資源,因此複雜度分為時間和空間複雜度。 二 時間複雜度 2.1 ...
  • 系統: 銀河麒麟 前提條件: 已經安裝了 fcitx 插件,因為QTcreator本身不支持中文輸入,需要插件支持; 場景1: 一臺電腦;使用普通用戶(例如:user01)登錄並打包一個可以執行的QT程式(我使用的是QT 5.6.3),程式中至少有一個文本輸入框用於測試,其它UI組件隨意;打開us ...
  • Linux的定時任務是基於cron驅動做到的 安裝 Ubantu系統下安裝crontab 正常情況下需要先執行:apt-get upgrade 進行升級 安裝:apt-get install cron 啟動:service cron start 重啟:service cron restart 停止: ...
  • Linux的文件系統分層結構: Lunux文件系統常用的目錄如下: 根目錄(/):根目錄是整個系統最重要的一個目錄,因為不但所有的目錄都是由根目錄衍生出來的,同時根目錄也與開機、還原、系統修複等操作有關。 執行文件目錄(/bin):所有用戶使用的基本命令:不能關聯至獨立分區,OS啟動即會用到的程式 ...
  • 本文章沒有任何宣傳產品等盈利性質,所有的陳述均為博主真實的日常使用。 關於電腦 現在很多學電腦的同學總是抱怨自己的電腦卡卡卡,打開一看360,金山等安全軟體在瘋狂打架,桌面各種文件堆得也是稀碎,再打開文件資源管理器一看,好家伙,C盤都紅了,各種文件堆在盤裡也是亂七八糟。清理垃圾本身沒多煩,21世紀 ...
  • 一、安裝VMware Workstation虛擬機 下載VMware Workstation 16 PRO虛擬機 https://www.vmware.com/cn/products/workstation-pro/workstation-pro-evaluation.html,下載後安裝即可,安裝 ...
  • 1.虛擬機下載 官網下載地址:https://www.kali.org/get-kali/#kali-virtual-machines 選擇VMware版本下載,並解壓 2.打開虛擬機 選擇打開虛擬機,瀏覽到剛纔壓縮包解壓路徑,選擇.vmx文件打開 開啟此虛擬機 用戶名密碼都是kali 3.設置ro ...
  • 世界上的開源許可證(Open Source License)大概有上百種,而我們常用的開源軟體協議大致有GPL、BSD、MIT、Mozilla、Apache和LGPL。 從下圖中可以看出幾種開源軟體協議的區別。 以下是上述協議的簡單介紹: GPL GNU是GNU General Public Lic ...
一周排行
    -Advertisement-
    Play Games
  • PasteSpider是什麼? 一款使用.net編寫的開源的Linux容器部署助手,支持一鍵發佈,平滑升級,自動伸縮, Key-Value配置,項目網關,環境隔離,運行報表,差量升級,私有倉庫,集群部署,版本管理等! 30分鐘上手,讓開發也可以很容易的學會在linux上部署你得項目! [從需求角度介 ...
  • SQLSugar是什麼 **1. 輕量級ORM框架,專為.NET CORE開發人員設計,它提供了簡單、高效的方式來處理資料庫操作,使開發人員能夠更輕鬆地與資料庫進行交互 2. 簡化資料庫操作和數據訪問,允許開發人員在C#代碼中直接操作資料庫,而不需要編寫複雜的SQL語句 3. 支持多種資料庫,包括但 ...
  • 在C#中,經常會有一些耗時較長的CPU密集型運算,因為如果直接在UI線程執行這樣的運算就會出現UI不響應的問題。解決這類問題的主要途徑是使用多線程,啟動一個後臺線程,把運算操作放在這個後臺線程中完成。但是原生介面的線程操作有一些難度,如果要更進一步的去完成線程間的通訊就會難上加難。 因此,.NET類 ...
  • 一:背景 1. 講故事 前些天有位朋友在微信上丟了一個崩潰的dump給我,讓我幫忙看下為什麼出現了崩潰,在 Windows 的事件查看器上顯示的是經典的 訪問違例 ,即 c0000005 錯誤碼,不管怎麼說有dump就可以上windbg開幹了。 二:WinDbg 分析 1. 程式為誰崩潰了 在 Wi ...
  • CSharpe中的IO+NPOI+序列化 文件文件夾操作 學習一下常見的文件、文件夾的操作。 什麼是IO流? I:就是input O:就是output,故稱:輸入輸出流 將數據讀入記憶體或者記憶體輸出的過程。 常見的IO流操作,一般說的是[記憶體]與[磁碟]之間的輸入輸出。 作用 持久化數據,保證數據不再 ...
  • C#.NET與JAVA互通之MD5哈希V2024 配套視頻: 要點: 1.計算MD5時,SDK自帶的計算哈希(ComputeHash)方法,輸入輸出參數都是byte數組。就涉及到字元串轉byte數組轉換時,編碼選擇的問題。 2.輸入參數,字元串轉byte數組時,編碼雙方要統一,一般為:UTF-8。 ...
  • CodeWF.EventBus,一款靈活的事件匯流排庫,實現模塊間解耦通信。支持多種.NET項目類型,如WPF、WinForms、ASP.NET Core等。採用簡潔設計,輕鬆實現事件的發佈與訂閱。通過有序的消息處理,確保事件得到妥善處理。簡化您的代碼,提升系統可維護性。 ...
  • 一、基本的.NET框架概念 .NET框架是一個由微軟開發的軟體開發平臺,它提供了一個運行時環境(CLR - Common Language Runtime)和一套豐富的類庫(FCL - Framework Class Library)。CLR負責管理代碼的執行,而FCL則提供了大量預先編寫好的代碼, ...
  • 本章將和大家分享在ASP.NET Core中如何使用高級客戶端NEST來操作我們的Elasticsearch。 NEST是一個高級別的Elasticsearch .NET客戶端,它仍然非常接近原始Elasticsearch API的映射。所有的請求和響應都是通過類型來暴露的,這使得它非常適合快速上手 ...
  • 參考delphi的代碼更改為C# Delphi 檢測密碼強度 規則(仿 google) 仿 google 評分規則 一、密碼長度: 5 分: 小於等於 4 個字元 10 分: 5 到 7 字元 25 分: 大於等於 8 個字元 二、字母: 0 分: 沒有字母 10 分: 全都是小(大)寫字母 20 ...