上篇《MySQL怎么秒級平滑擴容？》之后，很多朋友提問，說如果不是“雙倍”擴容，能否做到平滑遷移，不影響服務呢？今天和大家聊聊這個話題。

適用什么場景？

互聯網有很多“數據量較大，并發量較大，業務復雜度較高”的業務場景，其典型系統分層架構如下：

• 上游是業務層biz，實現個性化的業務邏輯；
• 中游是服務層service，封裝數據訪問；
• 下游是數據層db，存儲固化的業務數據。

服務化分層架構的好處是，服務層屏蔽下游數據層的復雜性，例如緩存、分庫分表、存儲引擎等存儲細節不需要向調用方暴露，而只向上游提供方便的RPC訪問接口，當有一些數據層變化的時候，所有的調用方也不需要升級，只需要服務層升級即可。

互聯網架構，很多時候面臨著這樣一些需求：

(1) 底層表結構變更：數據量非常大的情況下，數據表增加了一些屬性，刪除了一些屬性，修改了一些屬性。

(2) 分庫個數變化：由于數據量的持續增加，底層分庫個數非成倍增加。

(3) 底層存儲介質變化：底層存儲引擎由一個數據庫換為另一個數據庫。

種種需求，都需要進行數據遷移，如何平滑遷移數據，遷移過程不停機，保證系統持續服務，是文本將要討論的問題。

方案一：停機方案。

在討論平滑遷移數據方案之前，先看下不平滑的停機數據遷移方案，主要分三個步驟。

步驟一：掛一個類似“為了給廣大用戶提供更好的服務，服務器會在凌晨0:00-0:400進行停機維護”的公告，并在對應時段進行停機，這個時段系統沒有流量進入。

步驟二：停機后，研發一個離線的數據遷移工具，進行數據遷移。針對第一節的三類需求，會分別開發不同的數據遷移工具。

• 底層表結構變更需求：開發舊表導新表的工具；
• 分庫個數變換需求：開發2庫導3庫的工具；
• 底層存儲介質變換需求：開發Mongo導Mysql工具。

步驟三：恢復服務，并將流量切到新庫，不同的需求，可能會涉及不同服務升級。

• 底層表結構變更需求：服務要升級到訪問新表；
• 分庫個數變換需求：服務不需要升級，只需要改尋庫路由配置；
• 底層存儲介質變換需求：服務升級到訪問新的存儲介質。

總的來說，停機方案是相對直觀和簡單的，但對服務的可用性有影響，許多游戲公司的服務器升級，游戲分區與合區，可能會采用類似的方案。

除了影響服務的可用性，這個方案還有一個缺點，就是必須在指定時間完成升級，這個對研發、測試、運維同學來說，壓力會非常大，一旦出現問題例如數據不一致，必須在規定時間內解決，否則只能回滾。根據經驗，人壓力越大越容易出錯，這個缺點一定程度上是致命的。

無論如何，停機方案并不是今天要討論的重點，接下來看一下常見的平滑數據遷移方案。

方案二：追日志方案。

追日志方案，是一個高可用的平滑遷移方案，這個方案主要分為五個步驟。

數據遷移前，上游業務應用通過舊的服務訪問舊的數據。

步驟一：服務進行升級，記錄“對舊庫上的數據修改”的日志（數據的insert, delete, update），這個日志不需要記錄詳細數據，主要記錄：

• 被修改的庫；
• 被修改的表；
• 被修改的唯一主鍵。

具體新增了什么行，修改后的數據格式是什么，不需要詳細記錄。這樣的好處是，不管業務細節如何變化，日志的格式是固定的，這樣能保證方案的通用性。

這個服務升級風險較小：

• 寫接口是少數接口，改動點較少；
• 升級只是增加了一些日志，對業務功能沒有任何影響。

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

這個小工具的風險較小：

• 整個過程依然是舊庫對線上提供服務；
• 小工具的復雜度較低；
• 任何時間發現問題，都可以把新庫中的數據干掉重來；
• 可以限速慢慢遷移，技術同學沒有時間壓力。

數據遷移完成之后，就能夠切到新庫提供服務了么？

答案是否定的，在數據遷移的過程中，舊庫依然對線上提供著服務，庫中的數據隨時可能變化，這個變化并沒有反映到新庫中來，于是舊庫和新庫的數據并不一致，所以不能直接切庫，需要將數據追平。

哪些數據發生了變化呢？

步驟一中日志里記錄的，正是變化的數據。

步驟三：研發一個讀取日志并遷移數據的小工具，要把步驟二遷移數據過程中產生的差異數據追平。這個小工具需要做的是：

• 讀取日志，得到哪個庫、哪個表、哪個主鍵發生了變化；
• 把舊庫中對應主鍵的記錄讀取出來；
• 把新庫中對應主鍵的記錄替換掉。

無論如何，原則是數據以舊庫為準。

這個小工具的風險也很小：

• 整個過程依然是舊庫對線上提供服務；
• 小工具的復雜度較低；
• 任何時間發現問題，大不了從步驟二開始重來；
• 可以限速慢慢重放日志，技術同學沒有時間壓力。

日志重放之后，就能夠切到新庫提供服務了么？

答案依然是否定的，在日志重放的過程中，舊庫中又可能有數據發生了變化，導致數據不一致，所以還是不能切庫，需要進一步讀取日志，追平記錄。可以看到，重放日志追平數據的程序是一個while(1)的程序，新庫與舊庫中的數據追平也會是一個“無限逼近”的過程。

什么時候數據會完全一致呢？

步驟四：在持續重放日志，追平數據的過程中，研發一個數據校驗的小工具，將舊庫和新庫中的數據進行比對，直到數據完全一致。

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

• 整個過程依然是舊庫對線上提供服務；
• 小工具的復雜度較低；
• 任何時間發現問題，大不了從步驟二開始重來；
• 可以限速慢慢比對數據，技術同學沒有時間壓力。

步驟五：在數據比對完全一致之后，將流量遷移到新庫，新庫提供服務，完成遷移。

如果步驟四數據一直是99.9%的一致，不能完全一致，也是正常的，可以做一個秒級的舊庫readonly，等日志重放程序完全追上數據后，再進行切庫切流量。

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

方案三：雙寫方案。

雙寫方案，也是一個高可用的平滑遷移方案，這個方案主要分為四個步驟。

數據遷移前，上游業務應用通過舊的服務訪問舊的數據。

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

• 舊庫與新庫的同時insert；
• 舊庫與新庫的同時delete；
• 舊庫與新庫的同時update。

由于新庫中此時是沒有數據的，所以雙寫舊庫與新庫中的affect rows可能不一樣，不過這完全不影響業務功能，只要不切庫，依然是舊庫提供業務服務。

這個服務升級風險較小：

• 寫接口是少數接口，改動點較少；
• 新庫的寫操作執行成功與否，對業務功能沒有任何影響。

步驟二：研發一個數據遷移工具，進行數據遷移。這個數據遷移工具在本文中已經出現第三次了，把舊庫中的數據轉移到新庫中來。

這個小工具的風險較小：

• 整個過程依然是舊庫對線上提供服務；
• 小工具的復雜度較低；
• 任何時間發現問題，都可以把新庫中的數據干掉重來；
• 可以限速慢慢遷移，技術同學沒有時間壓力。

數據遷移完成之后，就能夠切到新庫提供服務了么？

答案是肯定的，因為前置步驟進行了雙寫，所以理論上數據遷移完之后，新庫與舊庫的數據應該完全一致。

由于遷移數據的過程中，舊庫新庫雙寫操作在同時進行，怎么證明數據遷移完成之后數據就完全一致了呢？

如上圖所示：

(1) 左側是舊庫中的數據，右側是新庫中的數據；

(2) 按照primary key從min到max的順序，分段，限速進行數據的遷移，假設已經遷移到now這個數據段，數據遷移過程中的修改操作分別討論：

① 假設遷移過程中進行了一個雙insert操作，舊庫新庫都插入了數據，數據一致性沒有被破壞

② 假設遷移過程中進行了一個雙delete操作，這又分為兩種情況

• 情況一：假設這delete的數據屬于[min,now]范圍，即已經完成遷移，則舊庫新庫都刪除了數據，數據一致性沒有被破壞；
• 情況二：假設這delete的數據屬于[now,max]范圍，即未完成遷移，則舊庫中刪除操作的affect rows為1，新庫中刪除操作的affect rows為0，但是數據遷移工具在后續數據遷移中，并不會將這條舊庫中被刪除的數據遷移到新庫中，所以數據一致性仍沒有被破壞。

假設遷移過程中進行了一個雙update操作，可以認為update操作是一個delete加一個insert操作的復合操作，所以數據仍然是一致的

除非，在一種非常極限的情況下：

• date-migrate-tool剛好從舊庫中將某一條數據X取出；
• 在X插入到新庫中之前，舊庫與新庫中剛好對X進行了雙delete操作；
• date-migrate-tool再將X插入到新庫中。

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

但無論如何，為了保證數據的一致性，切庫之前，還是需要進行數據校驗的。

步驟三：在數據遷移完成之后，需要使用數據校驗的小工具，將舊庫和新庫中的數據進行比對，完全一致則符合預期，如果出現步驟二中的極限不一致情況，則以舊庫中的數據為準。

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

• 整個過程依然是舊庫對線上提供服務；
• 小工具的復雜度較低；
• 任何時間發現問題，大不了從步驟二開始重來；
• 可以限速慢慢比對數據，技術同學沒有時間壓力。

步驟四：數據完全一致之后，將流量切到新庫，完成平滑數據遷移。

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

總結

針對互聯網很多“數據量較大，并發量較大，業務復雜度較高”的業務場景，在：

• 底層表結構變更；
• 分庫個數變化；
• 底層存儲介質變化。

的眾多需求下，需要進行數據遷移，完成“平滑遷移數據，遷移過程不停機，保證系統持續服務”有兩種常見的解決方案。

追日志方案，五個步驟：

• 服務進行升級，記錄“對舊庫上的數據修改”的日志；
• 研發一個數據遷移小工具，進行數據遷移；
• 研發一個讀取日志小工具，追平數據差異；
• 研發一個數據比對小工具，校驗數據一致性；
• 流量切到新庫，完成平滑遷移。

雙寫方案，四個步驟：

• 服務進行升級，記錄“對舊庫上的數據修改”進行新庫的雙寫；
• 研發一個數據遷移小工具，進行數據遷移；
• 研發一個數據比對小工具，校驗數據一致性；
• 流量切到新庫，完成平滑遷移。

知其然，知其所以然。

思路比結論更重要。