數據安全容不得極小概率，看OceanBase如何應對「靜默錯誤」
OB君：7月20日，騰訊雲北京三區部分雲硬碟IO異常，導致前沿數控技術公司的線上生產數據完全丟失。騰訊雲方面回應這是極小概率事件。即使是再小的概率，一旦發生，對於企業而言面臨的可能都是滅頂之災。本文將帶你深入解讀在面對數據安全性要求更為嚴苛的金融場景下，OceanBase是如何從容應對和處理「靜默錯誤」的。
本文作者：陳群
現任螞蟻金服OceanBase團隊高級技術專家，2010年加入支付寶後從事分散式事務框架的研發，2013年加入Oceanbase團隊，目前負責存儲引擎相關的研發工作。
「數據丟失事件」回溯
7月20日，北京清博數控科技有限公司所屬「前沿數控」平台一塊操作系統雲盤，因受騰訊雲北京三區部分物理硬碟固件版本bug導致的靜默錯誤（寫入數據和讀取出來的不一致）影響，文件系統元數據損壞。
7月20日，騰訊雲用戶告知故障狀態，並組織技術專家嘗試修複數據，最終仍有部分數據完整性校驗失敗。
隨即，「前沿數控技術」通過網媒發聲，表示他們對騰訊雲「99.9999999%數據可靠性，搭載了雲硬碟三副本存儲策略」非常存疑，認為有誇大之嫌。
騰訊雲則表示，硬碟靜默錯誤是在極小概率下被觸發，他們隨即對固件版本有bug的硬碟全部進行下線處理。
靜默錯誤
騰訊雲丟失數據的事件一經爆出就受到廣泛熱議，根據官方給出的說法，原因大概可以歸結為以下兩點：
首先，一個數據副本中的數據出現了靜默錯誤
其次，在數據遷移的過程中違規操作，關閉了數據校驗，導致三副本均複製了錯誤的數據
OceanBase的應對和處理
OceanBase作為分散式資料庫，同樣也使用了三副本的容災模式，由於應用於金融場景，事實上對於數據安全性的要求會更加苛刻。那麼對於靜默錯誤，OceanBase是如何從容應對和處理的呢？
和傳統資料庫不同，OceanBase的存儲引擎是基於LSM-Tree架構的，數據被分為兩部分：動態數據（MemTable）和靜態數據（SSTable）。所有的數據修改（插入、更新、刪除）都會先寫入MemTable，並通過Paxos協議將Redo Log同步到三副本；MemTable中的數據會在合適的時候通過合併的方式轉入SSTable，SSTable是只讀的。在整個過程中，數據會有多次落盤，寫Redo Log時每個副本都需要將Redo Log落盤；在合併時，每個副本都需要將合併後的SSTable落盤。
Redo Log是如何應對靜默錯誤的？
在每條Redo Log的頭部，我們都會記錄這條RedoLog的校驗和，在做網路傳輸和日誌回放時，都會強制對每條日誌的校驗和進行校驗。這樣我們保證了三副本同步到的內存數據至少是不會錯的，如果一條日誌中的數據出現了靜默錯誤，那麼這條日誌一定不會被同步到其他副本。
比較麻煩的是進程重啟，在進程重啟時，如果之前落盤的Redo Log出現了靜默錯誤，校驗和仍然可以幫助我們將錯誤識別出來，但是整個進程會重啟失敗。考慮到三台伺服器同時出現靜默錯誤的概率不是特別大，另外兩個副本的Redo Log仍然可以幫助我們把數據補齊。
SSTable是如何應對靜默錯誤的？
在數據結構上，一個SSTable是由很多宏塊組成的，宏塊是定長的，大小是2M，類似於MySQL或者Oracle的Extent，宏塊是最小的寫IO單位；一個宏塊又由很多微塊組成，微塊是變長的，默認大小大約是16K，類似於MySQL或者Oracle的Page，微塊是最小的讀IO單位。
首先對於每個微塊，我們都會在微塊頭部記錄整個微塊的校驗和，在每次數據讀取時，我們都會對微塊根據校驗和進行校驗，這樣我們就保證用戶讀到的數據一定是正確的。其次對於宏塊，我們會在宏塊頭記錄整個宏塊的校驗和，用於數據的複製遷移。當伺服器出現故障或者需要做負載均衡時，系統會自動做數據副本的複製遷移，在目的端寫入數據之前，會對每個宏塊的校驗和進行校驗，保證寫入的數據是正確的，這樣我們就保證靜默錯誤不會擴散。
出了靜默錯誤後能夠處理當然還是不夠的，我們還需要能夠將靜默錯誤儘早識別出來，因此我們在後台會有個定期巡檢的任務，定期讀取磁碟上的宏塊來做校驗，一旦發現有數據錯誤就會進行預警。發生靜默錯誤後，我們可以把錯誤的數據副本刪除掉，再通過複製遷移的方式從其他伺服器將副本拷貝過來補齊。
冷備——最後的保障
在線上操作時，運維同學通常承擔著巨大的風險，一旦操作不慎就會導致災難性後果。三副本只是盡量保證在硬體故障下，數據不會丟失；但如果運維同學操作失誤，直接將數據刪除，那麼我們如何將數據找回呢？
OceanBase提供了備份恢復的功能，可以將數據備份到外部的NFS或者是分散式存儲上。當發生運維失誤時，還是可以通過備份恢復的方式將數據找回。而對於NFS或者分散式存儲，可以通過RAID或者糾刪碼的方式來再做一份容災。
不止於此，我們希望做得更多
目前OceanBase已經通過以上幾種手段來保證容災，那麼做到這些就足夠了么？當然不是，我們還需要做的更多。對於運維同學drop table、truncate table之類的操作，OceanBase已經提供了回收站的功能，來幫助做數據恢復。但是對於Delete之類的操作，目前仍然只能通過冷備的方式來找回數據。未來我們會提供FlashBack的功能來方便做快速的數據找回。
此外對於靜默錯誤，目前我們也只能通過複製SSTable的方式來做恢復，同時靜默錯誤也會影響到數據查詢。考慮到出現靜默錯誤的數據通常不會太多，我們可以通過拷貝宏塊的方式做內部的自恢復。不影響用戶查詢的同時，也會極大減輕運維同學的負擔。
想跟本文作者陳群深入交流嗎？
想認識螞蟻金服OceanBase團隊的一線技術專家嗎？
TAG:OceanBase |