【GaussDB遷移攻略】DRS支持CDC，解決大規模數據遷移挑戰

1?背景介紹

2?CDC的實現原理

3?DRS的CDC實現方式

4?DRS的CDC使用介紹

5?總結

1 背景介紹

隨著國內各大行業數字化轉型的加速，客戶的數據同步需求越來越復雜。特別是當需要將一個源數據庫的數據同時遷移到不同的目標庫場景時，華為云通常會創建一個或多個DRS（Data Replication Service）任務來進行數據同步。

但是，隨著源庫數據量的增大，DRS任務數量也越來越多，會造成源庫性能下降，甚至影響源庫正常業務。

為了解決這一問題，華為云采用了DRS支持CDC（Change Data Capture，變更數據捕獲）的數據遷移方案。本文將詳細介紹其實現原理、實現方式及使用方法。

2 CDC的實現原理

CDC的核心思想是監測并捕獲數據庫的變動（包括插入、更新和刪除操作），并將這些變更按發生的順序完整記錄下來，以供其他服務進行訂閱及消費。

CDC主流的實現機制有2種：基于查詢和基于日志。

第一種，基于查詢

實現方式：通過SQL語句查詢數據庫中的變更記錄。

優點：實現簡單。通過簡單SQL命令，即可完成數據查詢，無需額外適配。

缺點：

1）高延遲，依賴查詢效率。

2）影響源庫性能。

第二種，基于日志

實現方式：通過解析日志，獲取數據庫的變動記錄。

優點：

1）低時延。數據變化快速記錄到日志中，解析識別速度快。

2）高保真。日志中包含完整的DDL和DML變更，可以精確捕捉源庫的各種變動。

3）不會增加源庫壓力。

缺點：靈活性有限。各個引擎的日志機制不同，需要深入了解后適配開發。

3 DRS的CDC實現方式

DRS的CDC功能主要借鑒了CDC的思想，采用基于日志的方式，并提出了1+N的架構創新，如圖1所示。該架構通過一個CDC任務連接源庫進行日志抽取和解析，而下游的多個DRS任務則直接通過CDC獲取數據進行增量同步，不再連接源庫。因此也不會對源庫產生壓力。

圖1 DRS的CDC實現架構

圖1中，CDC負責日志下載、日志解析和增量數據的發布；DRS負責全量遷移、日志下載、日志解析(過濾)和增量數據回放。

在新架構中，需要2個任務來完成數據遷移，相對于單任務完成遷移操作，低時延和高可靠成為該架構的主要技術挑戰。

3.1 低時延

3.1.1 NIO網絡通信

為了保證低時延，需要CDC和DRS任務之間的數據高效傳輸。NIO技術成為華為云的優選，這種面向緩沖區、基于通道的I/O處理方式，能夠高效地處理大量數據和高并發請求。

NIO的核心組件：

緩沖區(Buffer)

用于存儲和處理CDC和DRS任務各自的數據，確保數據傳輸的高效性。

通道?(Channel)

實現CDC和DRS任務之間的數據傳輸，支持雙向和異步操作，提高數據傳輸的效率和可靠性。

選擇器(Selector)

管理多個通道的IO事件，確保一個線程可以同時監控多個通道的IO操作，實現非阻塞IO，提高系統的并發處理能力。

典型NIO模型的處理方式，如圖2所示，一個線程可以管理多個網絡連接。

圖2?典型NIO模型的處理方式

回到我們業務本身CDC(RFS-Server)和DRS(RFS-Client)進行數據傳遞時，我們采用多路復用IO模型，交互方式如圖3所示：

圖3 CDC和DRS組件交互

SocketListener線程：實時監聽來自RFS-Client發送的連接請求；

SocketReader線程：負責校驗請求是否有效，讀取下游任務發送的命令，并進行分發處理；

RequestProcesser線程：執行具體操作，如讀取文件長度、讀取文件屬性等。

傳輸性能測試結果：

測試項（客戶端數量）	平均速度(MB/s)	最小(MB/s)	最大(MB/s)
1	268.2	129.1	622.9
5	112.9	29.1	833.9

測試環境：

類型	規格
ECS實例	c3.xlarge.2

3.1.2?數據壓縮

對已解析的日志文件進行壓縮，以減少磁盤占用，降低存儲成本，并進一步提高數據的讀寫性能。

壓縮算法

在數據遷移過程中，如果進行壓縮，那么無損壓縮算法成為我們的必選。當前選用LZ4壓縮算法，盡管壓縮率不是最優（接近2.0），但是壓縮和解壓縮速度極快。

LZ4?的主要算法思想是將重復的字符串替換為對已識別字符串的引用。具體工作原理是在數據流中使用滑動窗口識別出現在一定范圍內的數據序列。找到匹配項后，算法會將第二次出現的匹配項替換為對第一次出現的引用，從而減少數據的大小。

LZ4專注于查找固定長度的序列，簡化了匹配過程。同時，使用哈希表存儲和快速檢索固定長度序列的位置，以實現快速引用。

從源庫抽取的日志文件，統一解析為THL文件。存儲格式如下：

字符串：使用一個字節表示是否存在，實際內容使用UTF格式；

基本數據類型：使用固定長度。

THL文件是序列化和反序列嚴格對稱。這種緊湊性設計，占用更少的存儲空間。

數據剪枝

從實際業務需求出發，在CDC任務中提供2種對象選擇方式：整庫和部分表選擇。通過對象選擇，過濾冗余的源庫日志數據，減少磁盤空間占用。

3.2 高可靠

3.2.1?數據安全

在數據遷移過程中，下游的所有DRS任務都依賴CDC，從中拉取日志數據。除了性能外，如何可靠地傳輸數據，并保證傳輸過程中數據不丟失，成為衡量可靠性的關鍵因素。

文件完整性校驗

由于網絡環境的復雜性，數據在傳輸時有可能會出錯。因此，針對傳輸的每條數據，將校驗其序列號和長度是否一致。傳輸完成后，再次校驗文件長度，來保證文件的一致性。

加密傳輸

針對安全極度敏感客戶，可以啟動SSL傳輸加密。SSL通過使用數字證書和加密算法建立加密連接，保證數據傳輸過程的機密性。然而，啟用?SSL?傳輸會導致性能下降約三倍，建議按需使用。

安全位點

CDC任務從源庫拉取日志時，受限于源庫日志的保留時間。如果日志被清理，則無法繼續從源庫拉取。對于DRS任務，從CDC拉取日志時，不再受限源庫日志的清理，可以持續拉取使用。

但是，用戶可以調整放大CDC任務的同步對象范圍。在這種情況下，調整前產生的數據，即沒有新增對象的日志數據將不再可用。故引入“安全位點”概念，確保之前的數據不再支持拉取使用，且從安全位點之后的數據都是完整有效。

3.2.2?故障恢復

DRS任務自身已具備斷點續傳和故障恢復等功能，針對CDC任務和DRS任務之間因為網絡閃斷等原因，導致通信斷開時DRS任務失敗，如果通信條件恢復，那么，DRS任務也需要快速恢復。

文件異常快速識別

通信中斷后，為了保證THL文件數據的完整性，會清理本地文件，并重新拉取。

DRS任務在生成本地THL文件時，會標記文件的UUID，通過UUID的變動，可以快速識別文件變化，如圖4所示。

圖4?文件異常快速識別?

4 DRS的CDC使用介紹

DRS的CDC使用介紹（以MySQL為例）

1）創建CDC任務

步驟一創建CDC實例

設置數據流動方向、源庫引擎、源庫實例

步驟二源庫配置

填寫源庫用戶名和密碼，進行測試連接。

步驟三任務配置

設置同步對象的范圍，支持不同庫配置不同規則。

步驟四預檢查

檢查源庫是否滿足遷移條件，權限、表結構、源庫參數等校驗。

2）創建同步任務

步驟一創建同步實例

配置數據流動方向、源庫引擎、同步模式。

步驟二源庫及目標庫

源庫信息中，開啟CDC開關，可以選擇CDC任務，后續從CDC中拉取日志。

步驟三設置同步

在“編輯同步任務”頁面，默認的同步對象是CDC中已選擇的對象范圍，選擇后，支持映射。

步驟四數據加工

針對已選擇的對象，配置數據過濾，列加工等。

步驟五預檢查

檢驗CDC任務連通性、對象選擇范圍是否合理等。

3）?CDC任務運行

發布列表

DRS任務啟動后，即可再發布列表中查看下游的所有DRS任務。

5 總結

DRS支持CDC的數據遷移方案，即CDC通過拉取源庫日志，解析成標準的THL格式文件，進行增量數據發布。DRS直接拉取THL文件，進行解析和過濾，實現增量數據回放，有效的降低了多個DRS任務直連源庫對源庫性能的影響。針對源庫數據量級大需要拆分任務遷移（一對多場景），以及對源庫性能敏感客戶優先推薦使用該方案。