故障簡介

ACID是事務的四個特性，其中D(Duration)就是講的持久性，數(shù)據(jù)庫的一大價值就在于可以有效處理的故障，保證數(shù)據(jù)不會丟失。隨著分布式數(shù)據(jù)庫的發(fā)展，部署的復雜度上升，數(shù)據(jù)庫面臨的故障場景也越來越多。

常見硬件故障

接下來，我們看下常見數(shù)據(jù)中心的故障概率

[[229900]]

《Designs, Lessons and Advice from Building Large Distributed Systems》，jeff dean

網(wǎng)絡故障

除了上述故障，對于分布式系統(tǒng)設計，還有一些額外的網(wǎng)絡故障需要考慮

腦裂，顧名思義，腦裂指的是系統(tǒng)因為網(wǎng)絡故障被分割為多個獨立的區(qū)域；

多網(wǎng)面條件下，部分網(wǎng)面故障，這個錯誤一般是很難出現(xiàn)的，因為每個網(wǎng)面往往是邏輯的，并不和網(wǎng)卡綁定，如果用戶調整配置出錯，可能導致這種故障，如果系統(tǒng)橫跨多個網(wǎng)面，需要考慮這個故障；

脆弱的數(shù)據(jù)中心

實際上，數(shù)據(jù)中心也沒有想象中的那么穩(wěn)定，下圖是筆者2017年11月22日截取的cloudharmony監(jiān)控數(shù)據(jù)，監(jiān)控300多家數(shù)據(jù)中心的可靠性情況。

可以看到，即使大名鼎鼎的azure，也未能達到宣稱99.95%，有興趣的詳細了解的可以看這里

除此之外，再給大家舉幾個詳細的例子

2017年9月29日 azure北歐數(shù)據(jù)中心故障

北歐數(shù)據(jù)中心部分在定期的常規(guī)滅火系統(tǒng)維護中發(fā)生了意外，釋放出了滅火劑。然后導致了專門用于遏制和安全的空氣處理單元（AHU）自動關閉。而受到影響區(qū)域的某些系統(tǒng)為防止系統(tǒng)過熱對部分機器進行關機和重啟，AHU在35分鐘后手動恢復，因為系統(tǒng)突然關機導致部分數(shù)據(jù)需要恢復，系統(tǒng)在7小時后才恢復正常。該事故導致了部分用戶的存儲服務不可用。

2017年2月28日amazon s3故障

運維工程師定位賬務系統(tǒng)變慢這個問題時，想要刪除一小部分服務器，結果命令輸入錯誤刪除了大批服務器，包括 index subsystem和placement subsystem的服務器，導致S3服務從9:37AM開始不可用，直到1:54PM，其中最有意思的是，AWS Service Health Dashboard系統(tǒng)依賴S3，因此從故障發(fā)生直到11:37AM，監(jiān)控頁面沒有顯示故障。這個故障據(jù)說弄倒了半個墻外的互聯(lián)網(wǎng)世界。

2016年4月13日Google Compute Engine停止服務

全球所有區(qū)域的Google Compute Engine停止服務，18分鐘后恢復。該故障由一個運維工程師刪除一個無用的ip blocks引起的，而刪除ip這個操作并沒有合理做配置同步，這個操作觸發(fā)了網(wǎng)絡配置系統(tǒng)的一致性檢測，當網(wǎng)絡配置系統(tǒng)檢測到不一致后，進行了重啟，導致服務中斷。

2015年5月27日 杭州電信挖斷阿里網(wǎng)線

光纖挖斷后，部分用戶無法使用，兩小時后恢復。

2014年7月1日 寧夏銀行核心數(shù)據(jù)庫系統(tǒng)故障

銀行二部（2014）187號正式發(fā)全國文件，對寧夏銀行事故的描述大致如下，2014年7月1日，寧夏銀行核心系統(tǒng)數(shù)據(jù)庫出現(xiàn)故障，導致該行（含異地分支機構）存取款、轉賬支付、借記卡、網(wǎng)上銀行、ATM和POS業(yè)務全部中斷。

經(jīng)初步分析，在季末結算業(yè)務量較大的情況下，因備份系統(tǒng)異常導致備份存儲磁盤讀寫處理嚴重延時，備份與主存儲數(shù)據(jù)不一致，在采取中斷數(shù)據(jù)備份錄像操作后，造成生產(chǎn)數(shù)據(jù)庫損壞并宕機。因寧夏銀行應急恢復處置機制嚴重缺失，導致系統(tǒng)恢復工作進展緩慢，直至7月3日5點40分核心系統(tǒng)才恢復服務，業(yè)務系統(tǒng)中斷長達37小時40分鐘，其間完全依靠手工辦理業(yè)務。

故障分類

看一下數(shù)據(jù)中心網(wǎng)絡的互聯(lián)圖

圖上任何的硬件設備都可能發(fā)生故障，從各個主機，交換機到網(wǎng)線。

我們嘗試以故障域對故障做一個簡單的分類。所謂故障域，就是會因為一個故障而同時不可用的一組組件，常見的故障域包括：

• 物理機器，包括本地磁盤，網(wǎng)卡故障，內(nèi)存故障等
• 數(shù)據(jù)中心共用一組電源的一個機柜
• 數(shù)據(jù)中心共用一個網(wǎng)絡設備的數(shù)個機柜
• 受單個光纖影響的一個數(shù)據(jù)中心
• 處于同一個地域的多組數(shù)據(jù)中心，被同一個城市供電或受同一自然災害影響

故障的變化

不同組件發(fā)生故障的概率是不同，google一項研究表明，在36 °C和47 °C范圍內(nèi)運轉的磁盤，故障率***，隨著時間的發(fā)展，磁盤故障率也逐漸提升，***年只有1.7%，第三年達到8.6%。

現(xiàn)在也有很多研究，將大數(shù)據(jù)和人工智能引入了磁盤故障預測領域，取得了不錯的成果。

數(shù)據(jù)庫故障處理

日志系統(tǒng)

數(shù)據(jù)庫會為數(shù)據(jù)修改記錄日志，日志記錄了數(shù)據(jù)的變化，根據(jù)不同的日志用途，可以分為redo日志、. undo日志、redo/undo日志，現(xiàn)在流行的是redo日志。

看一下postgresql日志的結構：

根據(jù)不同日志記錄方式，可以分為如下兩種類型：

1. 物理日志，上圖即物理日志，replay速度快，但是日志量大，實現(xiàn)邏輯相對簡單不易出錯；
2. 邏輯日志，replay速度相對慢，日志量小，而且對于MVCC機制的數(shù)據(jù)庫有一個額外的好處，備機可以單獨gc，和主機無關；

數(shù)據(jù)庫日志系統(tǒng)有兩個重要的原理：

1. WAL原則，也就是日志刷盤要在頁面刷盤之前，這里的刷盤，并非調用write就可以，還需要調用sync操作。在合適時機，往往是事務提交時，將日志刷盤，并調用sync同步到磁盤，以保證斷電時可以恢復數(shù)據(jù)。除了在事務提交時將日志刷盤，在涉及元數(shù)據(jù)操作時，往往也會調用sync將數(shù)據(jù)刷盤，以保證元數(shù)據(jù)的一致。
2. 通過日志系統(tǒng)恢復，不僅僅需要一份完好的日志，還需要一份完整的（可以是落后的）數(shù)據(jù)作為起點。

日志系統(tǒng)是系統(tǒng)軟件內(nèi)廣泛使用的技術，不僅僅是數(shù)據(jù)庫，日志代表了系統(tǒng)的改變，他可以用來恢復/備份，也可以用做通知系統(tǒng)，掌握了系統(tǒng)的日志流，就相當于掌握了系統(tǒng)的整個狀態(tài)，日志可以更抽象的理解為日志+狀態(tài)機，通過不斷的重訪日志，改變狀態(tài)機的狀態(tài)，可以通過傳遞日志將狀態(tài)改變傳遞到整個系統(tǒng)的各個角落，關于日志系統(tǒng)，筆者見過的***的一篇文章是The Log: What every software engineer should know about real-time data’s unifying abstraction，非常推薦一讀，日志即一切。

日志回收

日志代表了系統(tǒng)所有的變化，如果數(shù)據(jù)大小是從0開始擴展到100G，那么日志至少也要有100G，甚至更多，而日志的增長和用戶做出的改動是正相關，任何系統(tǒng)也無法存儲***增長的日志。

回收日志所占存儲空間是必然的選擇，日志收回有兩個好處：

1. 減少日志占據(jù)磁盤空間
2. 降低系統(tǒng)恢復需要的時間

實際上，對于MVCC機制實現(xiàn)的數(shù)據(jù)庫，因為日志回收和事務提交沒有關系，所以可以嚴格的將日志控制在指定大小，為系統(tǒng)運維提供方便。

上文所說數(shù)據(jù)恢復需要一份完好的數(shù)據(jù)作為起點，其實原因就是最開始的日志被回收了，如果能保留從初始狀態(tài)到***狀態(tài)的所有日志，那么光靠日志也可以恢復系統(tǒng)，但是很明顯，任何系統(tǒng)也不能保留所有日志。

checkpoint

checkpoint用于回收日志，checkpoint的流程如下：

打點：記錄當前日志位置；

將當前系統(tǒng)內(nèi)所有內(nèi)存中的數(shù)據(jù)刷盤，并調用sync同步到磁盤，此時仍要遵循WAL原則；

寫checkpoint日志，或將checkpoint信息作為元數(shù)據(jù)刷盤；

回收checkpoint起始點之前的日志；

上面是常見的做checkpoint方式，這種方式也叫做全量檢查點(full checkpoint)，這種方式實現(xiàn)簡單，但是明顯checkpoint是一次IO峰值，會造成性能抖動。

還有一種做checkpoint的方式，叫做增量檢查點(incremental checkpoint)，過程如下：

后臺寫進程按照頁面***次修改的順序刷盤；

打點：記錄當前刷盤的頁面對應的日志點，寫checkpoint日志或者作為元數(shù)據(jù)刷盤；

這種方式化checkpoint為后臺寫操作，做checkpoint時只需要打點即可，消除了IO峰值，有助于平穩(wěn)數(shù)據(jù)庫性能。

torn page

數(shù)據(jù)庫頁面大小和磁盤扇區(qū)大小往往不同，因此當頁面刷盤時，如果系統(tǒng)斷電，可能只有部分頁面刷盤，這種現(xiàn)象，我們稱之為torn page，這個頁面相當于被徹底損壞，而日志replay需要一份完整的數(shù)據(jù)做起點，此時是無法恢復的。

處理半寫有幾種方式：

1. innodb的double write，pg的full page write，這兩種方式原理是類似的，都是在頁面刷盤前，將頁面首先寫在其他地方，sync后，再覆蓋寫頁面。
2. 從備份恢復，從備份單獨恢復某一個頁面。

這里有幾個例外:

1. 追加寫的系統(tǒng)沒有這個問題；
2. 如果頁面大小和扇區(qū)大小相同，也沒有這個問題，很多元數(shù)據(jù)設計都會考慮這點；
3. 很多文件系統(tǒng)或分布式文件系統(tǒng)，raid卡，或者磁盤本身也可以處理這個故障，如果使用能自處理半寫故障的硬件，數(shù)據(jù)庫就可以不開啟這個功能；

磁盤寫滿

磁盤寫滿這種問題只能通過運維手段解決，因為數(shù)據(jù)庫事務提交必須寫日志，如果無法寫日志，那么任何事務都不能提交，相當于停庫，因此應對磁盤故障一般是通過監(jiān)控，在磁盤空間即將不足時提前預警。

磁盤損壞

如上文所說，數(shù)據(jù)庫恢復需要一份完整的數(shù)據(jù)和日志，因此，如果數(shù)據(jù)或者日志遇到了磁盤損壞，日志系統(tǒng)是無法恢復，只能依賴其他的方式了。

備份

按照級別劃分，常見的備份方式有：

1. 全量備份：傳統(tǒng)數(shù)據(jù)庫全量備份通常的做法是首先做一次checkpoint，然后將所有的數(shù)據(jù)和checkpoint點之后的日志拷貝走，如果數(shù)據(jù)量很多，這是一次很重的操作；
2. 增量備份：增量備份同樣需要做一次checkpoint，然后將上一次備份后變化的頁面和checkpoint點之后的日志拷貝走，如何找到上一次備份之后變化的頁面，做全量頁面比對是一種方法，通過bitmap文件記錄頁面變化也是一種方法，percona就實現(xiàn)了第二種方法；增量備份往往是可以疊加的，也是可以合并的，全量備份和增量備份也可以按時間順序合并。
3. 日志歸檔：日志歸檔指的是將制定的日志定時歸檔；

很顯然，從上述操作的開銷從大到小排列依次是，全量備份>增量備份>日志歸檔。數(shù)據(jù)庫運維時往往會結合這三種方式，以達到縮小故障RPO的目標。

amazon aurora實現(xiàn)了近實時備份的功能，備份時間不超過5分鐘。

多機熱備

如果某臺機器因此各種原因發(fā)生了故障，比如cpu燒毀，內(nèi)存故障，或者操作系統(tǒng)bug，甚至被炸掉了，都可以使用備份的方式恢復。

但是通過備份恢復往往耗時較長，不能滿足業(yè)務連續(xù)性(Business Continuity)的需求，除了備份以外，數(shù)據(jù)庫都支持單機熱備，以及支持只讀查詢的備機。

很明顯，備機要根據(jù)故障域和客戶的要求，進行反親和部署。

master-slave(-cascade)

每個主機可以掛多個備機，每個備機可以掛多個級連備，這是當前傳統(tǒng)數(shù)據(jù)庫的常見部署方式。postgres甚至支持多級的級連備（次級連）等等，但是不是很常用。這種部署方式可以有效的處理單機故障。作為支持只讀操作的備機，可以有效的分攤讀負載，這是一種有延遲的讀操作，本身也是滿足相應隔離級別的，但是和主機放在一起考慮的話，并沒有一致性可言。

事務提交時機

根據(jù)主機事務的提交時機，有幾種事務提交級別：

主機日志落盤，此時RTO<1min，RPO>0

主機日志落盤，同時主機日志發(fā)送到備機，此時RTO<1min，RPO=0

主機日志落盤，同時主機日志發(fā)送到備機，并且落盤，此時RTO<1min，RPO=0

這三種提交級別，主機性能越來越差，一般而言，同城備機采用第二種方式，異地備機使用***種方式。

共享磁盤

共享磁盤方案依賴共享存儲，備機只讀不寫，雖然備機不寫盤，但仍然需要不斷的在內(nèi)存replay日志，以便主機故障后能快速升主。

很明顯，share disk方案性能類似數(shù)據(jù)單機，而且RTO<1min，RPO=0。但是受硬件限制，sharding disk方案只適用于同城。

技術是螺旋式前進的，在分布式計算中，share disk的思想也很流行，很多系統(tǒng)依賴分布式文件系統(tǒng)/存儲系統(tǒng)，在其上構建基于share disk的計算系統(tǒng)，比如大數(shù)據(jù)領域久負盛名的hadoop，還有OLTP領域的新力量aurora，還有newsql領域的tidb+tikv。

master-master

master-master架構服務也很多，日漸成為主流，目前低一致性的大數(shù)據(jù)系統(tǒng)幾乎都是多主架構，筆者對大數(shù)據(jù)不夠熟悉，這里只列一致性較強的一些數(shù)據(jù)庫系統(tǒng)

1. 傳統(tǒng)領域，oracle RAC，IBM purescale；
2. sharding中間件，很多互聯(lián)網(wǎng)公司都開發(fā)屬于自己的中間件，比如騰訊tdsql，阿里DRDS，中興GoldenDB，開源的方案也有很多，像pg-xc，pg-xl，mycat等等，中間件方案符合互聯(lián)網(wǎng)場景，技術門檻低，對用戶限制大；
3. fdw(foreign-data wrapper)，這也是一種類似sharding的方案，目前oracle和pg采用這種方案，將外部數(shù)據(jù)源直接映射為本地表，限制也很多，比如外部表的統(tǒng)計信息很難抽取等等；
4. mysql group replication，使用paxos作為復制協(xié)議，結合傳統(tǒng)數(shù)據(jù)庫做出了新的探索；
5. 類spanner架構，商業(yè)數(shù)據(jù)庫有spanner和oceanbase，開源數(shù)據(jù)庫有tidb和cockroach；

master-master架構的系統(tǒng)，總有數(shù)據(jù)是可以提供服務的，因此可靠性更高，這是當前分布式系統(tǒng)的主流方案。

paxos/raft

paxos/raft是當前主流的分布式復制協(xié)議。

paxos協(xié)議精確定義了在分布式系統(tǒng)下達成共識的最小條件。關于paxos的原理可以參考這篇文章《一步一步理解Paxos算法》。

paxos是分布式系統(tǒng)的核心之一，關于這個算法給予再多的贊譽也不為過。paxos協(xié)議有很多變種，他的應用也是有一些主要注意的地方，《SRE: google運維解密》內(nèi)23章討論了paxos應用的一些場景和情況，有興趣的可以了解一下。

一些工程可靠性手段

系統(tǒng)調用

什么樣的系統(tǒng)調用是可靠的？幾乎沒有，c語言中最容易出問題的系統(tǒng)調用就是malloc，因為使用的太廣泛了，在有些較深的代碼邏輯內(nèi)，一旦申請內(nèi)存出錯，處理相當棘手。在某個重要的內(nèi)閉的模塊中，首先申請足夠的內(nèi)存是一個比較好的做法，相當于半自管理的內(nèi)存。

其次容易出錯的系統(tǒng)調用是和IO相關的調用，比如IO調用出錯更難處理的是IO變慢，讀寫操作的速度在故障時是完全不不能有任何期待的，幾十秒，幾分鐘甚至更久都很正常，所以，如果自旋鎖內(nèi)包含一個IO操作，這個系統(tǒng)離崩潰就不遠了。

凡是跨網(wǎng)絡的操作，對網(wǎng)絡不要有任何期待，在操作前，釋放所有不必要持有的資源，并做好調用出錯的準備，并為其設定一個超時時間，改為異步模式是一個好選擇。

checksum

如果由于外部破壞或bug等原因導致數(shù)據(jù)損壞，可以通過checksum的方式探查，checksum一般在如下兩個時機應用：

數(shù)據(jù)刷盤時計算，并同時記錄到磁盤上；

數(shù)據(jù)讀取時校驗；

磁盤心跳/連接心跳

進程卡死是不可避免的，當系統(tǒng)cpu被占滿時，或者由于某些bug，可能導致某些關鍵進程得不到調度，導致其無法傳遞某些信息，某些故障可能對整個系統(tǒng)都是致命。

如何偵測進程/線程卡斯，有兩種常用的做法：

維護磁盤心跳，比如定期touch某個文件，如果長時間文件的時間戳沒有變化，表示該程序卡死；

提供接口供外部程序訪問，外部程序定期訪問該進程，如果長時間得不到回應，可以認為程序卡死；

對于bug導致的程序卡死，往往殺掉進程重新拉起可以解決。

調度/隊列/優(yōu)先級/流控

系統(tǒng)性能是很難做到線性提升的，對于數(shù)據(jù)庫來說，更是不可能，對于大部分數(shù)據(jù)庫系統(tǒng)來說，性能首先隨連接數(shù)增加而提升到某個點，繼續(xù)增加連接數(shù)，往往性能會下降，

上圖是mysql8.0.3 CATS特性的性能測試結果，明顯可以看到超過64連接后，性能隨著連接數(shù)增加而降低。

這也是數(shù)據(jù)庫系統(tǒng)一般都會做連接池的原因。

過量的壓力可能導致系統(tǒng)崩潰，比如上圖，F(xiàn)IFO的調度方式下，512連接，性能降低接近5倍。因此在大型系統(tǒng)中，連接池和優(yōu)先級隊列是一個好設計，可以方便對系統(tǒng)的壓力進行有效控制，同時通過監(jiān)控隊列長度，可以直觀看到這部分系統(tǒng)的壓力和處理能力。

異地備份

主流的高可用方案有兩種，一種是兩地三中心，一種是異地多活。

兩地三中心

對于傳統(tǒng)數(shù)據(jù)庫，兩地三中心的方案比較常見，常見的部署是同城兩中心，異地一中心

兩地三中心是一個初級和簡單的部署架構，一旦主庫發(fā)生故障，異地中心很難頂上，只能起到冷備的作用：

1. 一般而言，應用距離主庫較近，異地網(wǎng)絡延時大，性能往往不如主庫；
2. 異地中心往往較本地中心硬件條件差，無論是帶寬還是時延，未必滿足應用的需求；
3. 異地中心不能提供服務，浪費資源；
4. 如果不經(jīng)常做主備切換，一旦發(fā)生故障，往往異地中心會出現(xiàn)各種問題，上文中寧夏銀行在故障前一年就做過故障演練，但是一年不練，真的發(fā)生故障時，會出現(xiàn)各種問題。

還有一種共有云上可靠性更高的方案，如下圖

有錢任性。當然，公有云海量部署可以攤低成本，在私有云上，這種方案更貴。

paxos并不適合兩地三中心的部署，paxos協(xié)議要求有3個對等的故障域，并且能處理一個故障域的故障，兩地三中心故障域并不對等

同城復制快，異地復制慢，性能受很大影響；

同城兩中心在地質災害時會同時故障，paxos不能處理；

異地多活

異地多活方案主要要考慮如下幾個問題：

1. 系統(tǒng)資源分配在異地條件下是否存在問題；
2. 故障自閉，任意數(shù)據(jù)中心間斷網(wǎng)造成的區(qū)域隔斷是否會導致系統(tǒng)不可用，尤其注意當某個數(shù)據(jù)中心故障時，流控系統(tǒng)往往會立刻就將壓力導入到其他可用區(qū)域，可能會立刻導致系統(tǒng)過載；
3. 數(shù)據(jù)中心間數(shù)據(jù)同步性能是否可以滿足需要；

數(shù)據(jù)中心是及其昂貴的，一旦整個數(shù)據(jù)中心發(fā)生故障，作為服務整體服務質量不降級是不可能的，如何優(yōu)雅降級并保證盡可能多的數(shù)據(jù)可用，這是分布式系統(tǒng)需要重點考慮的問題。

以google spanner為例，時間戳分配是分布式的，不需要中心節(jié)點，數(shù)據(jù)可以由用戶選擇部署方式，橫跨數(shù)據(jù)中心越多，性能越差，可靠性越強，區(qū)域故障完全自閉，不影響其他部分。

異地多活是一項系統(tǒng)工程，在這個龐大工程里，數(shù)據(jù)庫只需要做好自己的事就可以了。

參考資料

《SRE: google運維解密》

來自 Google 的高可用架構理念與實踐

《the tail at scale》

Hard disk drive failure

CAP理論

The Log: What every software engineer should know about real-time data’s unifying abstraction

WAL Internals Of PostgreSQL

AWS re:Invent 2016: Getting Started with Amazon Aurora (DAT203)

一步一步理解Paxos算法

cloudharmony數(shù)據(jù)中心監(jiān)控