數據遷移的套路

• 2020 年 5 月 4 日
• 筆記

數據遷移的類型

隨著業務的發展，存儲也會經常性的需要遷移。以下場景是我們開發過程中經常遇到的

1. 業務、團隊在快速擴張，需要適當時機進行微服務的拆分，需要獨立的資料庫，將數據從源資料庫遷移到新的資料庫
2. 單表的記錄數比較大，需要進行分庫分表。需要將老表的數據遷移到新的分表中。
3. 存儲選型不對，比如關係型資料庫的相互遷移， PG, MySQL,Oracle的相互遷移。NoSQL的Mongo,Cassandra,Hbase的相互遷移。
4. 機房的遷移，自建機房到雲的相互遷移

這些場景都需要進行數據遷移，雖然細節的方案有不同之處，但是也會有一些共同之處。

數據遷移的方案

數據遷移簡單來說就是將數據從一個地方挪到另外一個地方。

因為我們的數據不是靜態的，所以我們不能隨便寫個job遷移就好了。需要確保一些遷移上的標準

標準

數據一致性
遷移完數據不能丟記錄，單條記錄的數據不能缺欄位。

不停機
數據在不斷的寫入，不能為了阻止寫入，而不允許數據寫入，需要保證業務寫入的可用性。

遷移過程可中斷、可回滾
這點要求很高，是確保數據萬無一失的策略。在遷移數據的各個階段發現有問題，都可以回滾到原來的庫，保證業務正常運行。

遷移方案

為了達到上述要求，一般採用雙寫策略。也就是寫兩份，既往老的寫，也往新的寫。

1. 收斂讀寫
   讀寫的入口越多，後續需要進行開關切換的地方就越多，就越容易出錯，所以要儘可能的先將所有的讀寫入口都收斂到一個地方
2. 雙寫
   將增量的數據同時寫入到兩個存儲系統。確保新的寫入程式碼沒問題。雙寫以寫入老的為準，老的寫入成功代表操作成功了，寫入新的失敗了需要記錄失敗日誌，分析為何失敗，進行修正和補償
3. 將老的存量數據遷移過來
   老的存量數據遷移就是通過遍歷id，寫入新的存儲。具體的方案有很多。可以使用同步工具，比如binlog +flink來處理。數據量比較少的就直接遍歷就行。
4. 數據校驗
   數據的一致性校驗是重中之重，確保兩邊數據的記錄數，單條記錄的數據完整性。如果數據量不多，一般是全量校驗。數據量很多，可以抽樣校驗。
5. 切換新的讀
   數據校驗通過後，就可以切換到新的讀，萬一還有問題，可以切換到老的讀。排查問題，重新來過。
6. 停止雙寫
   在新的存儲中安全平穩的運行了N天后，就可以停掉老的讀了，整個遷移過程完成了。

注意事項

1. 對於後端服務，存儲是基石，是重中之重。穩定性要求是最高的。一定要確保數據是平滑遷移的，對業務無感知。
2. 同時存儲是有狀態的，遷移難度比較大，開發者需要具備前瞻性，盡量在選型的時候慎重，選擇合適的資料庫，避免進行資料庫遷移。發現資料庫選型有潛在的問題時，需要當機立斷，儘早遷移。不要以為出現問題的概率不大，就拖延了。否則一旦出現問題，就是重大故障，造成的損失難以估量。