[TOC] > [參考](https://www.w3cschool.cn/architectroad/architectroad-data-smooth-migration.html) ## 問題的提出  面臨的變更 1. 底層表結構變更  數據量非常大的情況下，數據表增加了一些屬性，刪除了一些屬性，修改了一些屬性 2. 分庫個數變換  由于數據量的持續增加，底層分庫個數非成倍增加。 3. 底層存儲介質變換  底層存儲引擎由一個數據庫換為另一個數據庫 ## 方案 ## 停機方案 1. 步驟一：掛一個類似“為了給廣大用戶提供更好的服務，服務器會在凌晨0:00-0:400進行停機維護”的公告，并在對應時段進行停機，這個時段系統沒有流量進入。 2. 步驟二：停機后，研發一個離線的數據遷移工具，進行數據遷移。針對第一節的三類需求，會分別開發不同的數據遷移工具。 1. 底層表結構變更需求：開發舊表導新表的工具 2. 分庫個數變換需求：開發2庫導3庫的工具 3. 底層存儲介質變換需求：開發Mongo導Mysql工具 3. 步驟三：恢復服務，并將流量切到新庫，不同的需求，可能會涉及不同服務升級。 1. 底層表結構變更需求：服務要升級到訪問新表 2. 分庫個數變換需求：服務不需要升級，只需要改尋庫路由配置 3. 底層存儲介質變換需求：服務升級到訪問新的存儲介質 ### 平滑遷移-追日志法  1. 步驟一：服務進行升級，記錄“對舊庫上的數據修改”的日志（這里的修改，為數據的insert, delete, update），這個日志不需要記錄詳細數據，主要記錄： 1. 被修改的庫 2. 被修改的表 3. 被修改的唯一主鍵 具體新增了什么行，修改后的數據格式是什么，不需要詳細記錄。這樣的好處是，不管業務細節如何變化，日志的格式是固定的，這樣能保證方案的通用性 2. 步驟二：研發一個數據遷移工具，進行數據遷移。這個數據遷移工具和離線遷移工具一樣，把舊庫中的數據轉移到新庫中來。 這個小工具的風險較小： 1. 整個過程依然是舊庫對線上提供服務 2. 小工具的復雜度較低 3. 任何時間發現問題，都可以把新庫中的數據干掉重來 3. 可以限速慢慢遷移，技術同學沒有時間壓力 在數據遷移的過程中，舊庫依然對線上提供著服務，庫中的數據隨時可能變化，這個變化并沒有反映到新庫中來，于是舊庫和新庫的數據并不一致，所以不能直接切庫，需要將數據追平 3. 步驟三：研發一個讀取日志并遷移數據的小工具，要把步驟二遷移數據過程中產生的差異數據追平。這個小工具需要做的是： 1. 讀取日志，得到哪個庫、哪個表、哪個主鍵發生了變化 2. 把舊庫中對應主鍵的記錄讀取出來 3. 把新庫中對應主鍵的記錄替換掉 無論如何，**原則是數據以舊庫為準** 這個小工具的風險也很小： 1. 整個過程依然是舊庫對線上提供服務 2. 小工具的復雜度較低 3. 任何時間發現問題，大不了從步驟二開始重來 4. 可以限速慢慢重放日志，技術同學沒有時間壓力 新庫與舊庫中的數據追平也會是一個“**無限逼近”**的過程 4. 步驟四：在持續重放日志，追平數據的過程中，研發一個數據校驗的小工具，將舊庫和新庫中的數據進行比對，直到數據完全一致。 這個小工具的風險依舊很小： 1. 整個過程依然是舊庫對線上提供服務 2. 小工具的復雜度較低 3. 任何時間發現問題，大不了從步驟二開始重來 4. 可以限速慢慢比對數據，技術同學沒有時間壓力 5. 步驟五：在數據比對完全一致之后，將流量遷移到新庫，新庫提供服務，完成遷移。 如果步驟四數據一直是99.9%的一致，不能完全一致，也是正常的，可以做一個秒級的舊庫readonly，等日志重放程序完全追上數據后，再進行切庫切流量 ### 平滑遷移-雙寫法  1. 步驟一：服務進行升級，對“對舊庫上的數據修改”（這里的修改，為數據的insert, delete, update），在新庫上進行相同的修改操作，這就是所謂的“雙寫”，主要修改操作包括： 1. 舊庫與新庫的同時insert 2. 舊庫與新庫的同時delete 3. 舊庫與新庫的同時update 由于新庫中此時是沒有數據的，所以雙寫舊庫與新庫中的affect rows可能不一樣，不過這完全不影響業務功能，只要不切庫，依然是舊庫提供業務服務。 這個服務升級風險較小： 1. 寫接口是少數接口，改動點較少 2. 新庫的寫操作執行成功與否，對業務功能沒有任何影響 2. 步驟二：研發一個數據遷移工具，進行數據遷移。這個數據遷移工具在本文中已經出現第三次了，把舊庫中的數據轉移到新庫中來。 這個小工具的風險較小： 1. 整個過程依然是舊庫對線上提供服務 2. 小工具的復雜度較低 3. 任何時間發現問題，都可以把新庫中的數據干掉重來 4. 可以限速慢慢遷移，技術同學沒有時間壓力