CloudCanal x OceanBase 數據遷移同步優化

-Advertisement-

簡述 CloudCanal 去年支持 OceanBase 數據遷移同步能力後，隨著使用用戶增多以及問題反饋，近期對該能力進行了一輪較大規模的優化。本篇文章簡要介紹這些優化點，以及未來該能力的演進方向。優化點大幅提升同步性能 CloudCanal 目前使用 OceanBase LogProxy ...

簡述

CloudCanal 去年支持 OceanBase 數據遷移同步能力後，隨著使用用戶增多以及問題反饋，近期對該能力進行了一輪較大規模的優化。

本篇文章簡要介紹這些優化點，以及未來該能力的演進方向。

優化點

大幅提升同步性能

CloudCanal 目前使用 OceanBase LogProxy 做增量數據訂閱，使用方式相對簡單明瞭。

@Override
public void notify(LogMessage message) {
    try {
        ParsedEntry entry = msgConvertor.convertMsgToEntry(message);

        if (entry == null) {
            return;
        }

        instance.getEventStore().put(entry);
    } catch (Exception e) {
        String msg = "parse ob msg failed.msg:" + ExceptionUtils.getRootCauseMessage(e);
        log.error(msg, e);
        throw new LogProxyClientException(ErrorCode.E_PARSE, msg);
    }
}

消息解析對性能影響相對小，攢批和 對端寫入方式 影響更大。

攢批方面，我們將變更事件寫入記憶體隊列後，按照 個數/容量閾值(increBatchSize) 或 超時時間(fetchFromBrokerTimeoutMs) 刷出，提升批量寫入的粒度。

對端寫入方式，根據不同數據源，我們採用了 batch 、multisql 、並行、 upsert 等技術提升寫入效率。

統一各類表全量掃描方式

全量數據掃描 是 CloudCanal 全量數據遷移(或數據初始化)重要組成部分，需滿足 性能優秀（2KB/record,>= 100k records 掃描速率）、可斷點續傳、可預測進度、表相容性好 的要求。

其中前三者是業務要求，最後一種是儘可能滿足前三者的前提下，做到更多表的相容。

CloudCanal 碰到的"表"包含以下類型

關係型資料庫
- 無/單/多主鍵
- 各種類型主鍵(整型/浮點/日期/二進位等)
- 差異值主鍵(有/無符號，null值/空值，超長值)
- 各種類型分區
- 差異數據量(1萬，100萬，1000萬，1億，10億，100億)
- 實體表/視圖/臨時表
消息中間件
- 各種命名規範
- 無/有分區
- 順序/非順序
文檔資料庫
- 規範/非規範(schemaless)
- 無/有行業規範格式(ObjectId)
緩存資料庫
搜索引擎

CloudCanal 全量數據掃描主要面向關係型資料庫，性能要求、斷點續傳能力、進度預測能力都基於主鍵展開。

此次優化，我們做瞭如下幾方面工作，統一了掃描邏輯，並且讓無/單/多主鍵、各種類型主鍵、分區表都可斷點續傳

以主鍵、分區作為斷點續傳位點
掃描語句加入分區指定(如有)、元組比較(單/多主鍵)、按元組排序、指定分頁數等部分
對比位點最大值、掃描行數方式判定掃描是否結束

此外，各個數據源可根據自身差異性，可擴展掃描語句、最大最小位點值獲取邏輯、鏈接自定義(設置超時等)、執行語句上下文自定義(設置fetchSize等)。

支持全局索引表

全局二級索引（GLOBAL）對分散式資料庫有著非常重要的作用，它讓原本 多分區數據檢索 操作 弱化成單分區檢索，加速不同維度點查響應，提升 QPS。

對於 OceanBase 對端寫入，CloudCanal 預設採用關係型資料庫 INSERT IGNORE/ON DUPLICATE KEY UPDATE 規避主鍵/唯一鍵衝突。

但是對於帶有 GLOBAL 索引的表，OceanBase 不支持 INSERT IGNORE 操作，所以此次優化，我們寫入 OceanBase 的 INSERT 操作預設改為 ON DUPLICATE KEY UPDATE (REPLACE)。

異構 DDL 同步轉換優化

從異構資料庫同步 DDL 到 OceanBase，我們優化成白名單模式。

如 MySQL 到 OceanBase DDL 同步，預設支持

ALTER TABLE xxx ADD/DROP/MODIFY COLUMN
CREATE INDEX
RENAME TABLE

優化同時去除了 ALTER TABLE xxx CHANGE COLUMN、AFTER/BEFORE 等 OceanBase 現階段不支持的語句。

此項能力隨著 OceanBase 產品能力的進化而不斷豐富。

解決時間戳自更新問題

對於類似 gmt_create datetime/timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 時間欄位定義，當源端該欄位值變化區間小於時間精度（被程式判定未變化），並且寫入對端並非採用 upsert 方式（精確欄位更新），那麼該欄位數據將不一致。

CloudCanal 在精確欄位更新模式下，預設將時間欄位置為更新狀態，確保將源端值帶到對端，解決不一致的問題。

演進方向

OceanBase 商業級增量組件相容

OceanBase 商業版 OMS 的數據訂閱能力有別於目前社區版的 LogProxy，如 OceanBase 官方逐步擴大其使用面，CloudCanal 將第一時間跟進相容。

更快的數據校驗和訂正能力

分散式資料庫相對單機資料庫，單表數據量大幅度增加（億級表相當常見），數據校驗和訂正性能相比數據初始化，更加依賴數據掃描的性能，為此，CloudCanal 將開放 單表分片/分區並行掃描 的能力。

更強的結構遷移和 DDL 同步能力

大表 通用/特殊化分區 是常見操作，目前 CloudCanal 對錶分區的結構遷移並未有效支持，這種分區的結構遷移，對於同構資料庫相當必要。後續，我們將提供 分區信息的結構遷移。

總結

本文主要介紹了 CloudCanal 在過去一段時間對 OceanBase 數據遷移同步能力的優化,從而是這個能力具備更強的性能、更好的相容性、更加穩定的數據遷移同步表現。

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