TiDB DM2.0GA有哪些新特性

這篇文章主要介紹“TiDB DM2.0GA有哪些新特性”，在日常操作中，相信很多人在TiDB DM2.0GA有哪些新特性問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”TiDB DM2.0GA有哪些新特性”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

社會數字化、智能化的發展進程中，海量的數據帶來巨大挑戰，各行各業都在加速數字化轉型，越來越多的企業意識到數據基礎設施是成功的關鍵。然而，作為數據基礎設施的核心，傳統數據庫例如 MySQL 面臨性能和容量瓶頸，通過中間件實現的分庫分表方案復雜度高，同時帶來高昂的運維成本。

作為一款企業級 NewSQL 數據庫，TiDB 采用計算、存儲分離的架構，可以根據業務需要進行彈性的擴展，應對更加實時和智能的數據應用需求。TiDB 提供 Data Migration (DM) 生態工具，幫助用戶實現從 MySQL 到 TiDB 數據遷移，有效降低遷移成本和風險。

DM 是由 PingCAP 研發的一體化的數據遷移任務管理平臺，支持從 MySQL、Aurora或 MariaDB 到 TiDB 的全量數據遷移和增量數據復制。DM 2.0 版本現已正式發布，新增高可用、樂觀協調模式下的分庫分表合并遷移等企業級特性，同時帶來一系列易用性的提升，確保用戶的原數據庫可以平滑地切換到 TiDB，完全不用擔心遷移帶來的故障與數據丟失。

##DM 2.0 新特性

數據遷移任務的高可用

DM 2.0 提供數據遷移任務的高可用，部分 DM-master、DM-worker 節點異常后仍能保證數據遷移任務的正常運行。

當部署多個 DM-master 節點時，所有 DM-master 節點將使用內部嵌入的 etcd 組成集群。該 DM-master 集群用于存儲集群節點信息、任務配置等元數據，同時通過 etcd 選舉出 leader 節點，該 leader 節點用于提供集群管理、數據遷移任務管理相關的各類服務。若可用的 DM-master 節點數超過部署節點的半數，即可正常提供服務。

當部署的 DM-worker 節點數超過上游 MySQL/MariaDB 節點數時，超出上游節點數的相關 DM-worker 節點默認將處于空閑狀態。若某個 DM-worker 節點下線或與 DM-master 發生網絡隔離，DM-master 能自動將與原 DM-worker 節點相關的數據遷移任務調度到其他空閑的 DM-worker 節點上并繼續運行。

###樂觀協調模式下的分庫分表合并遷移

DM 1.0 版本支持在線上執行分庫分表的 DDL 語句（通稱 Sharding DDL），通過使用悲觀模式，即當上游一個分表執行某一 DDL 后，這個分表的遷移會暫停，等待其他所有分表都執行了同樣的 DDL 才在下游執行該 DDL 并繼續數據遷移。悲觀協調模式的優點是可以保證遷移到下游的數據不會出錯，缺點是會暫停數據遷移而不利于對上游進行灰度變更、并顯著地增加增量數據復制的延遲。

DM 2.0 版本提供新的樂觀協調模式，在一個分表上執行的 DDL，自動修改成兼容其他分表的語句后立即應用到下游，不會阻擋任何分表執行的 DML 的遷移。樂觀協調模式適用于上游灰度更新、發布的場景，或者是對上游數據庫表結構變更過程中同步延遲比較敏感的場景。

在樂觀協調模式下，DM-worker 接收到來自上游的 DDL 后，會把更新后的表結構轉送給 DM-master。DM-worker 會追蹤各分表當前的表結構，DM-master 合并成可兼容來自每個分表 DML 的合成結構，然后通知相應的 DM-worker 把與此對應的 DDL 遷移到下游；對于 DML 會直接遷移到下游。

DM 2.0 版本試驗性的支持從 MySQL 8.0 遷移數據到 TiDB，同時提供 TLS 支持，構建立體的數據安全體系，保障 DM 組件之間以及 DM 組件與上下游數據庫之間的連接與傳輸的安全與合規，幫助企業實現數據在全生命周期過程中的不丟失、不泄露、不被篡改和隱私合規。

###易用性全面提升

在新特性之外，DM 2.0 版本帶來易用性的全面提升。用戶可以通過 TiUP 進行 DM 2.0 的部署和運維 ，同時支持使用 TiUP 把 1.0 版本的 DM 導入升級為 2.0 版本。在 DM 2.0 中，DM-worker 使用 DM-master 提供的 API 動態進行注冊，在擴容和縮容 DM-worker 時，不再需要重啟 DM-master 組件，有效地提升業務連續性。

對于 AWS Aurora、阿里云 RDS 等由云廠商提供的托管式 MySQL，用戶通常無法獲取 SUPER 權限因而無法在全量數據導出時獲取一致性快照。在 DM 2.0 中，通過記錄全量導出過程開始至結束區間的 binlog position 范圍并在增量階段自動保證 safe-mode 的開啟，在無需用戶手動處理的情況下即保證了數據的最終一致性。對于 Aurora 中如 “SELECT INTO S3” 等特有權限，DM 2.0 在權限檢查過程中也提供了更好的兼容支持。

在 DM 2.0 中 query-status 命令除了能查詢到可能的數據遷移異常外，對于部分常見異常，提供 "Workaround" 信息來指導用戶如何進行處理。DM 2.0 引入 handle-error 命令來替換 DM 1.0 中的 sql-skip 與 sql-replace 命令，簡化了處理數據遷移過程中出錯 SQL 語句的流程。

此外，DM 2.0 加入對全量導出數據及增量 binlog 數據中對應的 sql_mode 的自動處理，確保盡可能地減少手動的配置和干預。DM 2.0 也對一系列功能進行了易用性增強，包括全量導出文件的自動清理、配置參數優化、監控面板優化、log 展示優化等。

##用戶實踐

###微眾銀行

微眾銀行于2014年12月獲得由深圳銀監局頒發的金融許可證，是由騰訊等知名企業發起設立、國內首家開業的民營銀行，致力于為普羅大眾、微小企業提供差異化、有特色、優質便捷的金融服務。

微眾銀行在多個業務場景中使用 TiDB，其中批量任務、流水日志歸檔這兩類場景高度依賴 DM 的分表合表功能。在批量任務場景中，使用 DM 把上游多個 MySQL 實例的同構分表匯總合表到下游 TiDB 中，再借助 TiDB 的水平擴展能力來提升批量效率。在流水日志歸檔場景，同樣使用 DM 把上游多個 MySQL 實例的同構分表進行合表匯總到 TiDB 中，借助 TiDB 的水平擴展能力來提供理論無上限的存儲容量能力。

原先的 DM 1.0 版本在使用過程中遇到一些問題：DM 的 Worker 組件發生異常掛掉后，會導致數據同步暫停，需要人工干預進行恢復，操作較為繁瑣且會影響數據同步的時效性。其次，在金融場景下，一般使用灰度策略進行表結構變更，即對于上游多個 MySQL 實例的同構分表，一般會灰度變更其中一個實例，觀察幾天無異常后，才會繼續對剩下的其他同構分表進行表結構變更，這種場景在 DM 1.0 下會導致數據同步 block 住，同樣會影響數據同步的時效性。

針對 DM 1.0 在實際場景中部分功能的缺失，微眾銀行數據庫團隊通過業務 POC 測試，挖掘和細化了需求，協同 PingCAP 進行了深度的方案討論，并進行了一系列功能的開發和優化工作。DM 2.0 的版本已經涵蓋了組件高可用、支持灰度變更等企業級特性，能夠滿足金融級的數據同步需求。此外，DM 2.0 在易用性上也有大量的優化，比如使用 TiUP 更方便地來部署和維護多套 DM 集群 、Worker 上游 source 配置信息更加簡化、錯誤信息更加清晰易讀等。

###理想汽車

理想汽車致力于研發比燃油車更好的智能電動車，首臺理想 ONE 自 2019 年 11 月正式下線以來，理想汽車僅用 10 個月交付 20,000 輛，創中國造車新勢力最快交付記錄。 微服務已經成為云原生時代企業數字化轉型升級的基礎，目前理想汽車累計 99% 以上，超過400+ 的業務應用都構建在微服務之上，覆蓋車聯網、訂單商城、車輛生產、售后、物流等業務流程。在微服務架構中，每個單獨的微服務都對應獨立的 MySQL 數據庫（基于公有云 RDS），理想汽車采用 TiDB Data Migration (DM) 工具實現把多個 MySQL 庫的數據實時同步到一套 TiDB 集群，來解決兩個業務場景的應用需求。

一方面，TiDB 滿足跨多個 MySQL 數據庫進行實時數據聯查的需求，利用 TiFlash 的 HTAP 能力，提供實時的業務分析報表。另一方面，利用 TiDB 對公有云的多個 MySQL 數據庫做實時的數據備份，在提升業務可用性的同時降低了公有云 RDS 在讀寫分離場景下，實現負載均衡所需要額外使用的從庫資源成本。

基于業務對 DM 工具的強依賴，理想汽車通過 TiUP 把原先 DM 1.0 集群升級到 DM 2.0 ，并對 DM 2.0 的高可用特性進行了深入測試，包括 DM-master 與 DM-worker 節點的高可用、數據遷移任務的自動調度與正確性保證，以及從 1.0 升級到 2.0 后的 DM-master 擴容等。總體來講，DM 2.0 降低了從 MySQL 向 TiDB 進行數據實時同步的風險，保障了同步過程中的數據不丟失與服務高可用。

到此，關于“TiDB DM2.0GA有哪些新特性”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！