記CBS一次動人心魄的數據保衛戰

記CBS一次動人心魄的數據保衛戰

接觸分布式存儲已經有一年多的時間了，首次遇到存儲側三份數據都有異常的情況，三份數據異常意味著客戶數據的丟失，這個對雲存儲來講是致命的打擊。為了保證數據的安全，CBS運維和開發的同學進行了持續兩天一夜的數據保衛戰，最終做到數據0丟失，那麼CBS運維和開發的同學是如何通過緊密合作來扭轉乾坤的？且聽我慢慢道來：

告警來襲，5個小表自動遷移異常

運維側收到一個數據遷移失敗的告警，告警內容如下：

[基礎架構部][CBS3.0_廣州_小set_快照_bonding_set4][10.182.24.13][cbs_web][check_storage_tablet][2016-09-0711:11:19] [error] [重要] CBS3.0_廣州_小set_快照_bonding_set4 有5個1份dead小表，沒空閒小表遷移或者沒有正常遷移，請檢查!

備注：這是為了能保證異常的小標都能正常遷移，提升CBS數據安全的告警。

這種問題優先級最高，因此運維第一時間介入分析，這個是前一天有一台cell的機器異常，系統自動將其剔除，此時正常的數據變成了2份（Cell2和Cell3），如下圖所示：

剔除後會自動發起容災遷移，成功遷移後就能恢復三份數據正常的狀態。查看遷移日志，發現是由於讀取cell數據異常引起

根據以往的經驗，一般是對應的cell機器對應的盤有異常，使用dmesg查看，發現遷移失敗的盤所在的disk確實有異常：

備注：線上的dbtrasf（遷移模塊）暫時不支持指定cell的IP來讀取數據

此時的線上CBS的數據分布變成了如下圖：

此時風險非常高，只有一份數據是正常的，如果此時Cell3再有異常後果將不堪設想，於是緊急和研發的同學溝通遷移方案，經過討論，我們確定了指定從Cell3讀取數據的修復策略。

定向讀取，首戰告捷

確定好方案後，研發開始修改dbtrasf代碼，30分鐘研發修改代碼+自測完成（確實很高效，點贊），運維側拿到支持指定cell讀取數據的包後，在測試環境和仿真環境進行反復遷移過程中的數據一致性校驗，未發現異常。正式開始在線上遷移，事實證明，定向讀取確實靠譜，成功遷移4個小表，還有1個小表遷移仍然報數據讀取失敗，繼續跟進。

多扇區異常，霧霾籠罩

通過使用smatctl分析發現10.53.65.214有14個扇區異常，那個小表的數據剛好有分布在壞的扇區的數據，因此遷移也是讀取數據異常導致遷移失敗。而10.53.65.101有800多個扇區異常，此時基本可以確定三份數據都出現不同程度的損壞。此時部分數據的分布如下圖所示：

嚇死寶寶了，於是和研發的同學一起再次討論緊急修復方案。

備注：分布式存儲1個小表的數據丟失可能是影響到整個set所有的盤的數據。

雙cell數據merage，希望乍現

通過溝通，確定采用雙cell數據merge的方式來修復數據，也就是通過從兩個cell中分別讀取可以讀取的數據進行merge的操作，原理為：

1、 先嘗試從Cell3(10.53.65.214)讀取

2、 讀取失敗的數據再從Cell2(10.53.65.101)上讀取

看看兩次讀取的數據是否能完全修復那個小表的數據。這次只有少量的block讀取失敗，雖然沒成功，但讓人看到了希望：

read from the first[diskid=290763668122043122, lba=1069470973952, sid=1]
[2016-09-09 16:13:38] read from the second[diskid=290763668122043122,lba=1069470973952, sid=1]

三個cell數據merage，扭轉乾坤

通過雙cell的數據merage發現通過兩個cell無法修復那個小表的數據，難道數據就真的修復不了了嗎？

到了這一步，研發的兄弟們還在瘋狂的想辦法，在pallysheng和yhwang的共同努力下，發現有異常的diskid的元數據在三個cell中是一致的，這說明這個數據在機器剔除後沒有新的數據寫入，因此可以通過讀取被剔除機器的數據來恢復：

有了這個腦洞打開的設想，yhwang開始修改工具邏輯，在測試環境做完測試後，繼續開始遷移，遷移的時候大家都緊盯著日志屏幕，直到看到最後打印遷移成功的日志，大家都松了一口氣，數據從新恢復成3份副本了：

至此持續2天1夜的騰訊雲數據保衛戰完美收官，騰訊雲的數據安全離不開每一個運維和研發同學的努力。

總結成敗，穩定江山

經歷了這次驚心動魄的數據修復保衛戰後，運維開發進行了深入的反思，這次數據能修復很大程度上是我們的運氣好，但是做存儲如果將數據安全寄托在運氣上，那麼和耍流氓沒什麼區別。因此最緊要的是如何從這次問題中總結出經驗和教訓，做到類似的問題不再發生，確保我們數據安全更上一層樓，這次問題的反思如下：

存在的問題：

1、 監控上存在漏洞

過去只針對IO錯誤的監控，在針對某個盤只有少量扇區壞掉，並且數據比較少訪問的情況下，通過IO錯誤監控是失效的（比率太低），需要專門增加磁盤粒度的監控。

2、 Cell數據修復缺乏工具支持

將這次線上修復的case進行發散思考，沉澱出來CBS這邊數據修復的相關解決方案和工具

3、 程序邏輯上可以進一步優化

目前IO讀取如果出現異常，會進行重試，但是沒有向不通cell重試的邏輯，這個在後續的程序中也會添加對應的優化。

收獲：

1、 加深了研發和運維的合作

2、 排查過程中充分體現了騰訊人專業、激情、責任

3、 通過這次修復工作提升了CBS團隊在應對3份數據異常修復技術，經驗得到很好的沉澱