相比傳統的遷移工具，優(yōu)刻得UDTS更加靈活彈性，對于正在遷移的任務，用戶如果不想遷移了可隨時停止，如果任務信息填錯等需要修改的時候，用戶也可以隨時進行修改重啟。優(yōu)刻得UDTS還能提供完善的運行信息，例如遷移任務的起始時間、剩余時間、數據量等。在安全可靠性方面，優(yōu)刻得UDTS在公有云平臺上進行數據遷移不僅支持外網的遷移，還提供優(yōu)刻得內網的數據遷移。
支持豐富的遷移類型
如上圖所示，目前優(yōu)刻得UDTS支持主流數據庫MySQL、TiDB、PgSQL、SQLServer、MongoDB、Redis的同構數據源之間的遷移，以及異構數據源的遷移MySQL->TiDB。還支持一些其他類型的遷移，例如從CSV->UDW（UCloud數據倉庫）、CSV->MySQL。
了解到很多UFile用戶有數據遷移的需求，因此UDTS新增了UFile之間的數據遷移，包括支持全bucket遷移、按prefix遷移、斷點續(xù)傳，同時可以與優(yōu)刻得工作流服務StepFlow結合實現增量同步。
優(yōu)刻得UDTS的三次重要升級
1、遷移維度從表到庫
經過調研我們發(fā)現有些用戶的表比較少且集中，有些用戶一個表有上百G的數據，如果按庫遷移的話，一個庫里面上TB的數據遷移在導出階段一旦出問題就得從頭再來，因此UDTS最初是從表的維度開始遷移，一次只能遷移一個庫里面的一張表。
后來又調研到有用戶的一個MySQL實例有十幾個庫，每個庫有二十幾張表，如果按表遷移可能要創(chuàng)建幾百個任務，對于該用戶來說按表遷移的顯然任務量巨大。于是我們很快開發(fā)支持了按庫進行遷移，將這個用戶庫里面所有表一次全部遷移過去。另外UDTS還支持多庫及全庫的遷移，可以將一個實例下除系統庫（mysql, information_schema, performance_schema, test, sys）以外的所有庫一次性遷移過去。
2、支持ETL數據過濾
有些用戶會面臨這樣的需求：在數據遷移的時候不希望或者不需要將所有數據完整的遷移到目標庫，因此UDTS開發(fā)了按條件（行）選擇及按列選擇功能。
還有一些數據整合的場景，用戶原來的數據分散在不同的數據庫中，現在希望整合到同一個高性能數據庫中。但有時會遇到數據庫名重復沖突導致無法整合。于是UDTS提供了遷移時重命名的功能，可以針對數據庫也可以針對表，這樣就幫助這類用戶解決了數據整合的難題。同時我們還提供了列級的映射，讓用戶有更靈活的遷移服務。
使用過MySQL的用戶可能經常會遇到這種情況，如果業(yè)務量大，從庫老是追不上主庫。我們遇到有用戶在做完全量遷移后，做增量遷移的時候發(fā)現老是追不上主庫，經過分析發(fā)現該用戶有一個批量計算在里面，有一張表有幾千萬條數據，每隔一段時間做一次批量計算，將那張表拷貝一份在里面做大量的運算，用完了之后再刪掉，不斷的重復做這件事情。但由于這些表都是臨時生成的只知道前綴不知道名字，于是UDTS增加了一個數據過濾功能，支持按特定的前綴來排除特定的表，這樣運行出來速度就很快，任務一旦啟動就從來沒有掉過隊，一直是實時保持同步的。
3、從單地域到多地域
優(yōu)刻得UDTS 從最初的北京單地域逐漸擴展了很多其他地域，這里涉及到跨地域甚至跨國遷移的問題。單地域遷移，比如在北京幾個可用區(qū)之間的延時最多可能一兩毫秒，而跨國遷移中有些國家網絡延時可能達到幾十毫秒，而低延時對于數據遷移的服務來說非常關鍵。
第一個大問題就是帶寬問題，同一地域內無論是內網還是外網帶寬可以認為是無限的，但跨國遷移不同，云廠商的網絡出口流量出于成本或安全的考慮都會做一些限制，因此最開始經常遇到一些失敗的情形，遷移過程中網絡突然斷掉，這是由于流量超過了云廠商機房的網絡閾值導致IP被限制了，因此我們要保證整個遷移過程中網速不能超過數據中心的閾值。
第二個問題是高延遲，例如數據庫連接中間丟包產生的現象比較多就必須做一些改進，因此UDTS產品需要更健壯，斷點續(xù)傳的功能一定要非常穩(wěn)健。
第三個問題是我們發(fā)現有很多跨國遷移用戶對數據非常敏感不愿意走公網，需要單獨拉一條專線，但是由于專線的廠商有一些?；顧C制在里面，會對數據庫連接產生干擾，經常遇到網絡突然中斷的情況。因此專線之間的保活措施如果確實有問題可以把機制關掉，另外數據庫的錯誤連接數一定要設置的很高，不然很容易達到閾值導致連接連不上去。
UDTS在多地域的支持上，除了優(yōu)刻得國內的節(jié)點（含臺灣，香港），也陸續(xù)開通了如新加坡、越南、巴西圣保羅等海外節(jié)點，后續(xù)還會逐步擴展UDTS服務至優(yōu)刻得全地域節(jié)點實現全球化級別的服務。
優(yōu)刻得UDTS雙向遷移
為什么要做雙向遷移呢？假如一個用戶要確保遷移萬無一失，一旦遷過去一段時間后出錯了，立馬要回切，這里面就涉及到一個問題，一般數據遷移都是從源到目的做一個全量，然后增量同步，才會把業(yè)務切過去。但是這個過程流量只會寫一邊，導致不斷產生的新數據并沒有寫到源端。
有些場景很復雜，不只是一個關系型數據庫，遷移下來有一整套比如緩存、DNS服務或者其他服務，萬一整個遷移過來后工作一段時間發(fā)現出問題了，就需要立馬把業(yè)務切回去，這時從數據庫的角度來說基本切不回去了，因為目的端已經產生了很多增量數據而源端沒有。如果有雙向同步，數據寫到目標端就可以實時同步到源端，將業(yè)務隨時切回來。
還有異地雙活的場景，有些用戶可能一部分業(yè)務跑在這家云廠商另外一部分業(yè)務跑在另外一家云廠商上面，或兩邊廠商都要跑一模一樣的環(huán)境，這些都需要數據同步，從而達到跨云協同或者跨云容災。一家云商出問題以后，快速將業(yè)務切換到另外一家云商上，保證業(yè)務可用。
雙活怎么做？不管哪家云廠商數據庫都支持高可用，不用同云廠商做了不同的架構改造，每一家都有自己的模式。UCloud的關系型數據庫UDB高可用的結構不能和AWS的高可用結構通過主從做實時同步，一個主庫可以有很多個從庫，但是一個從庫只能有一個主庫。如果有了雙向同步，就可以實現業(yè)務的雙活部署，無論從哪邊寫都可以實時的同步。
雙向同步有一個難點就是流量循環(huán)，為了避免這個問題，我們一般用打標簽的方法，給一條語記做一個標記，遷移的時候就能識別出來這個是從哪邊遷移過來直接扔掉不遷。
打標簽的方案有三種：
方案一：修改數據庫源碼，在binlog中給源加標記；
方案二：要求表有主鍵，將 insert/update 修改為 replace into；
方案三：將每一條語句打包成帶特殊TAG語句的事務，同步服務識別出TAG，忽略整條事務。
這里我們選擇的是方案三，主要是由于方案一需要改動數據庫源碼，還需要數據庫團隊合作，且這個方案只能支持我們自己的云數據庫，不能支持原生MySQL數據庫及其它廠商的數據庫；方案二限制太多，且有sql語句重復執(zhí)行的問題。
數據遷移作為IT架構不同階段中的重要一環(huán)，無論是從本地遷移上云或是異地多活（災備）等場景，UDTS都能夠保證數據的平滑遷移，解決傳統數據遷移的諸多難題。為了進一步提高用戶體驗，UDTS將不斷完善當前已有功能，并支持更多同構、異構類型的數據傳輸服務。
