故障簡介

ACID是事務(wù)的四個(gè)特性型酥，其中D(Duration)就是講的持久性躬柬，數(shù)據(jù)庫的一大價(jià)值就在于可以有效處理的故障昧旨，保證數(shù)據(jù)不會(huì)丟失拾给。隨著分布式數(shù)據(jù)庫的發(fā)展，部署的復(fù)雜度上升兔沃，數(shù)據(jù)庫面臨的故障場景也越來越多蒋得。

常見硬件故障

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

常見數(shù)據(jù)中心故障概率表1.jpg

常見數(shù)據(jù)中心故障概率表2.jpg

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

網(wǎng)絡(luò)故障

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

1. 腦裂，顧名思義窍侧，腦裂指的是系統(tǒng)因?yàn)榫W(wǎng)絡(luò)故障被分割為多個(gè)獨(dú)立的區(qū)域县踢；
2. 多網(wǎng)面條件下，部分網(wǎng)面故障伟件，這個(gè)錯(cuò)誤一般是很難出現(xiàn)的硼啤，因?yàn)槊總€(gè)網(wǎng)面往往是邏輯的，并不和網(wǎng)卡綁定斧账，如果用戶調(diào)整配置出錯(cuò)谴返，可能導(dǎo)致這種故障，如果系統(tǒng)橫跨多個(gè)網(wǎng)面咧织，需要考慮這個(gè)故障嗓袱；

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

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

2017-11-22數(shù)據(jù)中心監(jiān)控.png

可以看到闪萄，即使大名鼎鼎的azure逼肯，也未能達(dá)到宣稱99.95%，有興趣的詳細(xì)了解的可以看這里

除此之外桃煎，再給大家舉幾個(gè)詳細(xì)的例子

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

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

2017年2月28日amazon s3故障

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

2016年4月13日Google Compute Engine停止服務(wù)

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

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

光纖挖斷后窟社，部分用戶無法使用，兩小時(shí)后恢復(fù)绪钥。

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

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

經(jīng)初步分析命雀，在季末結(jié)算業(yè)務(wù)量較大的情況下，因備份系統(tǒng)異常導(dǎo)致備份存儲(chǔ)磁盤讀寫處理嚴(yán)重延時(shí)斩箫，備份與主存儲(chǔ)數(shù)據(jù)不一致吏砂，在采取中斷數(shù)據(jù)備份錄像操作后，造成生產(chǎn)數(shù)據(jù)庫損壞并宕機(jī)乘客。因?qū)幭你y行應(yīng)急恢復(fù)處置機(jī)制嚴(yán)重缺失狐血，導(dǎo)致系統(tǒng)恢復(fù)工作進(jìn)展緩慢，直至7月3日5點(diǎn)40分核心系統(tǒng)才恢復(fù)服務(wù)易核，業(yè)務(wù)系統(tǒng)中斷長達(dá)37小時(shí)40分鐘匈织，其間完全依靠手工辦理業(yè)務(wù)。

故障分類

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

數(shù)據(jù)中心網(wǎng)絡(luò)互聯(lián).jpeg

圖上任何的硬件設(shè)備都可能發(fā)生故障牡直，從各個(gè)主機(jī)缀匕，交換機(jī)到網(wǎng)線。

我們嘗試以故障域?qū)收献鲆粋€(gè)簡單的分類碰逸。所謂故障域弦追，就是會(huì)因?yàn)橐粋€(gè)故障而同時(shí)不可用的一組組件，常見的故障域包括：

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

故障的變化

不同組件發(fā)生故障的概率是不同零远，google一項(xiàng)研究表明苗分，在36 °C和47 °C范圍內(nèi)運(yùn)轉(zhuǎn)的磁盤，故障率最低牵辣，隨著時(shí)間的發(fā)展摔癣，磁盤故障率也逐漸提升，第一年只有1.7%纬向，第三年達(dá)到8.6%择浊。

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

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

日志系統(tǒng)

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

看一下postgresql日志的結(jié)構(gòu)：

postgres日志結(jié)構(gòu).png

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

1. 物理日志拌消，上圖即物理日志，replay速度快安券，但是日志量大拼坎，實(shí)現(xiàn)邏輯相對簡單不易出錯(cuò)；
2. 邏輯日志完疫，replay速度相對慢泰鸡，日志量小，而且對于MVCC機(jī)制的數(shù)據(jù)庫有一個(gè)額外的好處壳鹤，備機(jī)可以單獨(dú)gc盛龄，和主機(jī)無關(guān)；

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

1. WAL原則芳誓，也就是日志刷盤要在頁面刷盤之前余舶，這里的刷盤，并非調(diào)用write就可以锹淌，還需要調(diào)用sync操作匿值。在合適時(shí)機(jī)，往往是事務(wù)提交時(shí)赂摆，將日志刷盤挟憔，并調(diào)用sync同步到磁盤钟些，以保證斷電時(shí)可以恢復(fù)數(shù)據(jù)。除了在事務(wù)提交時(shí)將日志刷盤绊谭，在涉及元數(shù)據(jù)操作時(shí)政恍，往往也會(huì)調(diào)用sync將數(shù)據(jù)刷盤，以保證元數(shù)據(jù)的一致达传。
2. 通過日志系統(tǒng)恢復(fù)篙耗，不僅僅需要一份完好的日志，還需要一份完整的（可以是落后的）數(shù)據(jù)作為起點(diǎn)宪赶。

日志系統(tǒng)是系統(tǒng)軟件內(nèi)廣泛使用的技術(shù)宗弯，不僅僅是數(shù)據(jù)庫，日志代表了系統(tǒng)的改變搂妻，他可以用來恢復(fù)/備份蒙保，也可以用做通知系統(tǒng)叽讳，掌握了系統(tǒng)的日志流岛蚤，就相當(dāng)于掌握了系統(tǒng)的整個(gè)狀態(tài)懈糯，日志可以更抽象的理解為日志+狀態(tài)機(jī)，通過不斷的重訪日志赚哗，改變狀態(tài)機(jī)的狀態(tài)，可以通過傳遞日志將狀態(tài)改變傳遞到整個(gè)系統(tǒng)的各個(gè)角落贿讹，關(guān)于日志系統(tǒng)，筆者見過的最好的一篇文章是The Log: What every software engineer should know about real-time data's unifying abstraction民褂，非常推薦一讀，日志即一切疯潭。

日志回收

日志代表了系統(tǒng)所有的變化赊堪，如果數(shù)據(jù)大小是從0開始擴(kuò)展到100G，那么日志至少也要有100G竖哩，甚至更多哭廉，而日志的增長和用戶做出的改動(dòng)是正相關(guān)，任何系統(tǒng)也無法存儲(chǔ)無限增長的日志相叁。
回收日志所占存儲(chǔ)空間是必然的選擇遵绰，日志收回有兩個(gè)好處：

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

實(shí)際上辽幌，對于MVCC機(jī)制實(shí)現(xiàn)的數(shù)據(jù)庫，因?yàn)槿罩净厥蘸褪聞?wù)提交沒有關(guān)系街立，所以可以嚴(yán)格的將日志控制在指定大小舶衬，為系統(tǒng)運(yùn)維提供方便。

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

checkpoint

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

1. 打點(diǎn)：記錄當(dāng)前日志位置码撰；
2. 將當(dāng)前系統(tǒng)內(nèi)所有內(nèi)存中的數(shù)據(jù)刷盤，并調(diào)用sync同步到磁盤个盆，此時(shí)仍要遵循WAL原則脖岛；
3. 寫checkpoint日志，或?qū)heckpoint信息作為元數(shù)據(jù)刷盤颊亮；
4. 回收checkpoint起始點(diǎn)之前的日志柴梆；

上面是常見的做checkpoint方式，這種方式也叫做全量檢查點(diǎn)(full checkpoint)终惑，這種方式實(shí)現(xiàn)簡單雹有，但是明顯checkpoint是一次IO峰值溜宽，會(huì)造成性能抖動(dòng)坑质。

還有一種做checkpoint的方式涡扼，叫做增量檢查點(diǎn)(incremental checkpoint)吃沪，過程如下：

1. 后臺(tái)寫進(jìn)程按照頁面第一次修改的順序刷盤红淡；
2. 打點(diǎn)：記錄當(dāng)前刷盤的頁面對應(yīng)的日志點(diǎn)在旱，寫checkpoint日志或者作為元數(shù)據(jù)刷盤桶蝎；

這種方式化checkpoint為后臺(tái)寫操作登渣，做checkpoint時(shí)只需要打點(diǎn)即可，消除了IO峰值仇味，有助于平穩(wěn)數(shù)據(jù)庫性能丹墨。

torn page

數(shù)據(jù)庫頁面大小和磁盤扇區(qū)大小往往不同昧碉，因此當(dāng)頁面刷盤時(shí)揽惹，如果系統(tǒng)斷電搪搏，可能只有部分頁面刷盤疯溺，這種現(xiàn)象囱嫩，我們稱之為torn page，這個(gè)頁面相當(dāng)于被徹底損壞郑口，而日志replay需要一份完整的數(shù)據(jù)做起點(diǎn)，此時(shí)是無法恢復(fù)的腾仅。

處理半寫有幾種方式：

1. innodb的double write推励，pg的full page write吹艇，這兩種方式原理是類似的，都是在頁面刷盤前鼻听，將頁面首先寫在其他地方撑碴，sync后醉拓，再覆蓋寫頁面亿卤。
2. 從備份恢復(fù)排吴，從備份單獨(dú)恢復(fù)某一個(gè)頁面。

這里有幾個(gè)例外:

1. 追加寫的系統(tǒng)沒有這個(gè)問題街氢；
2. 如果頁面大小和扇區(qū)大小相同珊肃，也沒有這個(gè)問題近范，很多元數(shù)據(jù)設(shè)計(jì)都會(huì)考慮這點(diǎn)叶堆；
3. 很多文件系統(tǒng)或分布式文件系統(tǒng)虱颗，raid卡忘渔，或者磁盤本身也可以處理這個(gè)故障畦粮，如果使用能自處理半寫故障的硬件宣赔，數(shù)據(jù)庫就可以不開啟這個(gè)功能儒将；

磁盤寫滿

磁盤寫滿這種問題只能通過運(yùn)維手段解決，因?yàn)閿?shù)據(jù)庫事務(wù)提交必須寫日志砰逻，如果無法寫日志诱渤，那么任何事務(wù)都不能提交，相當(dāng)于停庫碑韵，因此應(yīng)對磁盤故障一般是通過監(jiān)控，在磁盤空間即將不足時(shí)提前預(yù)警联喘。

磁盤損壞

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

備份

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

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

很顯然，從上述操作的開銷從大到小排列依次是割择，全量備份>增量備份>日志歸檔眷篇。數(shù)據(jù)庫運(yùn)維時(shí)往往會(huì)結(jié)合這三種方式，以達(dá)到縮小故障RPO的目標(biāo)荔泳。

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

多機(jī)熱備

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

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

很明顯赋咽，備機(jī)要根據(jù)故障域和客戶的要求米母，進(jìn)行反親和部署芍碧。

master-slave(-cascade)

master-slave.png

每個(gè)主機(jī)可以掛多個(gè)備機(jī)陨倡，每個(gè)備機(jī)可以掛多個(gè)級(jí)連備擎勘，這是當(dāng)前傳統(tǒng)數(shù)據(jù)庫的常見部署方式且蓬。postgres甚至支持多級(jí)的級(jí)連備（次級(jí)連）等等括授，但是不是很常用。這種部署方式可以有效的處理單機(jī)故障。作為支持只讀操作的備機(jī)，可以有效的分?jǐn)傋x負(fù)載，這是一種有延遲的讀操作产阱，本身也是滿足相應(yīng)隔離級(jí)別的构蹬，但是和主機(jī)放在一起考慮的話涎显，并沒有一致性可言。

事務(wù)提交時(shí)機(jī)

根據(jù)主機(jī)事務(wù)的提交時(shí)機(jī)莫瞬，有幾種事務(wù)提交級(jí)別：

1. 主機(jī)日志落盤，此時(shí)RTO<1min郭蕉，RPO>0
2. 主機(jī)日志落盤疼邀，同時(shí)主機(jī)日志發(fā)送到備機(jī)，此時(shí)RTO<1min召锈，RPO=0
3. 主機(jī)日志落盤旁振，同時(shí)主機(jī)日志發(fā)送到備機(jī)，并且落盤涨岁，此時(shí)RTO<1min拐袜，RPO=0

這三種提交級(jí)別，主機(jī)性能越來越差梢薪，一般而言蹬铺，同城備機(jī)采用第二種方式，異地備機(jī)使用第一種方式秉撇。

共享磁盤

share-disk.png

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

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

技術(shù)是螺旋式前進(jìn)的，在分布式計(jì)算中墨榄，share disk的思想也很流行玄糟，很多系統(tǒng)依賴分布式文件系統(tǒng)/存儲(chǔ)系統(tǒng)，在其上構(gòu)建基于share disk的計(jì)算系統(tǒng)袄秩，比如大數(shù)據(jù)領(lǐng)域久負(fù)盛名的hadoop阵翎，還有OLTP領(lǐng)域的新力量aurora，還有newsql領(lǐng)域的tidb+tikv之剧。

tidb-architecture.png

aurora architecture.jpg

master-master

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

1. 傳統(tǒng)領(lǐng)域，oracle RAC蟹肘，IBM purescale词疼；
2. sharding中間件，很多互聯(lián)網(wǎng)公司都開發(fā)屬于自己的中間件帘腹，比如騰訊tdsql贰盗，阿里DRDS，中興GoldenDB阳欲，開源的方案也有很多舵盈，像pg-xc，pg-xl球化，mycat等等秽晚，中間件方案符合互聯(lián)網(wǎng)場景，技術(shù)門檻低赊窥，對用戶限制大爆惧；
3. fdw(foreign-data wrapper)，這也是一種類似sharding的方案锨能，目前oracle和pg采用這種方案扯再，將外部數(shù)據(jù)源直接映射為本地表，限制也很多址遇，比如外部表的統(tǒng)計(jì)信息很難抽取等等熄阻；
4. mysql group replication，使用paxos作為復(fù)制協(xié)議倔约，結(jié)合傳統(tǒng)數(shù)據(jù)庫做出了新的探索秃殉；
5. 類spanner架構(gòu)，商業(yè)數(shù)據(jù)庫有spanner和oceanbase，開源數(shù)據(jù)庫有tidb和cockroach钾军；

master-master架構(gòu)的系統(tǒng)鳄袍，總有數(shù)據(jù)是可以提供服務(wù)的，因此可靠性更高吏恭，這是當(dāng)前分布式系統(tǒng)的主流方案拗小。

paxos/raft

paxos.png

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

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

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

一些工程可靠性手段

系統(tǒng)調(diào)用

什么樣的系統(tǒng)調(diào)用是可靠的？幾乎沒有琢融，c語言中最容易出問題的系統(tǒng)調(diào)用就是malloc界牡，因?yàn)槭褂玫奶珡V泛了簿寂，在有些較深的代碼邏輯內(nèi)漾抬，一旦申請內(nèi)存出錯(cuò)，處理相當(dāng)棘手常遂。在某個(gè)重要的內(nèi)閉的模塊中纳令，首先申請足夠的內(nèi)存是一個(gè)比較好的做法，相當(dāng)于半自管理的內(nèi)存克胳。

其次容易出錯(cuò)的系統(tǒng)調(diào)用是和IO相關(guān)的調(diào)用平绩，比如IO調(diào)用出錯(cuò)更難處理的是IO變慢，讀寫操作的速度在故障時(shí)是完全不不能有任何期待的漠另，幾十秒捏雌，幾分鐘甚至更久都很正常，所以笆搓，如果自旋鎖內(nèi)包含一個(gè)IO操作性湿，這個(gè)系統(tǒng)離崩潰就不遠(yuǎn)了。

凡是跨網(wǎng)絡(luò)的操作满败，對網(wǎng)絡(luò)不要有任何期待肤频，在操作前，釋放所有不必要持有的資源算墨，并做好調(diào)用出錯(cuò)的準(zhǔn)備宵荒，并為其設(shè)定一個(gè)超時(shí)時(shí)間，改為異步模式是一個(gè)好選擇。

checksum

如果由于外部破壞或bug等原因?qū)е聰?shù)據(jù)損壞报咳，可以通過checksum的方式探查侠讯，checksum一般在如下兩個(gè)時(shí)機(jī)應(yīng)用：

1. 數(shù)據(jù)刷盤時(shí)計(jì)算，并同時(shí)記錄到磁盤上暑刃；
2. 數(shù)據(jù)讀取時(shí)校驗(yàn)继低；

磁盤心跳/連接心跳

進(jìn)程卡死是不可避免的，當(dāng)系統(tǒng)cpu被占滿時(shí)稍走，或者由于某些bug袁翁，可能導(dǎo)致某些關(guān)鍵進(jìn)程得不到調(diào)度，導(dǎo)致其無法傳遞某些信息婿脸，某些故障可能對整個(gè)系統(tǒng)都是致命粱胜。

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

1. 維護(hù)磁盤心跳狐树，比如定期touch某個(gè)文件焙压，如果長時(shí)間文件的時(shí)間戳沒有變化，表示該程序卡死抑钟；
2. 提供接口供外部程序訪問涯曲，外部程序定期訪問該進(jìn)程，如果長時(shí)間得不到回應(yīng)在塔，可以認(rèn)為程序卡死幻件；

對于bug導(dǎo)致的程序卡死，往往殺掉進(jìn)程重新拉起可以解決蛔溃。

調(diào)度/隊(duì)列/優(yōu)先級(jí)/流控

系統(tǒng)性能是很難做到線性提升的绰沥，對于數(shù)據(jù)庫來說，更是不可能贺待，對于大部分?jǐn)?shù)據(jù)庫系統(tǒng)來說徽曲，性能首先隨連接數(shù)增加而提升到某個(gè)點(diǎn)，繼續(xù)增加連接數(shù)麸塞，往往性能會(huì)下降秃臣，

CATS performance.png

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

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

過量的壓力可能導(dǎo)致系統(tǒng)崩潰正勒，比如上圖得院，F(xiàn)IFO的調(diào)度方式下，512連接章贞，性能降低接近5倍祥绞。因此在大型系統(tǒng)中非洲，連接池和優(yōu)先級(jí)隊(duì)列是一個(gè)好設(shè)計(jì)，可以方便對系統(tǒng)的壓力進(jìn)行有效控制蜕径，同時(shí)通過監(jiān)控隊(duì)列長度两踏，可以直觀看到這部分系統(tǒng)的壓力和處理能力。

異地備份

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

兩地三中心

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

數(shù)據(jù)庫兩地三中心方案.jpeg

? （TDSQL部署示意圖）

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

1. 一般而言扒接，應(yīng)用距離主庫較近伪货，異地網(wǎng)絡(luò)延時(shí)大，性能往往不如主庫钾怔；
2. 異地中心往往較本地中心硬件條件差碱呼，無論是帶寬還是時(shí)延，未必滿足應(yīng)用的需求宗侦；
3. 異地中心不能提供服務(wù)愚臀，浪費(fèi)資源；
4. 如果不經(jīng)常做主備切換凝垛，一旦發(fā)生故障懊悯，往往異地中心會(huì)出現(xiàn)各種問題，上文中寧夏銀行在故障前一年就做過故障演練梦皮，但是一年不練，真的發(fā)生故障時(shí)桃焕，會(huì)出現(xiàn)各種問題剑肯。

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

阿里云兩地三中心.png

有錢任性观堂。當(dāng)然让网，公有云海量部署可以攤低成本，在私有云上师痕，這種方案更貴溃睹。

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

1. 同城復(fù)制快，異地復(fù)制慢，性能受很大影響竞滓；
2. 同城兩中心在地質(zhì)災(zāi)害時(shí)會(huì)同時(shí)故障咐吼，paxos不能處理；

異地多活

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

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

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

google spanner.jpg

以google spanner為例涣易，時(shí)間戳分配是分布式的画机，不需要中心節(jié)點(diǎn)，數(shù)據(jù)可以由用戶選擇部署方式新症，橫跨數(shù)據(jù)中心越多步氏，性能越差，可靠性越強(qiáng)徒爹，區(qū)域故障完全自閉荚醒，不影響其他部分。

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

參考資料

1. 《SRE: google運(yùn)維解密》
2. 來自 Google 的高可用架構(gòu)理念與實(shí)踐
3. 《the tail at scale》
4. Hard disk drive failure
5. CAP理論
6. The Log: What every software engineer should know about real-time data's unifying abstraction
7. WAL Internals Of PostgreSQL
8. AWS re:Invent 2016: Getting Started with Amazon Aurora (DAT203)
9. 一步一步理解Paxos算法
10. cloudharmony數(shù)據(jù)中心監(jiān)控

廣告

最后踊沸，打個(gè)廣告京腥，如果對創(chuàng)業(yè)彻舰，分布式數(shù)據(jù)庫和開源社區(qū)感興趣蚓哩，歡迎加入pingcap帖汞，實(shí)習(xí)和工作都很歡迎纬朝！
Email: xuwentao@pingcap.com
微信: fbisland

pingcap是國內(nèi)為數(shù)不多的newsql方向的分布式數(shù)據(jù)庫个绍，維護(hù)國內(nèi)最頂級(jí)的開源社區(qū)技健，關(guān)注度近萬写穴，目前已在騰訊云和ucloud上線，做類f1+spanner架構(gòu)雌贱，和多家公司有合作關(guān)系啊送。
TiDB: https://github.com/pingcap/tidb
TiKV: https://github.com/pingcap/tikv