相比傳統(tǒng)的遷移工具，優(yōu)刻得UDTS更加靈活彈性，對于正在遷移的任務(wù)，用戶如果不想遷移了可隨時(shí)停止，如果任務(wù)信息填錯(cuò)等需要修改的時(shí)候，用戶也可以隨時(shí)進(jìn)行修改重啟。優(yōu)刻得UDTS還能提供完善的運(yùn)行信息，例如遷移任務(wù)的起始時(shí)間、剩余時(shí)間、數(shù)據(jù)量等。在安全可靠性方面，優(yōu)刻得UDTS在公有云平臺上進(jìn)行數(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遷移、斷點(diǎn)續(xù)傳，同時(shí)可以與優(yōu)刻得工作流服務(wù)StepFlow結(jié)合實(shí)現(xiàn)增量同步。

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

1、遷移維度從表到庫

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

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

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

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

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

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

3、從單地域到多地域

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這里我們選擇的是方案三，主要是由于方案一需要改動(dòng)數(shù)據(jù)庫源碼，還需要數(shù)據(jù)庫團(tuán)隊(duì)合作，且這個(gè)方案只能支持我們自己的云數(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ù)遷移的諸多難題。為了進(jìn)一步提高用戶體驗(yàn)，UDTS將不斷完善當(dāng)前已有功能，并支持更多同構(gòu)、異構(gòu)類型的數(shù)據(jù)傳輸服務(wù)。

zhangnn