21世紀了還愚公移山？數據庫這麼遷移更穩定！

背景

在系統的快速迭代過程當中，業務系統每每部署在同一個物理庫，沒有作核心數據和非核心數據的物理隔離。隨着數據量的擴大這種狀況會帶來穩定性的風險，如庫的慢sql，磁盤，IO等等都會相互總體影響，從而影響核心系統的業務穩定性，所以須要將核心業務的業務表從原有庫裏抽取出來，單獨到新庫裏。而核心數據的遷移，涉及到的一個關鍵難點：如何平穩及用戶無感知的遷移數據，本文將結合閒魚商品庫遷移實踐，向你們展現如何解決這個難題的.

閒魚商品數據現狀

閒魚商品數據量XX億級別以上，採用分表分庫和讀寫分離的MYSQL數據庫集羣來支撐線上查詢服務,以下圖，經過TDDL[1]數據庫中間件進行高效統一管理。可能有些同窗會對分表分庫相關概念不瞭解，這裏先簡單作些介紹。

01分表分庫原理

本質是數據庫的水平拆分問題，把一個數據庫切分紅多個部分放到不一樣的數據庫(server)上，從而緩解單一數據庫的性能問題，下圖描述分表分庫的核心原理：

固然分表分庫也有負面影響，就是表結構變動及相關管理相比單表麻煩，有必定風險，具體如何決擇，仍是要根據實際狀況來分析。

02分表分庫下全局Sequence生成

分表分庫解決在線服務容量和性能問題，可是也帶來使用上的複雜度提高。靈活的配置路由規則和路由數據並提供簡單易用的封裝都是要考慮的，以便業務對此無感知。阿里開源中間件產品TDDL提供瞭解決方案，對應阿里雲上產品爲：DRDS[2]。

TDDL關鍵原理很少作介紹，可是在數據庫遷移過程當中主鍵衝突風險是故障重要風險點，這裏簡要介紹下TDDL的全局惟一主鍵生成原理。

如上圖，TDDL Sequence是基於數據庫更新＋內存分配：每次操做批量分配id，分配id的數量就是sequence的內步長，而原有id值就加上外部長值，後續的分配直接就在內存裏拿，這樣的優點：簡單高效 缺點：沒法保證自增順序。

另外數據遷移過程當中，在新庫中，爲了保證跟原數據庫主鍵非衝突，須要設置一個躍遷比較大的主鍵，防止出現兩個庫中的主鍵衝突，這是後續遷移中要注意的關鍵點之一。

數據遷移方案

經過前文的簡單介紹，你們對閒魚商品庫現狀有了初步瞭解，下面將給你們介紹一下閒魚是如何作到穩定遷移商品庫的。

01核心思路

數據遷移核心思路抽象起來其實很簡單，即如何穩定平滑遷移數據，以下圖所示:

但圍繞這個過程細化下去，咱們會遇到很多問題，如：
一、數據咱們該如何遷移，是一次性？仍是分階段？
二、如何校驗數據遷移過程的正確性?
三、咱們業務改造有問題怎麼辦？如何儘早發現？如何回滾？
四、咱們的新庫性能如何？

帶着這些問題，咱們進一下細化梳理遷移方案。

02實現方案

如上圖所示，整個方案分爲幾個部份：

一、系統改造，包括SQL改造，雙寫開關，新庫sequence建立。

SQL改造：加載兩套TDDL數據源，一套是給老庫的，一套是給新庫的，而且生成兩套mybatis sql 模板。
雙寫開關：設置好寫新庫，寫老庫的開關，用於線上遷移過程當中雙寫過程及遇到問題及時回滾。
sequence建立：遷移sequence表時，須要擡升新庫的sequence表中的值，用於防止主鍵衝突，而且須要按照主鍵消耗量評估一個安全值，這是很是重要的一個細節，再次強調一下。

二、穩定性保障，遷庫是大事，改造過程當中，穩定性重中之重，主要有系統壓測，線上流量回放，故障演練。

系統壓測：主要針對新庫進行性能測，防止新庫有意外狀況。
線上流量回放：Edsger W. Dijkstra說過若是調試程序是一種標準的能夠剷除BUG的流程，那麼，編程就是把他們放進來的流程。經過引入線上數據在測試環境回放，能夠儘量的發現問題，保證改造後的穩定性。
故障演練：經過注入一些人爲故障，如寫新庫失敗，新庫邏輯有問題，及時的演練回滾策略。

三、數據遷移，主要利用阿里雲數據傳輸服務DTS[3]的數據遷移能力，涉及到全量遷移、增量遷移、一致性校驗及反向任務。

全量遷移:數據遷移首要目標如何將歷史全量數據遷移到新庫中，咱們的作法是指定一個時間點，再根據這個時間點查找每張源表的最大及最小id,而後分別批量導到目標庫中，如圖：

• 整個過程都是查詢在線庫的備庫，所以不影響在線業務的數據庫服務。

增量遷移:因爲遷移過程當中業務服務一直運行，所以全量遷移徹底成，而且要將全量時間點後的數據追回來，這裏核心原理是同步全量時間位點後binlog日誌數據來保證數據一致性，須要注意的是增量時間須要前移一小斷時間(如5分鐘)，其主要緣由是全量遷移啓動的那刻會有時間差，須要增量前移來保證數據最終一致性，以下圖:

一致性校驗：經過全量及增量的遷移後，此時源庫跟目標的數據理論上是一致的,但實際上應用在通過功能測試，線上流量回放等階段，數據在這個過程當中有可能會現不一致的狀況,所以正式上線前，須要作數據一致性校驗，其原理是分批查詢源表(跟全量遷移的查詢方式相似)，再跟目標庫進行比對,如圖所示：

反向任務：遷移到新庫後，會有一線離線業務對老庫還有依賴，須要創建重新庫到老庫的迴流任務，原理跟增量遷移同樣，只是變動一下原庫及目標庫。

03遷庫流程

到這裏你們應該對遷庫所涉及到點比較清楚了，但還有一個很是重要的事，即梳理整個遷庫步驟很是關鍵，一般會有兩種方案。

方案一：

一、DTS數據追平，即全量同步完成，開啓增量同步，而且延遲在秒級之內。
二、上線前校驗，主要有線上流量回放、壓測、一致性校驗，故障演練。
三、線上開雙寫，線上同時寫新庫及老庫，這時須要關閉增量同步任務，防止無效覆蓋。
四、線上校驗，執行預先準備的測試腳本並結合一致性校驗工具，同時將讀流量慢慢切到新庫，驗證雙寫邏輯。
五、切換數據源，關閉雙寫並正式寫入新庫。
六、建立反向任務，數據迴流老庫。

方案二：

一、DTS數據追平，即全量同步完成，開啓增量同步，而且延遲在秒級之內。
二、上線前校驗，主要有線上流量回放、壓測、一致性校驗，故障演練。
三、線上切開關，寫新庫， 同時須要關閉增量同步任務，防止無效覆蓋。
四、建立反向任務，數據迴流老庫。

方案優缺點對比：

總結起來方案1遷移流程相對複雜，對遷移的控制力度更細，適合業務複雜，底層改造比較多，想精細化控制遷移步驟的場景，方案2遷移相對簡單，過程快速，適合業務流程相對簡單，可控，想快速切換的場景，具體選選擇哪一個方案，同窗們能夠根據自身的業務狀況作選擇。

這裏考慮到閒魚商品業務複雜，底層改造較多，從穩定性的角度考慮，最終選擇方案1。

方案1，最關鍵的是三、四、5步驟，所以須要預先作好回滾計劃。

04回滾方案

回滾方案總原則是不丟數據。最有可能的發生點是雙寫期間新庫出問題，致使線上服務異常，這時只要當即關閉寫新庫便可，另外就是切到新庫後，新庫出問題了(如性能問題)，能夠當即切回到老庫，並經過反向任務，保持數據一致性，最後若沒啓用分佈式事務,雙寫的時間越短越好,有可能會有數據不一致狀況。

小結

經過周密的遷移方案設計，以及DTS強大的數據遷移工具的能力，閒魚商品庫順利完成XX億在線數據庫服務遷移，獨立的物理部署顯著提高商品庫在線服務的穩定性。然而不一樣業務系統的數據庫狀況可能會有差別，如單庫向多庫遷移，單表向多表遷移等，不過總體方案大體相似，但願本文遷庫實踐方案能給你們提供一個可行的參考。

---

本文做者：看鬆

閱讀原文

本文來自雲棲社區合做夥伴「閒魚技術」，如需轉載請聯繫原做者。