相比傳統(tǒng)的遷移工具，優(yōu)刻得UDTS更加靈活彈性，對于正在遷移的任務(wù)，用戶如果不想遷移了可隨時停止，如果任務(wù)信息填錯等需要修改的時候，用戶也可以隨時進行修改重啟。優(yōu)刻得UDTS還能提供完善的運行信息，例如遷移任務(wù)的起始時間、剩余時間、數(shù)據(jù)量等。在安全可靠性方面，優(yōu)刻得UDTS在公有云平臺上進行數(shù)據(jù)遷移不僅支持外網(wǎng)的遷移，還提供優(yōu)刻得內(nèi)網(wǎng)的數(shù)據(jù)遷移。

支持豐富的遷移類型

如上圖所示，目前優(yōu)刻得UDTS支持主流數(shù)據(jù)庫MySQL、TiDB、PgSQL、SQLServer、MongoDB、Redis的同構(gòu)數(shù)據(jù)源之間的遷移，以及異構(gòu)數(shù)據(jù)源的遷移MySQL->TiDB。還支持一些其他類型的遷移，例如從CSV->UDW（UCloud數(shù)據(jù)倉庫）、CSV->MySQL。

了解到很多UFile用戶有數(shù)據(jù)遷移的需求，因此UDTS新增了UFile之間的數(shù)據(jù)遷移，包括支持全bucket遷移、按prefix遷移、斷點續(xù)傳，同時可以與優(yōu)刻得工作流服務(wù)StepFlow結(jié)合實現(xiàn)增量同步。

優(yōu)刻得UDTS的三次重要升級

1、遷移維度從表到庫

經(jīng)過調(diào)研我們發(fā)現(xiàn)有些用戶的表比較少且集中，有些用戶一個表有上百G的數(shù)據(jù)，如果按庫遷移的話，一個庫里面上TB的數(shù)據(jù)遷移在導(dǎo)出階段一旦出問題就得從頭再來，因此UDTS最初是從表的維度開始遷移，一次只能遷移一個庫里面的一張表。

后來又調(diào)研到有用戶的一個MySQL實例有十幾個庫，每個庫有二十幾張表，如果按表遷移可能要創(chuàng)建幾百個任務(wù)，對于該用戶來說按表遷移的顯然任務(wù)量巨大。于是我們很快開發(fā)支持了按庫進行遷移，將這個用戶庫里面所有表一次全部遷移過去。另外UDTS還支持多庫及全庫的遷移，可以將一個實例下除系統(tǒng)庫（mysql, information_schema, performance_schema, test, sys）以外的所有庫一次性遷移過去。

2、支持ETL數(shù)據(jù)過濾

有些用戶會面臨這樣的需求：在數(shù)據(jù)遷移的時候不希望或者不需要將所有數(shù)據(jù)完整的遷移到目標庫，因此UDTS開發(fā)了按條件（行）選擇及按列選擇功能。

還有一些數(shù)據(jù)整合的場景，用戶原來的數(shù)據(jù)分散在不同的數(shù)據(jù)庫中，現(xiàn)在希望整合到同一個高性能數(shù)據(jù)庫中。但有時會遇到數(shù)據(jù)庫名重復(fù)沖突導(dǎo)致無法整合。于是UDTS提供了遷移時重命名的功能，可以針對數(shù)據(jù)庫也可以針對表，這樣就幫助這類用戶解決了數(shù)據(jù)整合的難題。同時我們還提供了列級的映射，讓用戶有更靈活的遷移服務(wù)。

使用過MySQL的用戶可能經(jīng)常會遇到這種情況，如果業(yè)務(wù)量大，從庫老是追不上主庫。我們遇到有用戶在做完全量遷移后，做增量遷移的時候發(fā)現(xiàn)老是追不上主庫，經(jīng)過分析發(fā)現(xiàn)該用戶有一個批量計算在里面，有一張表有幾千萬條數(shù)據(jù)，每隔一段時間做一次批量計算，將那張表拷貝一份在里面做大量的運算，用完了之后再刪掉，不斷的重復(fù)做這件事情。但由于這些表都是臨時生成的只知道前綴不知道名字，于是UDTS增加了一個數(shù)據(jù)過濾功能，支持按特定的前綴來排除特定的表，這樣運行出來速度就很快，任務(wù)一旦啟動就從來沒有掉過隊，一直是實時保持同步的。

3、從單地域到多地域

優(yōu)刻得UDTS 從最初的北京單地域逐漸擴展了很多其他地域，這里涉及到跨地域甚至跨國遷移的問題。單地域遷移，比如在北京幾個可用區(qū)之間的延時最多可能一兩毫秒，而跨國遷移中有些國家網(wǎng)絡(luò)延時可能達到幾十毫秒，而低延時對于數(shù)據(jù)遷移的服務(wù)來說非常關(guān)鍵。

第一個大問題就是帶寬問題，同一地域內(nèi)無論是內(nèi)網(wǎng)還是外網(wǎng)帶寬可以認為是無限的，但跨國遷移不同，云廠商的網(wǎng)絡(luò)出口流量出于成本或安全的考慮都會做一些限制，因此最開始經(jīng)常遇到一些失敗的情形，遷移過程中網(wǎng)絡(luò)突然斷掉，這是由于流量超過了云廠商機房的網(wǎng)絡(luò)閾值導(dǎo)致IP被限制了，因此我們要保證整個遷移過程中網(wǎng)速不能超過數(shù)據(jù)中心的閾值。

第二個問題是高延遲，例如數(shù)據(jù)庫連接中間丟包產(chǎn)生的現(xiàn)象比較多就必須做一些改進，因此UDTS產(chǎn)品需要更健壯，斷點續(xù)傳的功能一定要非常穩(wěn)健。

第三個問題是我們發(fā)現(xiàn)有很多跨國遷移用戶對數(shù)據(jù)非常敏感不愿意走公網(wǎng)，需要單獨拉一條專線，但是由于專線的廠商有一些?；顧C制在里面，會對數(shù)據(jù)庫連接產(chǎn)生干擾，經(jīng)常遇到網(wǎng)絡(luò)突然中斷的情況。因此專線之間的?；畲胧┤绻_實有問題可以把機制關(guān)掉，另外數(shù)據(jù)庫的錯誤連接數(shù)一定要設(shè)置的很高，不然很容易達到閾值導(dǎo)致連接連不上去。

UDTS在多地域的支持上，除了優(yōu)刻得國內(nèi)的節(jié)點（含臺灣，香港），也陸續(xù)開通了如新加坡、越南、巴西圣保羅等海外節(jié)點，后續(xù)還會逐步擴展UDTS服務(wù)至優(yōu)刻得全地域節(jié)點實現(xiàn)全球化級別的服務(wù)。

優(yōu)刻得UDTS雙向遷移

為什么要做雙向遷移呢？假如一個用戶要確保遷移萬無一失，一旦遷過去一段時間后出錯了，立馬要回切，這里面就涉及到一個問題，一般數(shù)據(jù)遷移都是從源到目的做一個全量，然后增量同步，才會把業(yè)務(wù)切過去。但是這個過程流量只會寫一邊，導(dǎo)致不斷產(chǎn)生的新數(shù)據(jù)并沒有寫到源端。

有些場景很復(fù)雜，不只是一個關(guān)系型數(shù)據(jù)庫，遷移下來有一整套比如緩存、DNS服務(wù)或者其他服務(wù)，萬一整個遷移過來后工作一段時間發(fā)現(xiàn)出問題了，就需要立馬把業(yè)務(wù)切回去，這時從數(shù)據(jù)庫的角度來說基本切不回去了，因為目的端已經(jīng)產(chǎn)生了很多增量數(shù)據(jù)而源端沒有。如果有雙向同步，數(shù)據(jù)寫到目標端就可以實時同步到源端，將業(yè)務(wù)隨時切回來。

還有異地雙活的場景，有些用戶可能一部分業(yè)務(wù)跑在這家云廠商另外一部分業(yè)務(wù)跑在另外一家云廠商上面，或兩邊廠商都要跑一模一樣的環(huán)境，這些都需要數(shù)據(jù)同步，從而達到跨云協(xié)同或者跨云容災(zāi)。一家云商出問題以后，快速將業(yè)務(wù)切換到另外一家云商上，保證業(yè)務(wù)可用。

雙活怎么做？不管哪家云廠商數(shù)據(jù)庫都支持高可用，不用同云廠商做了不同的架構(gòu)改造，每一家都有自己的模式。UCloud的關(guān)系型數(shù)據(jù)庫UDB高可用的結(jié)構(gòu)不能和AWS的高可用結(jié)構(gòu)通過主從做實時同步，一個主庫可以有很多個從庫，但是一個從庫只能有一個主庫。如果有了雙向同步，就可以實現(xiàn)業(yè)務(wù)的雙活部署，無論從哪邊寫都可以實時的同步。

雙向同步有一個難點就是流量循環(huán)，為了避免這個問題，我們一般用打標簽的方法，給一條語記做一個標記，遷移的時候就能識別出來這個是從哪邊遷移過來直接扔掉不遷。

打標簽的方案有三種：

方案一：修改數(shù)據(jù)庫源碼，在binlog中給源加標記；

方案二：要求表有主鍵，將 insert/update 修改為 replace into；

方案三：將每一條語句打包成帶特殊TAG語句的事務(wù)，同步服務(wù)識別出TAG，忽略整條事務(wù)。

這里我們選擇的是方案三，主要是由于方案一需要改動數(shù)據(jù)庫源碼，還需要數(shù)據(jù)庫團隊合作，且這個方案只能支持我們自己的云數(shù)據(jù)庫，不能支持原生MySQL數(shù)據(jù)庫及其它廠商的數(shù)據(jù)庫；方案二限制太多，且有sql語句重復(fù)執(zhí)行的問題。

數(shù)據(jù)遷移作為IT架構(gòu)不同階段中的重要一環(huán)，無論是從本地遷移上云或是異地多活（災(zāi)備）等場景，UDTS都能夠保證數(shù)據(jù)的平滑遷移，解決傳統(tǒng)數(shù)據(jù)遷移的諸多難題。為了進一步提高用戶體驗，UDTS將不斷完善當前已有功能，并支持更多同構(gòu)、異構(gòu)類型的數(shù)據(jù)傳輸服務(wù)。

zhangnn