TiDB DM2.0GA有哪些新特性

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

社會數(shù)字化、智能化的發(fā)展進(jìn)程中，海量的數(shù)據(jù)帶來巨大挑戰(zhàn)，各行各業(yè)都在加速數(shù)字化轉(zhuǎn)型，越來越多的企業(yè)意識到數(shù)據(jù)基礎(chǔ)設(shè)施是成功的關(guān)鍵。然而，作為數(shù)據(jù)基礎(chǔ)設(shè)施的核心，傳統(tǒng)數(shù)據(jù)庫例如 MySQL 面臨性能和容量瓶頸，通過中間件實(shí)現(xiàn)的分庫分表方案復(fù)雜度高，同時帶來高昂的運(yùn)維成本。

作為一款企業(yè)級 NewSQL 數(shù)據(jù)庫，TiDB 采用計(jì)算、存儲分離的架構(gòu)，可以根據(jù)業(yè)務(wù)需要進(jìn)行彈性的擴(kuò)展，應(yīng)對更加實(shí)時和智能的數(shù)據(jù)應(yīng)用需求。TiDB 提供 Data Migration (DM) 生態(tài)工具，幫助用戶實(shí)現(xiàn)從 MySQL 到 TiDB 數(shù)據(jù)遷移，有效降低遷移成本和風(fēng)險。

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

##DM 2.0 新特性

數(shù)據(jù)遷移任務(wù)的高可用

DM 2.0 提供數(shù)據(jù)遷移任務(wù)的高可用，部分 DM-master、DM-worker 節(jié)點(diǎn)異常后仍能保證數(shù)據(jù)遷移任務(wù)的正常運(yùn)行。

當(dāng)部署多個 DM-master 節(jié)點(diǎn)時，所有 DM-master 節(jié)點(diǎn)將使用內(nèi)部嵌入的 etcd 組成集群。該 DM-master 集群用于存儲集群節(jié)點(diǎn)信息、任務(wù)配置等元數(shù)據(jù)，同時通過 etcd 選舉出 leader 節(jié)點(diǎn)，該 leader 節(jié)點(diǎn)用于提供集群管理、數(shù)據(jù)遷移任務(wù)管理相關(guān)的各類服務(wù)。若可用的 DM-master 節(jié)點(diǎn)數(shù)超過部署節(jié)點(diǎn)的半數(shù)，即可正常提供服務(wù)。

當(dāng)部署的 DM-worker 節(jié)點(diǎn)數(shù)超過上游 MySQL/MariaDB 節(jié)點(diǎn)數(shù)時，超出上游節(jié)點(diǎn)數(shù)的相關(guān) DM-worker 節(jié)點(diǎn)默認(rèn)將處于空閑狀態(tài)。若某個 DM-worker 節(jié)點(diǎn)下線或與 DM-master 發(fā)生網(wǎng)絡(luò)隔離，DM-master 能自動將與原 DM-worker 節(jié)點(diǎn)相關(guān)的數(shù)據(jù)遷移任務(wù)調(diào)度到其他空閑的 DM-worker 節(jié)點(diǎn)上并繼續(xù)運(yùn)行。

###樂觀協(xié)調(diào)模式下的分庫分表合并遷移

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

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

在樂觀協(xié)調(diào)模式下，DM-worker 接收到來自上游的 DDL 后，會把更新后的表結(jié)構(gòu)轉(zhuǎn)送給 DM-master。DM-worker 會追蹤各分表當(dāng)前的表結(jié)構(gòu)，DM-master 合并成可兼容來自每個分表 DML 的合成結(jié)構(gòu)，然后通知相應(yīng)的 DM-worker 把與此對應(yīng)的 DDL 遷移到下游；對于 DML 會直接遷移到下游。

DM 2.0 版本試驗(yàn)性的支持從 MySQL 8.0 遷移數(shù)據(jù)到 TiDB，同時提供 TLS 支持，構(gòu)建立體的數(shù)據(jù)安全體系，保障 DM 組件之間以及 DM 組件與上下游數(shù)據(jù)庫之間的連接與傳輸?shù)陌踩c合規(guī)，幫助企業(yè)實(shí)現(xiàn)數(shù)據(jù)在全生命周期過程中的不丟失、不泄露、不被篡改和隱私合規(guī)。

###易用性全面提升

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

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

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

此外，DM 2.0 加入對全量導(dǎo)出數(shù)據(jù)及增量 binlog 數(shù)據(jù)中對應(yīng)的 sql_mode 的自動處理，確保盡可能地減少手動的配置和干預(yù)。DM 2.0 也對一系列功能進(jìn)行了易用性增強(qiáng)，包括全量導(dǎo)出文件的自動清理、配置參數(shù)優(yōu)化、監(jiān)控面板優(yōu)化、log 展示優(yōu)化等。

##用戶實(shí)踐

###微眾銀行

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

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

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

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

###理想汽車

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

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

基于業(yè)務(wù)對 DM 工具的強(qiáng)依賴，理想汽車通過 TiUP 把原先 DM 1.0 集群升級到 DM 2.0 ，并對 DM 2.0 的高可用特性進(jìn)行了深入測試，包括 DM-master 與 DM-worker 節(jié)點(diǎn)的高可用、數(shù)據(jù)遷移任務(wù)的自動調(diào)度與正確性保證，以及從 1.0 升級到 2.0 后的 DM-master 擴(kuò)容等。總體來講，DM 2.0 降低了從 MySQL 向 TiDB 進(jìn)行數(shù)據(jù)實(shí)時同步的風(fēng)險，保障了同步過程中的數(shù)據(jù)不丟失與服務(wù)高可用。

到此，關(guān)于“TiDB DM2.0GA有哪些新特性”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！