文章目錄
- 摘要
- 一、幾種主流的資料庫同步方式
- 二、架構及作業原理
- 三、全量同步和實時增量同步機制
- 四、源和目標
- 五、舉例:Oracle 資料實時同步到 Elasticsearch
- 六、目標和源資料一致性
- 七、異構資料型別轉換
- 八、總結
摘要
資料庫同步有3大難題:
1是如何保障目標和源資料一致性;
2是異構資料庫如何做資料型別轉換,導致資料同步失敗的原因常常是因為資料型別不一樣;
3是在資料越實時越有價值的背景下,同步程序中能否做到實時同步,
一、幾種主流的資料庫同步方式
方式一:基于無侵入的日志模式(如Oracle redo、Mysql binlog)
基于日志的采集方式無需在源庫端部署任務代理程式(Agent)及建任何表,對源資料庫無侵入和影響壓力;
方式二:基于時間戳
同步程序通過特定屬性(如時間戳、自增序列)來識別新插入的資料,該方式實作最簡單,但無法記錄洗掉和更新,也不具備實時的能力;
方式三:基于觸發器
基于資料庫的觸發器機制,當執行DML相關陳述句時,執行動作來捕獲資料,該方式會降低系統能,因此大多數場景下,生產系統不允許添加觸發器,
方式四:基于快照
基于快照的方式,可以通過比較源表和快照表來獲得資料變化,但需要消耗大量存盤空間和計算資源,
方式五:基于離線批處理
通過jdbc查詢來批量獲取資料,會進行資料表的大范圍掃描和資料提取,會對資料庫產生大量開銷,
本文主要探討無侵入的CDC模式,并以運用這種模式的資料庫同步云工具 Tapdata Cloud 舉例,你要問我為啥用它舉例,原因只有一個:永久免費,
二、架構及作業原理
Tapdata Cloud包含兩部分:
- Tapdata Cloud Manager,TCM是Tapdata Cloud的管理端,負責agent實體的安裝,同步任務的配置、分發、任務狀態監測,
- Tapdata agent,是Tapdata Cloud資料同步服務的執行實體,負責從TCM獲取任務資訊,通過流式技術從源系統獲取資料、處理轉換資料并發送到目標系統,并在任務執行程序中監測并上報任務狀態至TCM,

有朋友可能會擔心這個云平臺會不會把我要同步的資料泄露出去?
從Tapdata Cloud 作業原理上可以看出:
- 同步實體節點單向連接管控端運行服務, Tapdata agent實體節點對外不主動暴露網路資訊,只會連接 TCM管理端服務,獲取任務資訊、上報狀態資訊,
- 用戶部署的Tapdata agent實體節點和 TCM 通信鏈路采用 HTTPS 協議,
- 自建模式下,所有資料流轉均發生在受用戶管理的服務器和網路環境,
可見,資料同步程序中資料泄露的問題大可不必擔憂,
三、全量同步和實時增量同步機制
Tapdata Cloud 這款云同步工具支持全量同步和實時增量同步,實作的程序如下圖所示:

四、源和目標
據 Tapdata Cloud 最新版本,目前支持了:
| 資料庫 | 版本 | 作為源 | 作為目標 | 是否可用 |
|---|---|---|---|---|
| mysql | 5.x,8.x | 支持 | 支持 | 是 |
| oracle | 9i, 10g, 11g, 12c | 支持 | 支持 | 是 |
| sqlsever | 2005, 2008, 2012, 2014, 2016, 2017 | 支持 | 支持 | 是 |
| mongodb | 3.2, 3.4, 3.6, 4.0, 4.2 | 支持 | 支持 | 是 |
| PostgreSQL | 9.x, 10.x,11.x,12.x,13.x | 支持 | 支持 | 是 |
| Elastic | 5.x, 6.x, 7.x | 暫不支持 | 支持 | 是 |
| 達夢資料庫 | 7,8 | 支持 | 支持 | 是 |
| Kafka | 2.3.x及以上 | 暫不支持 | 支持 | 是 |
| Redis | 2.x, 3.x, 4.x | 暫不支持 | 支持 | 即將上線 |
| DB2 | 9.7 LUW版本 | 支持 | 支持 | 即將上線 |
| Sybase | Sybase ASE 15.7 及以上 | 支持 | 支持 | 即將上線 |
| Gbase | 支持 | 支持 | 即將上線 |
五、舉例:Oracle 資料實時同步到 Elasticsearch
一般需要做全文檢索的時候,會將 Oracle 資料實時同步到 Elasticsearch,
第一步:配置 Oracle 連接
- 點擊 Tapdata Cloud 操作后臺左側選單欄的【連接管理】,然后點擊右側區域【連接串列】右上角的【創建連接】按鈕,打開連接型別選擇頁面,然后選擇Oracle

- 在打開的連接資訊配置頁面依次輸入需要的配置資訊

【連 接 名 稱】:設定連接的名稱,多個連接的名稱不能重復
【資料庫地址】:資料庫 IP / Host
【端 口】:資料庫埠
【資料庫名稱】:tapdata 資料庫連接是以一個 db 為一個資料源,這里的 db 是指一個資料庫實體中的 database,而不是一個 schema,
【賬 號】:可以訪問資料庫的賬號
【密 碼】:資料庫賬號對應的密碼
【時 間 時 區】:默認使用該資料庫的時區;若指定時區,則使用指定后的時區設定
第二步:配置 Elasticsearch 連接
- 同第一步操作,點擊左側選單欄的【連接管理】,然后點擊右側區域【連接串列】右上角的【創建連接】按鈕,打開連接型別選擇頁面,然后選擇Elasticsearch

- 在打開的連接資訊配置頁面依次輸入需要的配置資訊,配置完成后測驗連接保存即可,

第三步:建立同步任務,以全量+增量同步舉例
進入Tapdata Cloud 操作后臺任務管理頁面,點擊添加任務按鈕進入任務設定流程

根據剛才建好的連接,選定源端與目標端,

根據資料需求,選擇需要同步的庫、表,如果你對表名有修改需要,可以通過頁面中的表名批量修改功能對目標端的表名進行批量設定.

在以上選項設定完畢后,點擊下方的全量+增量選項并點擊確定按鈕即可完成本次全量同步任務的配置,在點擊確定后將自動回傳任務管理頁面,在任務管理頁面中,點擊右側的啟動按鈕即可使Tapdata Agent 開始執行本次任務,在全量任務執行完畢后,Tapdata Agent 會自動進入增量同步狀態,在該狀態中,Tapdata Agent 會持續監聽源端的資料變化(包括:寫入、更新、洗掉),并實時的將這些資料變化寫入目標端,

點擊任務監控可以打開任務執行詳情頁面,可以查看任務執行的具體資訊,

同理,其他資料庫的同步操作也跟上面步驟一致,比如幾個常用的場景是:
? 從業務資料庫到快取資料庫的實時同步
? 不停機遷移資料庫
? 將主業務中心的資料實時同步至次業務中心
? 構建只讀實體
? 構建異地災備中心
? 構建異地多活
六、目標和源資料一致性
很多人都擔心同步的資料可能沒法和源資料一致,Tapdata Cloud 提供了資料校驗功能,包括快速count校驗、表全欄位值校驗和關聯欄位值校驗三種校驗方式,
? 快速count:僅對源表和目標表的行數進行count校驗,速度極快,但是不會展示差異的具體欄位內容,
? 全表欄位值校驗:會對源表和目標表的全部欄位進行逐行校驗,能查出所有欄位的差異,但是速度慢,
? 關聯欄位值校驗:只對源表和目標表的關聯欄位的值進行比對校驗,速度快于全表欄位值校驗模式,
校驗操作步驟
進入資料校驗選單,點擊新建校驗任務創建資料校驗,
【選擇任務】:選擇一個歷史同步任務
【校驗型別】:可選 快速count校驗、表全欄位值校驗和關聯欄位值校驗
【校驗任務名】:默認與選擇的同步任務名字一樣
【校驗頻次】:設定您的校驗的執行頻次
【單次校驗】:只執行一次校驗
【重復校驗】:設定校驗任務重復執行,支持設定校驗執行的起止時間和校驗間隔
【錯誤資料保存條數】:當出現校驗不一致的資料時,不一致資料保存的最大條數,該數值會影響到差異校驗,當錯誤資料條數超出設定的保存條數時,將無法進行差異校驗,
【校驗條件】:添加需要進行校驗的表,點擊自動添加會自動將任務下的所有表全部添加進來,
快速count校驗
創建快速count校驗時只需要選擇到要校驗的表,無需設定關聯條件,

表全欄位值校驗
除了要選擇待校驗表外,還需要針對每一個表設定索引欄位,

在進行表全欄位值校驗時,還支持進行高級校驗,通過高級校驗可以添加JS校驗邏輯,對源和目標的資料進行校驗,

完整示例:以MongoDB查詢示例
JavaScript
function validate(sourceRow){
// 第1步
var targetRow = target.executeQuery({database: "target",collection: "USER",filter: {USER_ID: sourceRow.USER_ID}});
// 第2步
if(sourceRow.USER_ID === targetRow[0].USER_ID){
// 第3步
return {result: 'passed',message: "",data: ""}
}else{
return {result: 'failed',message: "記錄不一致",data: targetRow}
}
}

關聯欄位值校驗
創建關聯欄位值校驗時,除了要選擇待校驗表外,還需要針對每一個表設定索引欄位,

七、異構資料型別轉換
在異構資料庫之間做同步,型別轉換是一大難題,也是導致資料同步失敗的重要原因,Tapdata Cloud 型別映射功能,在系統推演的基礎上,提供了人工調整的能力,這一點比其他資料同步工具都更方便使用,

八、總結
為了達到資料實時要求,并且不對源庫造成干擾,首選 CDC 模式,
現在市面上已經陸續出現了一些資料同步工具,完全沒有必要自己擼代碼了,免費的用起來不香嗎?
希望上文的實操圖文,對你的資料庫同步有幫助,有資料庫相關的問題可以隨時跟我交流!
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/297791.html
標籤:其他
