redis數據遷移

前期準備

在進行數據遷移以前，必定要作好遷移前的準備。

• 環境調研，源和目標數據庫環境、版本、數據量大小、業務場景、操做系統版本等

• 方案准備，儘可能詳細、遷移失敗致使源數據庫掛了是否有數據備份回退方案

• 人員角色到齊，數據遷移放在晚上，最好是A/B角色一塊兒參與。

• 對業務影響範圍充分了解，對源數據用monitor命令查看有哪些ip進行了操做(過慮掉ping、info、slowlog的ip)，host轉爲域名

• 停機窗口、這段時間要是出現問題怎麼處理

檢查

• 對比源和目標的環境（info、uname -a命令）

• 瞭解業務的影響範圍（monitor、wak、sort等命令，有哪些對源進行了crud）

• 人員備齊（開發、運維）

• 源數據的備份，萬一遷移的時候源掛了

• 數據雙寫，在寫源的時候，寫一份到目標機器，採用先雙寫後面增量或者全量補充歷史數據的方式。

平滑遷移-雙寫法方案

• 主要分爲四個步驟。

• 步驟一：服務進行升級，對「對舊庫上的數據修改」（這裏的修改，爲數據的insert, delete, update），在新庫上進行相同的修改操做，這就是所謂的「雙寫」，主要修改操做包括：

  1. 舊庫與新庫的同時insert

  2. 舊庫與新庫的同時delete

  3. 舊庫與新庫的同時update

• 因爲新庫中此時是沒有數據的，因此雙寫舊庫與新庫中的affect rows可能不同，不過這徹底不影響業務功能，只要不切庫，依然是舊庫提供業務服務。

• 這個服務升級風險較小：

  1. 寫接口是少數接口，改動點較少

  2. 新庫的寫操做執行成功與否，對業務功能沒有任何影響

---

• 步驟二：研發一個數據遷移工具，進行數據遷移，把舊庫中的數據轉移到新庫中來。

• 這個小工具的風險較小：

  1. 整個過程依然是舊庫對線上提供服務

  2. 小工具的複雜度較低

  3. 任什麼時候間發現問題，均可以把新庫中的數據幹掉重來

  4. 能夠限速慢慢遷移，技術同窗沒有時間壓力

• 數據遷移完成以後，就可以切到新庫提供服務了麼？

  • 答案是確定的，由於前置步驟進行了雙寫，因此理論上數據遷移完以後，新庫與舊庫的數據應該徹底一致。

• 在一種很是很是很是極限的狀況下：

  1. date-migrate-tool恰好從舊庫中將某一條數據X取出

  2. 在X插入到新庫中以前，舊庫與新庫中恰好對X進行了雙delete操做

  3. date-migrate-tool再將X插入到新庫中

• 這樣，會出現新庫比舊庫多出一條數據X。

• 但不管如何，爲了保證數據的一致性，切庫以前，仍是須要進行數據校驗的

---

• 步驟三：在數據遷移完成以後，須要使用數據校驗的小工具，將舊庫和新庫中的數據進行比對，徹底一致則符合預期，若是出現步驟二中的極限不一致狀況，則以舊庫中的數據爲準。

• 這個小工具的風險依舊很小：

  1. 整個過程依然是舊庫對線上提供服務

  2. 小工具的複雜度較低

  3. 任什麼時候間發現問題，大不了從步驟二開始重來

  4. 能夠限速慢慢比對數據，技術同窗沒有時間壓力

---

• 步驟四：數據徹底一致以後，將流量切到新庫，完成平滑數據遷移。

• 至此，升級完畢，整個過程可以持續對線上提供服務，不影響服務的可用性。

---

總結

針對互聯網不少「數據量較大，併發量較大，業務複雜度較高」的業務場景，在

1. 底層表結構變動

2. 分庫個數變換

3. 底層存儲介質變換

的衆多需求下，須要進行數據遷移，完成「平滑遷移數據，遷移過程不停機，保證系統持續服務」的解決方案。

• 雙寫法，四個步驟：

1. 服務進行升級，記錄「對舊庫上的數據修改」進行新庫的雙寫

2. 研發一個數據遷移小工具，進行數據遷移

3. 研發一個數據比對小工具，校驗數據一致性

4. 流量切到新庫，完成平滑遷移