100億數據平滑數據遷移,不影響服務

---

title: '100億數據平滑數據遷移,不影響服務'
date: 2017-04-26 00:13:44
tags: 數據庫
categories: 轉載

100億數據平滑數據遷移,不影響服務

2017-03-23 58沈劍 架構師之路

1、問題的提出

互聯網有不少「數據量較大，併發量較大，業務複雜度較高」的業務場景，其典型系統分層架構以下：

（1）上游是業務層biz，實現個性化的業務邏輯

（2）中游是服務層service，封裝數據訪問

（3）下游是數據層db，存儲固化的業務數據

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

互聯網架構，不少時候面臨着這樣一些需求：

需求1->底層表結構變動：數據量很是大的狀況下，數據表增長了一些屬性，刪除了一些屬性，修改了一些屬性。

需求2->分庫個數變換：因爲數據量的持續增長，底層分庫個數非成倍增長。

需求3->底層存儲介質變換：底層存儲引擎由一個數據庫換爲另外一個數據庫。

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

2、停機方案

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

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

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

（1）底層表結構變動需求：開發舊錶導新表的工具

（2）分庫個數變換需求：開發2庫導3庫的工具

（3）底層存儲介質變換需求：開發Mongo導Mysql工具

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

（1）底層表結構變動需求：服務要升級到訪問新表

（2）分庫個數變換需求：服務不須要升級，只須要改尋庫路由配置

（3）底層存儲介質變換需求：服務升級到訪問新的存儲介質

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

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

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

3、平滑遷移-追日誌法

平滑遷移方案一，追日誌法，這個方案主要分爲五個步驟。

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

步驟一：服務進行升級，記錄「對舊庫上的數據修改」的日誌（這裏的修改，爲數據的insert, delete, update），這個日誌不須要記錄詳細數據，主要記錄：

（1）被修改的庫

（2）被修改的表

（3）被修改的惟一主鍵

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

這個服務升級風險較小：
（1）寫接口是少數接口，改動點較少
（2）升級只是增長了一些日誌，對業務功能沒有任何影響

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

這個小工具的風險較小：

（1）整個過程依然是舊庫對線上提供服務
（2）小工具的複雜度較低
（3）任什麼時候間發現問題，均可以把新庫中的數據幹掉重來
（4）能夠限速慢慢遷移，技術同窗沒有時間壓力

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

答案是否認的，在數據遷移的過程當中，舊庫依然對線上提供着服務，庫中的數據隨時可能變化，這個變化並無反映到新庫中來，因而舊庫和新庫的數據並不一致，因此不能直接切庫，須要將數據追平。

哪些數據發生了變化呢？

步驟一中日誌裏記錄的不就是麼？

步驟三：研發一個讀取日誌並遷移數據的小工具，要把步驟二遷移數據過程當中產生的差別數據追平。這個小工具須要作的是：

（1）讀取日誌，獲得哪一個庫、哪一個表、哪一個主鍵發生了變化

（2）把舊庫中對應主鍵的記錄讀取出來

（3）把新庫中對應主鍵的記錄替換掉

不管如何，原則是數據以舊庫爲準。

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

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

（2）小工具的複雜度較低

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

（4）能夠限速慢慢重放日誌，技術同窗沒有時間壓力

日誌重放以後，就可以切到新庫提供服務了麼？

答案依然是否認的，在日誌重放的過程當中，舊庫中又可能有數據發生了變化，致使數據不一致，因此仍是不能切庫，須要進一步讀取日誌，追平記錄。能夠看到，重放日誌追平數據的程序是一個while(1)的程序，新庫與舊庫中的數據追平也會是一個「無限逼近」的過程。

何時數據會徹底一致呢？

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

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

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

（2）小工具的複雜度較低

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

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

步驟五：在數據比對徹底一致以後，將流量遷移到新庫，新庫提供服務，完成遷移。

若是步驟四數據一直是99.9%的一致，不能徹底一致，也是正常的，能夠作一個秒級的舊庫readonly，等日誌重放程序徹底追上數據後，再進行切庫切流量。

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

4、平滑遷移-雙寫法

平滑遷移方案二，雙寫法，這個方案主要分爲四個步驟。

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

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

（1）舊庫與新庫的同時insert

（2）舊庫與新庫的同時delete

（3）舊庫與新庫的同時update

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

這個服務升級風險較小：

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

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

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

這個小工具的風險較小：

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

（2）小工具的複雜度較低

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

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

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

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

因爲遷移數據的過程當中，舊庫新庫雙寫操做在同時進行，怎麼證實數據遷移完成以後數據就徹底一致了呢？

如上圖所示：

（1）左側是舊庫中的數據，右側是新庫中的數據

（2）按照primary key從min到max的順序，分段，限速進行數據的遷移，假設已經遷移到now這個數據段

數據遷移過程當中的修改操做分別討論：

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

（2）假設遷移過程當中進行了一個雙delete操做，這又分爲兩種狀況

（2.1）假設這delete的數據屬於[min,now]範圍，即已經完成遷移，則舊庫新庫都刪除了數據，數據一致性沒有被破壞

（2.2）假設這delete的數據屬於[now,max]範圍，即未完成遷移，則舊庫中刪除操做的affect rows爲1，新庫中刪除操做的affect rows爲0，可是數據遷移工具在後續數據遷移中，並不會將這條舊庫中被刪除的數據遷移到新庫中，因此數據一致性仍沒有被破壞

（3）假設遷移過程當中進行了一個雙update操做，能夠認爲update操做是一個delete加一個insert操做的複合操做，因此數據仍然是一致的

除非除非除非，在一種很是很是很是極限的狀況下：

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

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

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

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

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

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

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

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

（2）小工具的複雜度較低

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

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

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

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

5、總結

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

（1）底層表結構變動

（2）分庫個數變換

（3）底層存儲介質變換

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

追日誌法，五個步驟：

（1）服務進行升級，記錄「對舊庫上的數據修改」的日誌

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

（3）研發一個讀取日誌小工具，追平數據差別

（4）研發一個數據比對小工具，校驗數據一致性

（5）流量切到新庫，完成平滑遷移

雙寫法，四個步驟：

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

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

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

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