很多的大型業務，有著非常繁雜的業務邏輯，隨著上雲遷雲的趨勢，越來越多的數據庫需要在遷移和搬遷的路上。那麼大型系統的數據庫，如何高效穩定的搬遷，就需要研究下細節了。
1、業務評估和技術選型
首先要確定自己的業務有用到多少種產品，以數據庫來說，需要知道自己使用了哪些數據庫，比如MySQL，Redis等多種不同的數據庫。
值得注意的是：
1）不同的雲廠商，同一類別的產品，名字可能不同。
比如mongodb，在AWS叫做documentDB，在Azure叫做cosmosDB。 這當中的技術實現也會有些許差別，但總歸可以看做一類。
2）相同的類別，但是可能特性和社區版有差異。
比如MySQL的開源分支有Oracle版，percona版，mariadb版本。
Redis也有社區集群和codis集群這種區別。
3） 阿里雲企業版的特性
MySQL為例，我們有高度兼容的社區優化版 AliSQL，也有企業版XDB 三節點
Redis 我們也有社區版，和企業版TairDB
這些企業版特性，都是針對社區版功能，做了特性深度改造，同時一般都是由阿里內部長期使用，除了特性上優化，穩定性也是經得起考驗。
2、實施過程
在搞清楚對標的產品後，下一步就是要做具體的遷雲實施
大規模的搬站，往往不僅僅是數據庫的搬站，還包括應用的搬遷。 所以一般都會有一個切換時間，在運維窗口期，統一的把應用和數據庫同步切換到雲平臺。
有些場景特別的複雜，比如多套應用相互有依賴，無法單獨剝離，如果無法一起搬遷。 則要考慮分批搬遷，這樣就會有一個新的要求。
即： 已經切換的應用，需要走阿里雲的數據庫鏈路，同時還要考慮保留一條反向鏈路，作為兜底回滾。 沒有切換的關聯應用數據庫，則需要走本地只讀，或者遠程讀寫訪問。
這樣的雙活場景，能夠有效保障切換和沒切換的應用，都能正常工作。同時提供兜底回滾方案，避免中間過程的問題。 我們的DTS 雙向同步，則能很好的實現這樣的邏輯。
3、 實施細節
數據庫的搬遷，還存在一些細節，需要大家注意。
首先，不能在遷移的過程中，大規模使用大事務、DDL、熱點寫等情況。 這些都會帶來同步鏈路的延遲，如果有雙活業務，那麼需要非常重視，可能導致不一致讀，引發業務問題。
其次，我們的雙向同步中，只有正向鏈路具備同步DDL的能力，反向鏈路只能同步DML。 如果反向鏈路的源，需要做DDL，則會被忽略。 另外，如果使用了ghostptosc等開源無鎖表結構變更的情況，這些工具生產的影子表，因為不會被同步，所以影子表的增量，會導致DTS鏈路報錯。