前期準備
在進行資料遷移之前，一定要做好遷移前的準備。
-
環境調研，源和目標資料庫環境、版本、資料量大小、業務場景、作業系統版本等
-
方案准備，儘量詳細、遷移失敗導致源資料庫掛了是否有資料備份回退方案
-
人員角色到齊，資料遷移放在晚上，最好是A/B角色一起參與。
-
對業務影響範圍充分了解，對源資料用monitor命令檢視有哪些ip進行了操作(過慮掉ping、info、slowlog的ip)，host轉為域名
-
停機視窗、這段時間要是出現問題怎麼處理
檢查
-
對比源和目標的環境（info、uname -a命令）
-
瞭解業務的影響範圍（monitor、wak、sort等命令，有哪些對源進行了crud）
-
人員備齊（開發、運維）
-
源資料的備份，萬一遷移的時候源掛了
-
資料雙寫，在寫源的時候，寫一份到目標機器，採用先雙寫後面增量或者全量補充歷史資料的方式。
平滑遷移-雙寫法方案
-
主要分為四個步驟。
-
步驟一：服務進行升級，對“對舊庫上的資料修改”（這裡的修改，為資料的insert, delete, update），在新庫上進行相同的修改操作，這就是所謂的“雙寫”，主要修改操作包括：
-
舊庫與新庫的同時insert
-
舊庫與新庫的同時delete
-
舊庫與新庫的同時update
-
-
由於新庫中此時是沒有資料的，所以雙寫舊庫與新庫中的affect rows可能不一樣，不過這完全不影響業務功能，只要不切庫，依然是舊庫提供業務服務。
-
這個服務升級風險較小：
-
寫介面是少數介面，改動點較少
-
新庫的寫操作執行成功與否，對業務功能沒有任何影響
-
-
步驟二：研發一個資料遷移工具，進行資料遷移，把舊庫中的資料轉移到新庫中來。
-
這個小工具的風險較小：
-
整個過程依然是舊庫對線上提供服務
-
小工具的複雜度較低
-
任何時間發現問題，都可以把新庫中的資料幹掉重來
-
可以限速慢慢遷移，技術同學沒有時間壓力
-
-
資料遷移完成之後，就能夠切到新庫提供服務了麼？
-
答案是肯定的，因為前置步驟進行了雙寫，所以理論上資料遷移完之後，新庫與舊庫的資料應該完全一致。
-
-
在一種非常非常非常極限的情況下：
-
date-migrate-tool剛好從舊庫中將某一條資料X取出
-
在X插入到新庫中之前，舊庫與新庫中剛好對X進行了雙delete操作
-
date-migrate-tool再將X插入到新庫中
-
-
這樣，會出現新庫比舊庫多出一條資料X。
-
但無論如何，為了保證資料的一致性，切庫之前，還是需要進行資料校驗的
-
步驟三：在資料遷移完成之後，需要使用資料校驗的小工具，將舊庫和新庫中的資料進行比對，完全一致則符合預期，如果出現步驟二中的極限不一致情況，則以舊庫中的資料為準。
-
這個小工具的風險依舊很小：
-
整個過程依然是舊庫對線上提供服務
-
小工具的複雜度較低
-
任何時間發現問題，大不了從步驟二開始重來
-
可以限速慢慢比對資料，技術同學沒有時間壓力
-
-
步驟四：資料完全一致之後，將流量切到新庫，完成平滑資料遷移。
-
至此，升級完畢，整個過程能夠持續對線上提供服務，不影響服務的可用性。
總結
針對網際網路很多“資料量較大，併發量較大，業務複雜度較高”的業務場景，在
-
底層表結構變更
-
分庫個數變換
-
底層儲存介質變換
的眾多需求下，需要進行資料遷移，完成“平滑遷移資料，遷移過程不停機，保證系統持續服務”的解決方案。
-
雙寫法，四個步驟：
-
服務進行升級，記錄“對舊庫上的資料修改”進行新庫的雙寫
-
研發一個資料遷移小工具，進行資料遷移
-
研發一個資料比對小工具，校驗資料一致性
-
流量切到新庫，完成平滑遷移