21世紀了還愚公移山?資料庫這麼遷移更穩定!

2021-09-12 03:36:49 字數 3088 閱讀 1872

在系統的快速迭代過程中,業務系統往往部署在同乙個物理庫,沒有做核心資料和非核心資料的物理隔離。隨著資料量的擴大這種情況會帶來穩定性的風險,如庫的慢sql,磁碟,io等等都會相互整體影響,從而影響核心系統的業務穩定性,因此需要將核心業務的業務表從原有庫里抽取出來,單獨到新庫里。而核心資料的遷移,涉及到的乙個關鍵難點:如何平穩及使用者無感知的遷移資料,本文將結合閒魚商品庫遷移實踐,向大家展示如何解決這個難題的.

閒魚商品資料現狀

閒魚商品資料量xx億級別以上,採用分表分庫和讀寫分離的mysql資料庫集群來支撐線上查詢服務,如下圖,通過tddl[1]資料庫中介軟體進行高效統一管理。可能有些同學會對分表分庫相關概念不了解,這裡先簡單做些介紹。

分表分庫原理

本質是資料庫的水平拆分問題,把乙個資料庫切分成多個部分放到不同的資料庫(server)上,從而緩解單一資料庫的效能問題,下圖描述分表分庫的核心原理:

當然分表分庫也有負面影響,就是表結構變更及相關管理相比單錶麻煩,有一定風險,具體如何決擇,還是要根據實際情況來分析。

tddl關鍵原理不多做介紹,但是在資料庫遷移過程中主鍵衝突風險是故障重要風險點,這裡簡要介紹下tddl的全域性唯一主鍵生成原理。

如上圖,tddl sequence是基於資料庫更新+記憶體分配:每次操作批量分配id,分配id的數量就是sequence的內步長,而原有id值就加上外部長值,後續的分配直接就在記憶體裡拿,這樣的優勢:簡單高效 缺點:無法保證自增順序。

另外資料遷移過程中,在新庫中,為了保證跟原資料庫主鍵非衝突,需要設定乙個躍遷比較大的主鍵,防止出現兩個庫中的主鍵衝突,這是後續遷移中要注意的關鍵點之一。

資料遷移方案

通過前文的簡單介紹,大家對閒魚商品庫現狀有了初步了解,下面將給大家介紹一下閒魚是如何做到穩定遷移商品庫的。

核心思路

資料遷移核心思路抽象起來其實很簡單,即如何穩定平滑遷移資料,如下圖所示:

但圍繞這個過程細化下去,我們會遇到不少問題,如:

1、資料我們該如何遷移,是一次性?還是分階段?

2、如何校驗資料遷移過程的正確性?

3、我們業務改造有問題怎麼辦?如何盡早發現?如何回滾?

4、我們的新庫效能如何?

實現方案

如上圖所示,整個方案分為幾個部份:

1、系統改造,包括sql改造,雙寫開關,新庫sequence建立。

sql改造:載入兩套tddl資料來源,一套是給老庫的,一套是給新庫的,並且生成兩套mybatis sql 模板。

雙寫開關:設定好寫新庫,寫老庫的開關,用於線上遷移過程中雙寫過程及遇到問題及時回滾。

sequence建立:遷移sequence表時,需要抬公升新庫的sequence表中的值,用於防止主鍵衝突,並且需要按照主鍵消耗量評估乙個安全值,這是非常重要的乙個細節,再次強調一下。

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

系統壓測:主要針對新庫進行效能測,防止新庫有意外情況。

線上流量回放:edsger w. dijkstra說過如果除錯程式是一種標準的可以剷除bug的流程,那麼,程式設計就是把他們放進來的流程。通過引入線上資料在測試環境回放,可以盡可能的發現問題,保證改造後的穩定性。

故障演練:通過注入一些人為故障,如寫新庫失敗,新庫邏輯有問題,及時的演練回滾策略。

3、資料遷移,主要利用阿里雲資料傳輸服務dts[3]的資料遷移能力,涉及到全量遷移、增量遷移、一致性校驗及反向任務。

全量遷移:資料遷移首要目標如何將歷史全量資料遷移到新庫中,我們的做法是指定乙個時間點,再根據這個時間點查詢每張源表的最大及最小id,然後分別批量導到目標庫中,如圖:

增量遷移:由於遷移過程中業務服務一直執行,因此全量遷移完全成,並且要將全量時間點後的資料追回來,這裡核心原理是同步全量時間位點後binlog日誌資料來保證資料一致性,需要注意的是增量時間需要前移一小斷時間(如5分鐘),其主要原因是全量遷移啟動的那刻會有時間差,需要增量前移來保證資料最終一致性,如下圖:

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

反向任務:遷移到新庫後,會有一線離線業務對老庫還有依賴,需要建立從新庫到老庫的回流任務,原理跟增量遷移一樣,只是變更一下原庫及目標庫。

遷庫流程

到這裡大家應該對遷庫所涉及到點比較清楚了,但還有乙個非常重要的事,即梳理整個遷庫步驟非常關鍵,通常會有兩種方案。

方案一:

1、dts資料追平,即全量同步完成,開啟增量同步,並且延遲在秒級以內。

2、上線前校驗,主要有線上流量回放、壓測、一致性校驗,故障演練。

3、線上開雙寫,線上同時寫新庫及老庫,這時需要關閉增量同步任務,防止無效覆蓋。

4、線上校驗,執行預先準備的測試指令碼並結合一致性校驗工具,同時將讀流量慢慢切到新庫,驗證雙寫邏輯。

5、切換資料來源,關閉雙寫並正式寫入新庫。

6、建立反向任務,資料回流老庫。

方案二:

1、dts資料追平,即全量同步完成,開啟增量同步,並且延遲在秒級以內。

2、上線前校驗,主要有線上流量回放、壓測、一致性校驗,故障演練。

3、線上切開關,寫新庫, 同時需要關閉增量同步任務,防止無效覆蓋。

4、建立反向任務,資料回流老庫。

方案優缺點對比:

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

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

方案1,最關鍵的是3、4、5步驟,因此需要預先做好回滾計畫。

回滾方案

回滾方案總原則是不丟資料。最有可能的發生點是雙寫期間新庫出問題,導致線上服務異常,這時只要立即關閉寫新庫即可,另外就是切到新庫後,新庫出問題了(如效能問題),可以立即切回到老庫,並通過反向任務,保持資料一致性,最後若沒啟用分布式事務,雙寫的時間越短越好,有可能會有資料不一致情況。小結

21世紀了還愚公移山?資料庫這麼遷移更穩定!

2019獨角獸企業重金招聘python工程師標準 背景 在系統的快速迭代過程中,業務系統往往部署在同乙個物理庫,沒有做核心資料和非核心資料的物理隔離。隨著資料量的擴大這種情況會帶來穩定性的風險,如庫的慢sql,磁碟,io等等都會相互整體影響,從而影響核心系統的業務穩定性,因此需要將核心業務的業務表從...

21世紀的軟體測試

全程軟體測試,測試是重中之重。全程自動化測試,測試原來可以是這樣的。全程缺陷預防,測試工作已經不是那麼重要。譯文 由於當前商業和it環境的驅動,軟體測試的理念 實踐和工具正在發生一些革命性的變化。這種變化將給專業測試人員及其測試工作帶來什麼樣的影響?這些驅動正在改變專業測試人員的生活 it操作的商業...

21世紀 互動設計

21世紀 互動設計 隨著計算機 資訊科技的高速發展,資訊現在無處不在,怎樣有效地將自身的產品 資訊等,很好被使用者接受,越來越多地被提供商所關注。針對it行業,各種 軟體等到處都是,目的很明確都是為使用者提供更好的服務。然而我們是否真得做到完全滿足客戶的需求,使客戶完全滿意,為使用者提供更方便的服務...