故障簡介

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

常見硬件故障

接下來，我們看下常見數據中心的故障概率

[[229900]]

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

網絡故障

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

腦裂，顧名思義，腦裂指的是系統因為網絡故障被分割為多個獨立的區域；

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

脆弱的數據中心

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

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

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

2017年9月29日 azure北歐數據中心故障

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

2017年2月28日amazon s3故障

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

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

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

2015年5月27日 杭州電信挖斷阿里網線

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

2014年7月1日 寧夏銀行核心數據庫系統故障

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

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

故障分類

看一下數據中心網絡的互聯圖

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

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

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

故障的變化

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

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

數據庫故障處理

日志系統

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

看一下postgresql日志的結構：

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

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

數據庫日志系統有兩個重要的原理：

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

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

日志回收

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

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

1. 減少日志占據磁盤空間
2. 降低系統恢復需要的時間

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

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

checkpoint

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

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

將當前系統內所有內存中的數據刷盤，并調用sync同步到磁盤，此時仍要遵循WAL原則；

寫checkpoint日志，或將checkpoint信息作為元數據刷盤；

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

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

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

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

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

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

torn page

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

處理半寫有幾種方式：

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

這里有幾個例外:

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

磁盤寫滿

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

磁盤損壞

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

備份

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

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

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

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

多機熱備

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

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

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

master-slave(-cascade)

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

事務提交時機

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

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

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

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

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

共享磁盤

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

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

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

master-master

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

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

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

paxos/raft

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

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

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

一些工程可靠性手段

系統調用

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

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

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

checksum

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

數據刷盤時計算，并同時記錄到磁盤上；

數據讀取時校驗；

磁盤心跳/連接心跳

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

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

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

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

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

調度/隊列/優先級/流控

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

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

這也是數據庫系統一般都會做連接池的原因。

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

異地備份

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

兩地三中心

對于傳統數據庫，兩地三中心的方案比較常見，常見的部署是同城兩中心，異地一中心

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

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

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

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

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

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

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

異地多活

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

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

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

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

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

參考資料

《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數據中心監控