摘要：8月24日，阿里云數據庫技術峰會到來，本次技術峰會邀請到了阿里集團和阿里云數據庫老司機們，為大家分享了一線數據庫實踐經驗和技術干貨。在本次峰會上，阿里巴巴高級技術專家付大超(千震)針對于云計算時代最好的數據傳輸產品阿里云DTS的架構設計、基本原理以及相關的應用場景進行了精彩分享。幫助大家了解了阿里是如何實現異地多活和異構多活的，以及通過DTS輕松實現遷移、雙同同步、容災、訂閱的真實案例。
以下內容根據演講嘉賓現場視頻以及PPT整理而成。
本次分享的內容主要圍繞以下四個部分：
一、DTS技術架構
二、DTS異地&異構多活架構
三、DTS應用案例
四、最佳實踐
一、DTS技術架構
DTS產生的背景
大家下午好，如下圖中左側所示的是幾年之前的支付寶發布的一條微博信息，這條微博主要表達的是因為當時杭州的溫度很高，導致當時的用電壓力比較大，而為了保證居民的正常用電，甚至連阿里巴巴的機房也因此受到限電。而這樣的限電卻可能會對于阿里的服務、支付寶的服務甚至是阿里云的服務造成影響。在幾年之前，阿里巴巴就在思考將服務搬到另外一個地方去，這樣即使杭州出現了一些像機房全部斷電這樣由于不可控因素產生無法提供服務的情況，阿里也依舊能夠為全球的用戶提供在線服務。所以為了實現上述目標，阿里逐漸開始實現異地多活的場景。
上圖中右側所展示的是中國人民銀行對于數據中心出現的問題的數據統計。可以看出數據中心所出現的問題種類還是比較多的，其中比較典型的就是主機故障、電源故障等。總而言之，就是數據中心會出現各種各樣的異常情況導致服務中斷。在本質上來說，這樣的異常情況是不可以避免的，阿里巴巴在思考該如何解決這些問題的時候就想到了可以通過將數據中心做成異地甚至是全球的架構，這樣就可以盡可能地避免因為異常情況導致的服務不可用。比如在雙11場景之下，當某一個機房掛掉了，業務也并不會受到影響。為了實現這樣的目標，也就產生了DTS這款產品。
DTS簡介
后來發現阿里云也存在著與阿里巴巴同樣的需求，因為很多用戶需要將自己的數據遷移到阿里云上來去構建自己的數據架構，這時候也會遇到同樣的問題。于是DTS這款產品逐漸地從內部開放到外部，開始對外提供服務。所以在今天，阿里云的外部客戶能夠享受到與阿里內部一樣的基礎設施和服務。
目前，DTS產品有這樣的幾個功能，典型的就是用戶上云時需要進行數據遷移，幫助用戶將本地機房的數據遷移到阿里云的其他數據庫或者用戶在ECS上自建的數據庫上去。總而言之，DTS產品的目標就是打通整個數據鏈路。之前的數據在每個產品中，這樣相當于是數據孤島，而通過DTS產品能夠消除數據孤島，將數據鏈路完全打通，驅動數據自由地流動。除此之外，DTS的功能還有實現長期的數據同步，這一點與數據遷移不同，在長期的數據同步過程中必定會對于可用性、性能以及安全性提出更高的要求，而DTS能夠提供長期的數據同步能力。DTS的第三個功能就是實現數據訂閱，一些用戶在阿里云上擁有很多的數據庫，而用戶想要將RDS的增量數據訂閱回去，更加靈活地構建自己的數據架構。DTS還提供了一點功能就是文件遷移，可以將像SQL以及CSV等以文件的形式導過來。
通過上述的功能，DTS就能夠在應用場景下提供更強大的服務能力。阿里云上的數據庫都能夠支持DTS，而用戶在ECS上自建的數據庫以及用戶在本地IDC上自建的數據庫，包括MySQL、Oracle、SQL Server、PG、MongoDB以及Redis都是能夠支持DTS的，而且相對比較特別的是DTS還能夠支持增量的能力。而就目前而言，能夠支持Oracle、SQL Server、Redis的增量能力的云產品只有DTS能夠做到。
DTS發展歷史
DTS的發展經歷了很多個階段，其發展成熟的過程也經歷了一定的演變。在今天，DTS能夠支持雙11這樣的場景，其背后是一步一個腳印走下來的，所以每年也都會逐步地實現新的特性。在2012年的時候，DTS就實現了異地冷備；在2013年，實現了同城雙活；在2014年實現了異地多活；在2015年的時候，支付寶和天貓國際都開始了全球化的步伐，而這些交易數據是需要進行全球同步的，因為中美之間的鏈路足夠長，所以DTS也實現了中美同步，解決了在上萬公里的天然網絡延遲的情況下的延時問題以及網絡傳輸的優化問題；最后，在2016年DTS實現了異構雙活，也就是實現了兩個異構的數據庫比如從Oracle到MySQL或從MySQL到OceanBase這樣異構場景的雙向多活。
DTS架構設計
上圖所展現的是用戶維度的DTS產品的架構設計。在最外層所提供了用戶可以直接進行操作的控制臺，同時也提供了OpenAPI。阿里云在上周上線了OpenAPI的完整文檔來幫助用戶更好地使用這款產品。用戶通過控制臺以及OpenAPI這兩種途徑都可以建立DTS的任務，這樣的任務會發到反向代理集群，再到前端集群，最后再下發到核心的工作集群上去。在DTS底層會存在一個任務調度系統，DTS本身是全球服務的，所以可以將命令下發到全球。DTS將能夠提供幾個功能，比如數據遷移系統就需要解決數據一致性的問題，無論是無主鍵表還是InnoDB引擎，DTS都能支持用戶將數據輕松地遷移到RDS或者自建的ECS甚至是大數據系統上去。除此之外，DTS還提供了數據同步以及數據訂閱的功能。而且還提供了上云評估功能，這個功能能夠幫助用戶更加輕松地評估自己的系統，因為阿里云的用戶中有一些用戶對于自己的系統并不了解，而且可能并沒有專業的DBA，所以這些系統需要一款產品能夠為用戶提供一些對于系統所存在的問題的建議，比如將數據從Oracle遷移到MySQL可能出現哪些內容不兼容，可能有哪些無主鍵表，可能有哪些大字段，以及性能如何等。DTS能夠為用戶的系統提供一個基本的測試報告，讓用戶可以看到改造成本是什么樣的。除了核心功能之外，DTS還會提供一些輔助系統，比如監控系統、運維系統、以及運輸系統等。
架構優勢：高性能
接下來分享DTS的架構優勢，來幫助大家更加清晰地了解應該在什么樣的場景上去應用DTS，并且更好地利用DTS的特性來快速實現業務的快速發展。首先，DTS的第一個架構優勢就是高性能，如果用戶想要快速地實現異地災備或者上云，DTS可以幫助用戶使得同步性能達到3萬多TPS，當然這個數據是在實驗場景之下的。阿里云經常會在用戶所提交的工單中發現用戶的源庫和目的庫之間的差別很大，這樣的情況下往往達不到上述的性能。
但是DTS會盡可能地提供比測試數據更高的性能，當用戶在實際使用的時候就能夠感知到即使庫寫的很大，DTS也能夠支持。這是因為DTS內部有一整套通用的解決方案，比如事務沖突檢測能夠實現并發的事務寫入。舉個例子，事務1寫了表A和表B兩張表，另外一個事務2寫了表C，還有一個事務3寫了表A和表D這兩張表，這樣的話，事務1和事務3是沖突的，因為他們都寫了A這張表，而事務2與他們都不相關，所以事務2是可以和他們并行執行的，而事務1和事務3只能是串行執行的。這個例子非常簡單，而在實際情況下卻并非如此，因為每個表都有主鍵、唯一索引以及外鍵，上述例子只是為了幫助大家進行理解。補充一點：MySQL的事務處理比較簡單，但是Oracle數據庫的事務則不同，其事務是穿插的，所以在Oracle中實現事務沖突檢測就會非常復雜。大家如果做過Oracle的日志解析就會發現其中存在非常大的困難，而目前無論是對于MySQL、Oracle、SQL Server、Redis還是MongoDB，DTS都能夠提供支持。
架構優勢：高可靠
DTS的第二個架構優勢就是高可靠。云計算本身所具有的特性之一就是可以彈性伸縮，當需要資源的時候就去購買，當不需要的時候就釋放掉。而DTS的架構設計上也引入了彈性的思想，在為全球提供服務的時候，任何一個服務節點發生故障時，故障節點的任務自動切換到健康的節點繼續完成之前的工作，而應用卻是無感知的。
這時候就會涉及到一些問題，比如斷點是如何解決的，另外如果表在全量遷移的過程中掛掉了，是否能連接起來之后從掛掉的地方繼續運行，這樣盡可能節約時間和計算成本，除此之外還會涉及到無主鍵表所造成的困難，而這些困難和問題都已經被DTS所解決了。總而言之，DTS能夠為用戶在使用過程中屏蔽掉這些問題。
基于結構化存儲隊列的查詢和分發技術
那么為什么DTS在架構上具有一定的領先性呢？一部分原因是DTS所有的增量解析能力都是基于日志實現的，而不是基于查詢源庫的Select表實現的。阿里云所有的數據庫產品的增量能力都是基于日志實現的，這樣能夠帶來一些好處，首先對于源庫基本上是沒有影響的，而且使得性能足夠好，可以實現實時地解析，基本上可以做到秒級，而且大部分的數據同步都在幾百毫秒。在做日志解析過程中就需要結構化數據隊列這個組件，它所能夠實現的功能就是無論使用的是哪一種數據庫，都可以將其日志解析過來并且放入到結構化數據隊列里面，將其解析成DTS所需要的格式。接下來就可以通過這個結構化數據隊列為下游提供服務，比如用戶訂閱數據、進行數據同步以及未來將會開放的SQL接口的實時查詢等。SQL接口的實時查詢指的是比如用戶想要知道數據庫在過往的歷史中究竟發生了什么樣的變更，這時就可以根據表格的ID查詢該表所有的歷史變更記錄，目前而言這個功能還沒有開放出來，后續將會考慮開放。因為這樣的架構，所以所有的數據庫接入進來都會有天然的實時性。阿里云的DTS是在2015年4月份上線的，而亞馬遜AWS在2015年9月份上線了一個類似的產品，但是今天可以不謙虛地說阿里云DTS是目前同類產品中做的最好的。
二、DTS異地&異構多活架構
DTS異地多活
接下來根據下面這張圖分享DTS的異地多活是如何實現的。其實在實現阿里巴巴的異地多活的時候就已經將這套東西整合總結出來了，所以也希望將這套比較復雜的能力賦予公有云的用戶，比如阿里云DTS輸出了一個雙向輸出的功能，也就是異地多活的能力，使得用戶可以親身地構建這套東西。在下圖所示的場景里面，用戶擁有一個A城主庫還有一個B城主庫，并且希望實現異地雙活。
用戶希望既寫A城主庫又寫B城主庫，通過DTS就是先建立一個從A到B的正向任務，也就是中間通過一個結構化隊列以及DWriter模塊實現與所有的數據庫之間的事務一致性的寫入。這里特別強調在場景上必須實現事務一致性，這是因為像是在天貓或者淘寶下單的時候，訂單往往會涉及到幾百條SQL以及幾個庫，而且一個事務可能會涉及到幾個表的若干個字段，而其本質上是一個事務，而如果將事務拆開并且同步到B城主庫上面去的時候就會發現有些數據當讀取過來之后就是不一致的，比如對于一筆訂單而言，可能在A城主庫中讀取的數據發現已經支付，但是在B城中讀取出來的數據發現這筆訂單還沒有支付，這就會產生數據不一致的問題。所以希望在這樣的場景下也能夠保持事務的一致性，這一點也是非常重要的，否則的話在一些非常嚴格的場景下會產生非常多的問題，比如像銀行的流水業務場景。所以DTS所需要解決的問題中，一個是日志的解析，另外一個就是通用的事務解決方案，這樣一來正向的方案就建立完成了，同樣的反向方案也能夠建立。但是在建立反向方案的時候需要解決防循環的問題，也就是不能出現讓從A城主庫寫的數據到了B城主庫然后又回到A城主庫這樣的循環。而防止循環的方案在DTS的異地多活場景中也已經實現了。
DTS異構多活
其實在這個場景之下還有一個比較大的問題就是兩邊數據庫都可以寫入，如何去判斷數據是否一致，當數據出現不一致時如何判斷出來，以及在判斷出來之后又應該如何去進行修復。而且如果沒有這樣的修復能力，一旦數據出現了問題，損失將是無法挽回的。在今天，阿里巴巴的淘寶、天貓以及支付寶的交易都是搭建在這樣的平臺之上的，如果出現數據不一致的情況，將會造成極大的影響和損失。正是因為數據一致的問題非常重要，所以一定要有數據的一致性校驗的能力，而在DTS的異地多活解決方案中恰恰擁有這樣的能力，能夠輕松地校驗兩端的數據庫是否是一致的，并且可以非常輕松地訂正表，當出現問題時也可以及時地進行修復。
在下圖所示的場景中，展現的是從Oracle數據庫遷移到OceanBase或者MySQL數據庫。阿里云的很多政府部門或者銀行的客戶使用的數據庫還是Oracle或者DB2，而這些用戶往往也希望借鑒阿里巴巴的架構來實現自己的全球化分布來避免單點問題。而在這樣的場景之下如何去支持異構數據呢？今天，阿里云在線上已經能夠為用戶提供這樣的能力，而且在銀行業也有實際落地的案例，DTS能夠將Oracle數據庫中的日志解析出來寫給OceanBase，而且在這里面還可以支持DDL功能，比如從Oracle到MySQL可以支持DDL。而如果大家對于Oracle和MySQL比較了解的話就會明白他們兩者之間的DDL的差別是非常大的。當然這里并不是說阿里云DTS的異構多活解決方案能夠支持所有的DDL，但是對于大多數的DDL而言都是能夠支持的。
在上圖所示的場景里面存在著一個非常大的問題，就是用戶其實從Oracle到OceanBase之間存在著一個緩慢的過程，所以從Oracle逐漸切入到OceanBase或者MySQL上需要一個灰度的能力。在這個場景中，首先假設有三個用戶向A城Oracle中寫數據，這時候想要切一個用戶到B城上去，這時候就需要DTS提供一個能力來告訴用戶這個鏈路的延時是什么樣的，如果延時很小就可以將用戶從A城切換到B城，這樣就可以逐漸地將所有的用戶從A城切換到B城上面去。但是當切換過去之后用戶可能還是不放心，因為對于像銀行業這樣的行業而言，如果沒有后備的措施，一旦云端發生問題可能就會出現無法遷回到Oracle上去的風險。所以為了讓用戶放心，DTS同樣也提供了遷回到Oracle的能力。而這個功能的實現也存在著比較大的挑戰，因為從MySQL或者OceanBase上遷移回Oracle的過程中，數據庫也存在著很大的差異性，這樣的差異性就需要DTS異構多活產品來抹平，這款產品同樣也會提供全量和增量的校驗能力，能夠實時地發現數據的不一致情況。當將所有的用戶全部切換到B城之后就實現了將用戶主要業務遷移到阿里云自主可用的RDS、OceanBase以及PolarDB上去。
案例：阿里異構多活
之前分享了阿里異地多活的技術實現，實際上，除了技術實現以外，還需要從業務層面進行分析。這里使用淘寶中賣家商品維度的場景為例子進行說明，比如從中心到單元是按照用戶的ID，也就是買家的維度去取模分割，這樣每個單元都會得到一部分的流量，同時中心也會得到一部分的流量。所以如果單元的數量越多，理論上對于雙11的支持能力也就越強。在2015年的雙11當天單是賣家商品數據庫全天同步的數據量就在PB級別了，而且這套方案不是單實例的，而是整套集群的，高峰時候的增量流量在Gbps級別。當運行的數據架構足夠大的時候就會發現往往需要去接數據庫的下游，包括實時的計算、分析、搜索以及備份等。而阿里的這套機制也是比較完善的，大家在雙11的時候看到的能夠實時地捕獲訂單以及交易額的數據媒體大屏幕上的數據都是來源于DTS的，媒體大屏上的數據是絕對真實的，是直接從生產中獲取的，而且能夠做到秒級別的刷新，所以訂單、消費額以及物流情況基本上都能夠實時地轉移給媒體顯示。
在這個平臺里面，DTS提供了異地多活能力，首先解決了阿里巴巴的單點的問題，除此之外還解決了多下游消費的問題。現在很多公司在進行實時計算的時候是以全量的方式去拉取的源庫，比如將全量數據每天定時拉取到Hadoop集群或者ODPS中去并進行實時計算，但是隨著業務的逐漸發展，會發現用戶所需要拉取的庫越來越大，同時給系統造成的壓力也越來越大，而且數據拉取的下游也會變多，比如搜索、實時計算等，他們需要DTS這樣的產品。只要為他提供一個將日志解析成增量的能力，然后賦予數據庫的下游共同消費這些增量的能力，就可以實現只拉取一次，讓大家能夠多次消費，而且這個過程還不是通過SQL去查詢源庫，所以對于源庫基本沒有影響，而與此同時對于下游而言，收益則是非常大的。
案例：阿里云全球化
除了DTS在阿里的應用場景之外，還有阿里云上的應用場景。在今天很多云計算的用戶選擇了阿里云的產品，而阿里云能夠提供比如像華東、杭州以及新加坡等很多的Region，阿里云目前有十幾個Region分布于全球，并且還在快速地擴展之中。阿里云天生就是全球化的架構，而阿里云的志向就是做全球化的云計算服務，可以說是志向高遠，所以在進行架構設計的時候就需要去考慮使阿里云的云產品能夠實現全球化的架構。
因為DTS是提供給阿里云自己的產品來實現全球化服務的，而像RDS、ECS上面的數據是需要和中心進行交互的，比如用戶購買一個RDS，那么這個RDS實例是如何生產出來的，實例與中心之間如何實現信息的交互的，其中的控制節點又是如何控制流動的，這一套東西其實都是基于DTS所提供的全球化和單元化架構實現的。其實，阿里云和阿里的實現方式還不完全相同，阿里云所實現的是雙中心的架構，而阿里目前實現的是單中心的架構，但是單中心有backup，所以無論是這兩種方式中的哪一種都是可以支撐交易以及下單業務的，所以DTS架構上的復雜性會更高一些。
DTS可以支持關系型數據庫，也支持大數據，還支持NoSQL以及一些應用領域。所以在場景上來看，DTS支持的范圍是非常廣泛的。
三、DTS應用案例
接下來分享一些場景下的DTS應用案例，幫助大家了解在什么樣的場景下使用DTS，以及應該如何使用DTS。
案例1：某國內大型商場使用DTS從Oracle不停機遷移到RDS
下圖中所展示的是一個真實的案例，某國內大型商場原本是Oracle的用戶，但是他希望將自己的數據遷移到云上來。進行遷移可以選擇去購買Oracle的服務，但是這個服務是比較昂貴的，而且也會比較復雜，所以用戶希望通過DTS來完成。其實對于DTS而言，在頁面上創建這樣的一個任務是比較簡單的，用戶只需要點擊幾下鼠標就可以實現，也不需要專業顧問去提供實現方案的建議。因為不需要付昂貴的軟件采購費用和顧問咨詢費用，所以使用DTS進行數據遷移的成本是比較低的，可能僅需要幾元錢就能夠完成從Oracle不停機地遷移到RDS的工作。
如上圖所示，首先會把Oracle的庫表列遷入到RDS上去，然后再將全量數據以及增量數據遷移過去。這個過程需要確保的就是如何保證將全量遷移過程中引入的增量寫入到目的庫中去，還有Oracle的無主鍵問題應該如何解決，而這些問題都是比較困難的，單純依靠用戶自己去解決則是比較麻煩的，但是使用DTS就能夠方便地解決上述問題。阿里云為用戶提供了這樣的簡單功能，而用戶卻給阿里云提出了更多的場景，比如還是這個大型商場用戶，他們還提出了從Oracle到Oracle的雙向遷移能力以及從Oracle到RDS的雙向能力，阿里云也為用戶提供了這樣的能力，不僅僅實現了架構的靈活轉換，還為用戶節約了大量的成本。
案例2：某游戲公司通過DTS同步到海外實現就近訪問
當今中國的游戲行業蓬勃發展，很多游戲公司開始布局海外市場，并且發展情況良好。很多使用了阿里云的游戲公司也提出了這樣的新需求：希望將把游戲數據在中美之間進行同步，把下發的游戲參數信息、購買信息等從中國傳給美國或者從美國傳回中國。阿里云可以通過DTS的中美同步功能幫助用戶實現萬公里毫秒級延遲的數據同步能力。很多國內發展比較好的創業公司都使用了DTS的中美同步服務，不僅僅是游戲公司，還包括一些無人機之類的公司也都使用了這樣的功能。
案例3：某大型央企通過DTS進行在離線實時同步分析目標用戶
目前一些央企、國企也開始走上了上云之路，只不過對于央企或國企而言，上云的道路可能需要分步驟地完成，比如通過DTS逐步地實現大數據分析，對于央企或國企而言，可能原來在本地并沒有搭建自己的大數據平臺，而現在希望借助阿里云上比較方便的像MaxCompute等來實現大數據能力，而DTS就能夠幫助他們實現這樣的目標。因為搭建這樣的一個大數據集群本身的成本是非常高的，而使用阿里云卻是非常方便的，并且成本也會比較低，只需要按需付費就可以了。通過DTS增量能力可以直接寫給MaxCompute或者通過Spark的流式接入寫給其下游的計算服務，這樣也可以解決知識計算以及流式計算的需求。
案例4：某大型互聯網公司通過DTS構建公有云異地多活架構
大型互聯網公司可以通過DTS構建如上圖所示的公有云異地多活架構，這個案例的基本內容在前面已經分享了，這里不再贅述。
案例5：某視頻類科技公司訂閱DTS做緩存更新
有一些用戶在實現自己的互聯網架構過程中不可避免地需要使用到緩存，無論是Memcache還是Redis，這些緩存所起到的作用就是幫忙擋一層訪問。如果沒有緩存層，就難以應對像雙11這樣的場景。而緩存層也都存在著失效的問題，通過使用DTS的數據訂閱功能，實時獲取數據庫更新數據，就能夠更新緩存內容，解決緩存失效的問題，而用戶使用和搭建這套架構所需要的成本也比較低。
案例6：某商業銀行通過DTS構建私有云的兩地三中心容災架構
重點分享一下這個案例。應中國人民銀行的要求，所有的銀行都需要提供“兩地三中心”的容災能力，“兩地三中心”也成為了銀行的標配。而在這之前，很多的銀行曾出現過因為數據庫版本升級、數據庫運維以及其他原因造成服務不可用的問題，但是對于很多銀行而言，是不敢輕易切換目的庫的，因為這可能對于銀行的業務造成很大的影響。銀行不敢切換到目的庫的本質原因就是他們無法保證目的庫能夠正常使用。而通過DTS這款產品能夠確保目的庫通過異地的兩地三中心搭建出來一個備庫，使其能夠實時使用的并且有效。因為通過文件這種方式無法驗證副本集是否是有效的，而DTS卻是通過備庫與第三方庫進行有效性驗證。
上圖中的兩地是深圳和杭州，杭州有兩個機房IDC A和B，深圳有IDC C，這樣的情況下需要搭建兩地——深圳和杭州，三中心——IDC A、B、C三個機房這樣的異地多活的架構。使用下圖的這種方案是比較輕松的，因為在同城內部是通過阿里云RDS實現運載的，對于異地的情況可以通過使用DTS實現深圳機房的數據運載，而且RTO或者RPO基本在1秒左右。除此之外，將服務切到杭州去之后還可以通過DTS切回到杭州。而成本也會降低一些，這是因為首先對于同城部分，阿里云RDS已經幫助用戶實現了；對于異地的數據庫而言，從節省成本的角度，可以自己搭建，當然也可以通過RDS來實現。最重要的一點就是目的端的數據庫是實時的、有效的，并且能夠提供可靠的在線服務。
在上述案例中，如果IDC A出現了故障，這時候RDS會去做主備切換，但是服務卻不會受影響。如果現在用戶100%的流量都寫入到杭州，應用端會自動切換到IDC B上來，保證整個服務是可用的。
如果上述案例中的IDC A和B都掛掉了，也就說整個杭州的機房全部掛掉了，在這樣的情況下該如何保證服務的可用性？實際上這時候需要通過查看DTS的界面來看其延時是多少，如果延時很小就可以做一些標準的切換流程，把應用的流量切換到深圳去。這個時候即便是整個杭州的機房全部掛掉了，也能夠保證服務的正常運行。剛才提到的RPO是1秒，如果可以做到更好，就可以實現杭州節點中的數據在機房恢復之后還能找回來，只是可能某一秒的數據沒有寫過來，但是當杭州的節點恢復了，數據還是可以同步到深圳節點去的。
四、最佳實踐
上面分享了DTS的一些使用場景，最后為介紹DTS在使用過程中用戶反映比較多的典型問題以及最佳實踐。
1.DTS連接不上源庫報錯，這種報錯產生的場景和原因有很多，比如數據庫是否開放了可以遠程連接的權限，因為一些數據庫會限制只允許某些IP進行訪問；用戶填寫的用戶名和密碼是否是正確的；以及數據庫有沒有連接到公網。所以在這樣的場景上，用戶發現DTS連接不上源庫就需要自己在另外一臺ECS上登錄自己的源庫，查看是否能夠連接上，如果能夠連接上，說明目前的網路連接是正常的。而在阿里云所接收的工單中發現很多情況下用戶的源庫限制了IP訪問，因為如果用戶使用的是自建的數據庫而不是RDS版本的數據庫，就會自動地限制只允許某些IP進行訪問，這也是出于安全性的考慮。所以建議用戶在出現這樣問題的時候在另外一臺ECS上直接訪問源庫并查看訪問情況。
2.使用DTS遷移上云的過程中，如何將應用切換到RDS上去？其實這樣的過程具有非常嚴格的規范，比如應該怎么去切換數據庫。這個過程在這里進行簡單說明，首先如果發現DTS的延時很小了，就應該將源庫置成Read Only的。除此之外，還需要在源庫上將應用的Session全部清除掉，因為如果不清除掉，應用還是可以進行寫操作。將Session全部清除掉之后就能夠確保應用不會再執行寫操作，這個時候再將應用切換到目的端。而有時候因為應用機器規模很大，所以導致切不干凈，使得有的應用還在向源端的庫進行寫入，這樣就會導致數據不一致，也就是出現了“雙寫”的情況，這也是一個值得吸取的經驗教訓。
3.源庫和目的庫庫名、表名、列名不同，比如源庫本地是A庫改變成目的庫是B庫，源庫中表名是A表到了目的庫的表名稱變成了B表。在這種場景上，DTS提供了庫、表、列的映射，使得用戶可以很方便地去進行映射。
4.源庫和目的庫都有觸發器，很多用戶的源庫上有觸發器，而且想要將源庫的數據遷移到目的庫上去，所以往往會在目的庫上再建同樣的觸發器。然而，其實目的庫的觸發器是不用建的，因為源庫上的觸發器所產生的數據會產生Binlog，而通過DTS進行遷移，源庫表中有觸發器就不需要再向目的端庫新建觸發器了，因為DTS已經幫助用戶將觸發器上產生的數據同步到目的端了。不然如果用戶在目的端庫上也建立觸發器就會報錯，因為源庫上觸發器已經產生了同一條記錄，這樣就會出現主鍵沖突，進而導致報錯。
5.跨賬號遷移的問題，也就是在跨賬號進行遷移的時候，用戶不知道應該如何遷移。DTS在頁面上提供了跨賬號遷移的功能，用戶可以填寫另外一個賬號的用戶名和密碼，實現跨賬號的遷移。而阿里云DTS還提供了專業的文檔幫助用戶實現這樣的功能。
6.遷移同步過程中進行了Rename表操作，很多用戶在源庫上需要做在線的DDL，而做在線DDL的時候，很多工具會產生Rename表，而Rename的表也在遷移的對象里面。比如需要遷移A、B、C三個表，用戶將A表Rename成D表，再將D表Rename成C表，這樣的過程中D表并不在同步對像里面，所以并不會將其同步到目的端去，因為已經選擇了A、B、C表，后來D表才出現，所以D表必然不在同步對象中。而在目的端執行從D Rename成C的時候發現沒有D這張表了，所以如果需要做Rename操作，建議用戶直接選擇將整個庫進行遷移。整個遷移就能夠將源庫上所有的表全部同步過去，這樣就不會出現Rename而導致的目的端某個表不存在的問題了。總結而言，這是因為使用開源的工具做了在線DDL導致Rename操作進而導致的比較常見的錯誤，而這個錯誤也是值得重視的。
7.主子賬號遷移、同步，當公司發展壯大了，就會涉及到很多主子賬號的問題。為了解決這個問題就需要用戶在使用主子賬號做遷移或者同步的時候通過主賬號給子賬號授權，通過授權確定什么賬號可以使用哪一個RDS。
8.遷移和同步過程中有DDL，MySQL到MySQL這種場景是支持DDL的，很多用戶會出現在源庫上建立了DDL并且還跑到目的庫上建了一個DDL的情況，也就是兩個庫上都建了一個DDL，而這樣肯定會出現問題。所以對于MySQL這種場景不需要兩邊都做DDL，在源庫做一個表結構，DTS可以幫助用戶同步到目的端去。
9.公共云和金融云之間遷移、同步，在公共云和金融云之間是存在隔離的，因為金融云的隔離級別相對而言比較高。數據可以從公共云到金融云，但是反過來從金融云到公共云卻是不可以的。
10.目標庫多了一個表increment_trx，這個表實際上是DTS在同步過程中或者增量遷移過程中建的元數據表，這張表為的是解決斷點續傳問題的，如果還處于數據遷移過程中就不要刪除這個表，如果沒有DTS任務在運行的時候，就可以刪除這個表。
11.用戶想要實現A->B->C遷移，以及實現級聯同步，之前對于這樣的級聯遷移或者同步的需求是會進行攔截的，但是現在DTS也開始支持這樣的操作了，可以實現級聯的遷移和同步。
12.用戶在使用數據訂閱啟動SDK報如下的錯誤:keep alive error，這表示的意思就是訂閱程序連接不上DTS的服務，比如在沒有連接公網的時候就會出現這樣的錯誤，所以需要讓用戶自己的服務能夠連接外面的公網。阿里云所提供的服務是在公網上的，未來阿里云也會對訂閱功能提供私網服務。
