MySQL開源數據傳輸中間件架構設計實踐

本文根據洪斌10月27日在「3306π」技術 Meetup - 武漢站現場演講內容整理而成。

主要內容：

本次分享將介紹目前數據遷移、數據同步、數據消費，多IDC架構中數據複製技術所面臨問題及現有的產品和方案，並分享新開源的能在異構數據存儲之間提供高性能和強大複製功能的DTLE相關技術內容。

提綱：

1. MySQL Replication
2. DTLE核心場景
3. DTLE設計原則
4. DTLE相關介紹（架構/集羣機制/拓撲結構/技術棧/功能/限制）
5. 同類對比
6. Demo演示
7. 雲間同步案例

你們好，我今天分享的主題是關於愛可生在前不久開源的數據傳輸中間件DTLE，也可簡稱爲DTS。愛可生做爲一家以MySQL爲主的技術服務公司，在咱們服務企業客戶過程當中，常常會遇到各類數據同步的需求，能作數據同步的軟件不少，但未能找到知足咱們全部需求的軟件，因此咱們決定自研一款數據傳輸軟件，結合咱們客戶的需求場景作了DTLE，並選擇在10月24號「程序員節」向社區開源。

今天主要是對DTLE的一些技術架構，跟你們分享。

1. MySQL Replication

MySQL如此受歡迎，其緣由和MySQL原生支持了 Replication密不可分。基於replication能力社區也是玩出了各類拓撲架構。

1.1 MySQL Replication架構

這張圖對DBA們應該並不陌生，左邊是MySQL主實例，右邊是MySQL從實例，數據變動記錄在binlog中。主實例的Dump線程，將binlog 事件經過網絡推送給從實例。

從實例的IO線程將接收到事件寫入本地relay log，SQL線程讀取relay log bing進行回放執行，這是MySQL Replication的基本流程。

既然MySQL已經有了數據同步能力，那爲什麼還要作DTLE呢？

1.2 MySQL Replication的限制

- 篩選功能不足

MySQL Replication只能在庫表級別作篩選，沒法在行級別進行篩選。

- 數據落地，開銷較大

MySQL Replication須要日誌或數據落地，這會產生存儲空間的開銷。

- 靈活性較弱

沒法支持較爲複雜的複製拓撲結構，以及在跨網絡邊界不一樣數據中心場景的。

- 應用場景多爲高可用

MySQL replication更多以高可用、讀寫分離應用場景爲主，利用開源工具實現Master failover以及讀寫分離架構。

2. DTLE的核心場景

MySQL Replication主要應用在數據全同步的場景。而對於DTLE主要解決如下場景：

- 異地多活

異地多活的場景一般創建在網絡環境不佳的條件下，咱們經過數據壓縮、加密、限速等方法，保障複製的可靠性、安全性、效率。解鎖跨網絡邊際、雙向同步等能力，在業務配合下，實現異地多活的。

- 數據匯聚分發

數據的匯聚和分發，須要支持到庫、表、行這幾個級別。好比：在業務垂直分庫場景下可將前端多個分庫實例彙總到實例中進行統計分析。數據行按不一樣條件分發到下游節點，條件能夠是簡單的where條件，也但是簡單函數表達式等。

- 數據訂閱

數據訂閱的場景是對MySQL binlog日誌進行解析，將增量變化實時同步給Kafka消息隊列，其餘系統經過kafka訂閱須要的數據。

- 在線數據遷移

在線數據遷移，要簡化MySQL到MySQL或其餘DB到MySQL的遷移過程，減小停機時間，目前還只支持MySQL間的遷移。首先抽取全量的數據，並獲取增量起始的快照點，當全量回放完畢後，從增量起始點開始同步增量數據。

這對MySQL分佈式架構的數據分片擴容特別有幫助，通常咱們將先預分片好的物理分片放在相同MySQL實例中，當數據量增加超過實例處理能力時，就須要講分片遷移到新的實例節點，遷移過程確定但願儘可能平滑不影響業務。DTLE能夠配合咱們以前開源分佈式中間件DBLE，進行在線擴容。

- 雲間同步

公有云RDS用戶會有一些上下雲和雲間遷移同步的需求，咱們測試了幾家雲廠商，針對雲廠商自研的RDS for MySQL的特色，實現不一樣雲廠商的RDS之間進行數據同步。

3. DTLE設計原則

以上是DTLE主要的應用場景。軟件設計DTLE力求兩個基本原則：易用性與可靠性。

- 易用性

做爲軟件的使用者和開發者，咱們特別重視產品的使用體驗，上手簡單，易於部署是必須的，沒有複雜的部署條件要求，沒有外部依賴，安裝配置步驟越簡單越好，儘量符合使用者的操做習慣。

- 可靠性

可靠性也必不可少，咱們將DTLE的設計採用分佈式的架構，具有扛單點風險和故障切換的能力。元數據信息保存在分佈式一致性KV存儲中，若是某工做節點或進程掛了，工做任務會轉移至其餘進程繼續以前的斷點處理數據同步，不影響服務連續性。

4. DTLE相關介紹

DTLE （Data-Transformation-le） 是愛可生10月24日在「程序員節」貢獻開源社區的 CDC 工具，主要具有如下特色：

• 多種數據傳輸模式：支持鏈路壓縮，支持同構傳輸和異構傳輸，支持跨網絡邊際的傳輸
• 多種數據處理理模式：支持庫/表/行級別 數據過濾
• 多種數據通道模式：支持多對多的數據傳輸、支持迴環傳輸
• 多種源/目標端：支持MySQL - MySQL的數據傳輸，支持MySQL - Kafka的數據傳輸
• 集羣模式部署
• 提供可靠的元數據存儲
• 可進行自動任務分配
• 支持自動故障轉移

Github地址： https://github.com/actiontech...

4.1 DTLE架構

DTLE架構上包含兩種角色的進程，Agent角色與Manager角色。Manager角色主要負責元數據信息存儲，任務的接收和分發，Agent節點健康狀態檢測、故障轉移。Agent主要負責數據讀取，binlog解析，數據篩選、壓縮、傳輸、回放等。

用戶經過http協議訪問Manager發佈job，job是以json格式的配置項，裏面定義了源數據庫實例，目標數據庫實例，須要複製的schema或table對象，數據的篩選條件等信息，任務提交後manager會分配給可用的agent進程，agent根據任務配置鏈接數據庫實例，開始全量或增量的數據同步。

4.2 DTLE的集羣機制

DTLE支持的多種拓撲結構，最簡單的1對1同步，n對1的匯聚同步模式，1對n的數據分發同步模式。

在跨數據中心的場景，虛線框內是兩個不一樣的數據中心，DTLE部署在不一樣的數據中心，DTLE負責本數據中心的數據讀取或回放，DTLE將數據壓縮後經過網絡發送到對端，減小了對帶寬的利用，適用於窄帶寬的網絡環境下。

在跨數據中心有多個實例之間須要數據同步，若是經過MySQL Replication須要創建多條鏈路通道，而經過DTLE能夠在數據中心間創建一條通道同步多個實例的數據，網絡策略配置更簡單，也避免了MySQL服務對外暴露。

跨數據中心的雙向同步能力，能夠應用在數據中心雙活的場景，但數據層自身還沒法作衝突檢測，須要在應用層來保障數據不會衝突。

4.4 DTLE技術棧

在DTLE的開發過程當中咱們藉助了一些優秀的開源組件，來支撐起整個架構。

咱們選用的開發語言是Golang，它的好處是開發效率高，性能有保障，部署也方便，build後的二進制文件自帶運行時環境，徹底不須要擔憂軟件依賴問題。

網上有許多優秀的Golang開源項目，Hashicorp公司就是其中一家以分佈式應用見長的開源軟件公司，他們開發了不少優秀的DevOps 基礎設施組件，包括Vagrant、Packer 、 Terraform 、Serf 、Consul , Vault 和 Nomad 等，咱們使用了部分組件來構建DTLE。

nomad是一個集羣管理器和調度器，咱們利用它來構建基礎架構，解決的任務調度和集羣管理的問題，在此基礎上咱們開發所需的任務模板。

consul是一個分佈式KV存儲，nomad也集成了consul，咱們用它來作manager元數據信息存儲。

serf是基於gossip協議的節點狀態檢測組件，可以快速檢測到故障節點並踢出集羣，主要用來解決agent節點的failover，若是某個agent節點不可用，這個節點就會被移出集羣。

NATS是一款開源的輕量級消息系統組件，咱們在agent之間的數據傳遞使用了NATS。

以上是DTLE採用的開源組件。若是以前對這些組件由所瞭解，能夠幫助理解DTLE的架構原理。

4.5 DTLE功能

DTLE的回放是支持binlog回放和SQL回放。binlog回放不須要對binlog事件進行轉換，能夠直接在MySQL中回放，精度高，但沒法作數據轉換或篩選。SQL回放是直接把binlog事件解析成SQL文本，能夠進行數據的轉換和篩選。

咱們模仿了MySQL MTS並行回放機制，基於MySQL 5.7的邏輯時鐘模式，提升並行回放的效率。

自動建表，在數據遷移的場景下，目標端不須要事先創建表結構，只須要定義好job須要同步的對象，DTLE會自動建表並同步存量數據。

DTLE的所有功能總結：

• 集羣式架構部署，支持故障轉移
• binlog回放、SQL回放
• 仿MySQL MTS機制並行回放
• 支持增量斷點續傳
• 全量&增量同步
• 庫級、表級、行級篩選
• 鏈路壓縮、跨網絡邊際
• 自動建表
• 支持DDL

4.6 DTLE限制

• 僅支持 MySQL 5.6/5.7 版本
• 僅支持 InnoDB 引擎
• 僅支持如下字符集: latin一、latin二、gbk、utf八、utf8mb四、binary
• 僅支持binlog_format=row和binlog_row_image=full
• 源端和目標端lower_case_table_names配置必須保持⼀一致
• 必須開啓 GTID
• 不支持 Trigger
• 僅支持MySQL認證方式 mysql_native_password, 暫不支持其餘類型的

default_authentication_plugin

5. 同類對比

咱們選取了其餘同類的開源軟件debezium、streamsets、otter、DTLE，一塊兒橫向對比了相關特性。

- 全量/增量

debezium是支持全量增量的，對於streamsets和otter他們並無全量支持，只能作一些增量數據的支持，DTLE支持全量和增量。

- 元數據全局一致性

元數據信息的全局一致性是指在作全量數據遷移時如何得到增量數據起始的一致性位點。debezium是經過全局讀鎖或者快照讀索實現的。streamsets和otter不支持全量，因此也不用考慮這個場景。

DTLE沒有使用全局讀鎖，它在快照讀的事務中讀取存量數據，並在事務開啓先後分別獲取GTID。若是先後兩個GTID是相等的，意味着在這個事務開啓以後即便沒有新的更新，後續能夠今後GTID作增量同步。若是說先後兩個GTID不等，事務將回滾，再重複上述流程。

- 數據過濾

在數據過濾方面，debezium支持庫級， streamsets支持行級，otter能夠自定義，DTLE是庫、表、行三個等級都支持。

- 數據映射

數據映射上，debezium可以支持到表級的映射到普通表之間，原表、錄入表可能不一樣的表之間能夠進行數據映射。一樣streamsets也是，otter也能夠靈活自定義。DTLE當前不支持數據映射，還在Roadmap中。

- 事務性

在MySQL binlog中一個事務可能包含多個event，咱們選擇兼容在回放時保持其事務性。debezium能夠作到源端的事物性，但不支持目標端的事務性。streamsets自己是沒有事務性的，按event產生進行回放。otter不保持回放的事務性，爲了提升入庫的效率會進行合併操做。DTLE其實目標端和源端均可以保證事務性。

- GTID

DTLE會維護一份獨立的GTID信息，主要來解決一些環形複製場景。其餘三者都是不維護GTID信息的。

- 源端類型

源端類型，debezium支持的數據類型比較多，包括MySQL、Mongo、PostgreSQL、Oracle這幾種都支持。MySQL是基於binlog，mongo是基於 Oplog，其餘幾種PG，SQL sever應該是經過CDC的方式，而非基於日誌方式。streamsets支持許多中數據源，不詳細展開了，otter主要是MySQL。DTLE還只是支持MySQL一種數據庫。

- 目標端類型

debezium僅限於Kafka做爲目標端。streamsets支持不少的目標端，再也不詳細展開。otter支持 MySQL和Oracle，DTLE當前僅支持MySQL和Kafka。

- 部署方式

在部署方式上，debezium和streamsets都是單節點，otter是集羣化的部署方式，DTLE支持單機和集羣化部署。

6.DEMO演示

我這裏準備了一些演示用例，主要演示如下幾個場景，單向同步，表級匯聚，數據分發以及跨IDC雙向複製。

Demo演示腳本： https://github.com/kevinbin/d...

感興趣的同窗能夠本身動手測試！

7.雲間同步案例

咱們作了一個雲間同步的測試，源端是阿里雲RDS，目標端是京東雲RDS，分別在華北區，和華東區。

使用TPCC的模型插入20個倉庫，全部表加起來大概約10億條記錄。全量數據同步完耗時約5小時，平均是1000+ row/s，這裏有關於該測試job的github地址，感興趣的同窗能夠本身測試下。

job連接：
https://gist.github.com/kevin...

將來咱們還會繼續去作其餘雲廠商RDS的測試，以上是我今天的分享內容，謝謝你們！

咱們的開源數據傳輸中間件DTLE是具備專業團隊維護和支持的，在使用過程當中遇到任何Bug和疑難問題均可以獲得及時的修復和解答，歡迎加入DTLE技術交流羣（852990221）！

PPT下載連接： github.com/actiontech/slides