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

支持豐富的遷移類型

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

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

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

1、遷移維度從表到庫(kù)

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

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

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

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

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

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

3、從單地域到多地域

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

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

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

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

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

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

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

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

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

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

雙向同步有一個(gè)難點(diǎn)就是流量循環(huán)，為了避免這個(gè)問(wèn)題，我們一般用打標(biāo)簽的方法，給一條語(yǔ)記做一個(gè)標(biāo)記，遷移的時(shí)候就能識(shí)別出來(lái)這個(gè)是從哪邊遷移過(guò)來(lái)直接扔掉不遷。

打標(biāo)簽的方案有三種：

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

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

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

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

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

zhangnn