在過去十多年在Oracle，騰訊等公司的數(shù)據(jù)庫系統(tǒng)內(nèi)核開發(fā)工作中，我的大量工作就是確保數(shù)據(jù)庫系統(tǒng)在各種環(huán)境故障情況下，能夠保持數(shù)據(jù)一致性和持續(xù)可用地提供數(shù)據(jù)讀寫服務(wù)。這些工作既包括在騰訊參與開發(fā)的TDSQL 分布式數(shù)據(jù)庫，也包括過去的近一年我開發(fā)的昆侖分布式數(shù)據(jù)庫。

過去3個多月我花了大量時間精力解決了昆侖數(shù)據(jù)庫使用的存儲節(jié)點的容災(zāi)問題。昆侖分布式數(shù)據(jù)庫使用我改進后的Percona-MySQL-8.0.18-9，我將它命名為Kunlun-Percona-MySQL-8.0.18-9。官方版本的Percona-MySQL-8.0.18-9的group replication和分布式事務(wù)處理（即XA）有很多個容災(zāi)能力方面的缺陷，這些缺陷有一些是在mysql-5.7時代就已經(jīng)存在的了---當時我在騰訊做TDSQL分布式事務(wù)處理功能開發(fā)的時候修復(fù)了這些bug并報告給了mysql官方團隊。很遺憾mysql官方并沒有修復(fù)全部的這些bug，多數(shù)關(guān)鍵的bug仍然在mysql8.0存在，盡管我在每個bug報告中都提供了我的patch。

在Kunlun-Percona-MySQL-8.0.18-9中，我的改進填補了MGR在處理XA事務(wù)方面的諸多缺陷和空白。在本文中，我希望基于過往工作歷程中積累的經(jīng)驗，給讀者分享一下我對分布式數(shù)據(jù)庫系統(tǒng)的容災(zāi)能力和需求的理解，并介紹Kunlun-Percona-MySQL-8.0.18-9修復(fù)的容災(zāi)缺陷。

本文內(nèi)容包括數(shù)據(jù)庫系統(tǒng)需要應(yīng)對的故障（即災(zāi)難）類型和環(huán)境可靠性模型，災(zāi)難可能造成的損害，以及容災(zāi)的方法和手段，包括數(shù)據(jù)庫事務(wù)處理，數(shù)據(jù)備份和恢復(fù)，數(shù)據(jù)復(fù)制與高可用性，兩階段提交和分布式事務(wù)處理等數(shù)據(jù)庫容災(zāi)相關(guān)的內(nèi)容。

本文不含蓋或者針對特定的數(shù)據(jù)模型（比如關(guān)系模型）和查詢語言（比如SQL），因此本文內(nèi)容對于關(guān)系數(shù)據(jù)庫管理系統(tǒng)，json/xml 數(shù)據(jù)庫管理系統(tǒng)，對象數(shù)據(jù)庫管理系統(tǒng)，key-value數(shù)據(jù)庫管理系統(tǒng)和圖數(shù)據(jù)庫管理系統(tǒng)都適用。

分布式數(shù)據(jù)庫系統(tǒng)的環(huán)境可靠性模型

生產(chǎn)中運行的分布式數(shù)據(jù)庫集群通常由運行在一個或者多個數(shù)據(jù)中心的計算機服務(wù)器聯(lián)網(wǎng)構(gòu)成，這些計算機服務(wù)器硬件以及網(wǎng)絡(luò)，以及硬件和網(wǎng)絡(luò)中運行的軟件，以及操作所有這些軟硬件的人員執(zhí)行的操作和行為，就是分布式數(shù)據(jù)庫集群運行的環(huán)境。這個環(huán)境可能出現(xiàn)的錯誤和故障就是分布式數(shù)據(jù)庫系統(tǒng)需要處理的故障來源。

集群中任何節(jié)點的軟硬件故障，或者任何節(jié)點之間的網(wǎng)絡(luò)連接故障，都可能影響集群的正常工作。由于其天然的復(fù)雜性，這個環(huán)境發(fā)生故障的幾率并不低，因此分布式數(shù)據(jù)庫系統(tǒng)需要將節(jié)點軟硬件故障和網(wǎng)絡(luò)故障當作常見情況來處理，而不是當作極低概率的事件來處理。

分布式數(shù)據(jù)庫集群需要處理的軟件環(huán)境故障包括計算機服務(wù)器的操作系統(tǒng)自身的bug導(dǎo)致的工作故障和系統(tǒng)管理員人為錯誤導(dǎo)致的運行錯誤等，還包括網(wǎng)絡(luò)節(jié)點的控制軟件自身的bug以及網(wǎng)絡(luò)管理員人為錯誤導(dǎo)致的網(wǎng)絡(luò)連接故障，以及數(shù)據(jù)庫操作人員使用和管理分布式數(shù)據(jù)庫集群時誤操作導(dǎo)致的分布式數(shù)據(jù)庫集群節(jié)點故障等，比如誤殺進程，誤刪數(shù)據(jù)文件等；需要處理的硬件環(huán)境故障包括服務(wù)器或者網(wǎng)絡(luò)設(shè)備短暫斷電，服務(wù)器的持久存儲設(shè)備損壞，服務(wù)器短暫重啟，服務(wù)器硬件永久損壞或者停止工作，以及部分或者全部網(wǎng)絡(luò)連接短暫失效和長期失效等。

容災(zāi)能力對于一個數(shù)據(jù)庫系統(tǒng)來說是非常關(guān)鍵的能力，特別是對于分布式數(shù)據(jù)庫集群來說，其多節(jié)點的架構(gòu)導(dǎo)致構(gòu)成集群的軟硬件和網(wǎng)絡(luò)發(fā)生故障的幾率更高，因此必須有絕對可靠的容災(zāi)能力，確保在任何節(jié)點發(fā)生軟硬件故障情況下都不會導(dǎo)致數(shù)據(jù)一致性問題，或者丟失已提交的事務(wù)的改動，或者導(dǎo)致系統(tǒng)不可用。為了展現(xiàn)不同規(guī)模的分布式數(shù)據(jù)庫集群環(huán)境故障幾率，下面我們就量化上述故障的概率。

首選我們定義分布式數(shù)據(jù)庫的‘集群環(huán)境可靠性’為組成該集群的軟硬件節(jié)點及其間的網(wǎng)絡(luò)連接都不發(fā)生故障的概率。然后我們計算在不同的集群規(guī)模和軟硬件預(yù)期可靠性情況下這個‘集群環(huán)境可靠性’的值。

以昆侖分布式數(shù)據(jù)庫集群或者TDSQL分布式數(shù)據(jù)庫集群為例，假設(shè)集群有 N個存儲shard，每個shard一主兩備，同時還有N個計算節(jié)點與每個shard的主節(jié)點相連接。每個存儲和計算節(jié)點運行在獨立的硬件計算機上面；同時這些節(jié)點之間還有至少2*N+N*N條網(wǎng)絡(luò)連接（不考慮讀備機的情況下）。這樣一共有N*N+6*N 個可能發(fā)生故障的點。我們假設(shè)每個點在一定時間范圍內(nèi)，比如1個月內(nèi)，可以以一個穩(wěn)定的概率保持正常工作。在這個時間范圍內(nèi)只要集群中有1個節(jié)點發(fā)生了故障，就認定集群環(huán)境就發(fā)生了故障。這樣就可以計算在一定時間范圍內(nèi)集群環(huán)境的可靠性概率。表1顯示了在不同的N和單個點可靠性情況下‘集群環(huán)境可靠性’。

從這個表中可以看出，對于一個分布式數(shù)據(jù)庫集群來說，在時間足夠長（比如一年），范圍足夠廣（比如有多個集群）的情況下，某個集群環(huán)境出現(xiàn)故障的幾率很大，隨著時間不斷增長，這個概率是趨近100%的。假如分布式數(shù)據(jù)庫集群沒有滴水不漏的毫無破綻的容災(zāi)能力的話，那么在實際生產(chǎn)中分布式數(shù)據(jù)庫集群長期不出現(xiàn)系統(tǒng)故障或者數(shù)據(jù)一致性錯誤幾乎是不可能的。

不同的分布式數(shù)據(jù)庫集群的總可能故障點數(shù)計算方法未必完全相同，但是肯定時隨著N的增加而增加的，集群環(huán)境可靠性隨著時間的增長以及N的增大而降低也是必然的，因此無論對于哪一種分布式數(shù)據(jù)庫，都會有類似的結(jié)論。可見分布式數(shù)據(jù)庫集群必須具備完備的堅不可摧的容災(zāi)能力，否則一定會出現(xiàn)數(shù)據(jù)不一致，數(shù)據(jù)損壞丟失或者數(shù)據(jù)庫服務(wù)停止等嚴重的問題。

另外想提一下，上面的統(tǒng)計雖然用昆侖分布式數(shù)據(jù)庫和TDSQL做比較，但事實上對于TDSQL分布式數(shù)據(jù)庫集群來說，集群還需要一個zookeeper集群來存儲集群關(guān)鍵元數(shù)據(jù)，而且通常這個zookeeper集群會有多個TDSQL集群共享。zookeeper集群軟硬件和網(wǎng)絡(luò)也是一組可能的故障來源，并且一旦故障會導(dǎo)致所有使用該zookeeper集群的TDSQL集群不能正常工作，甚至發(fā)生數(shù)據(jù)一致性錯誤或者丟失已提交的事務(wù)。但是上述環(huán)境可靠性概率計算并沒有考慮zookeeper集群的故障可能性，否則其值會更快趨近于0。所以zookeeper也必須要有非常可靠的容災(zāi)能力才行。

下面我們回顧一下數(shù)據(jù)庫管理系統(tǒng)（DBMS）發(fā)展的50多年以來，在不同的發(fā)展階段所面臨的災(zāi)難或者故障類型，故障的可能損害以及故障處理的方法。

不同時代的數(shù)據(jù)庫管理系統(tǒng)面對的災(zāi)難的范圍和容災(zāi)需求

經(jīng)典數(shù)據(jù)庫時代（單機）

單機數(shù)據(jù)庫時代，DBMS實現(xiàn)了單機數(shù)據(jù)庫事務(wù)處理，和單機事務(wù)的ACID保障。不過一旦數(shù)據(jù)庫服務(wù)器故障，則數(shù)據(jù)庫服務(wù)會停止，直到故障被排除，數(shù)據(jù)庫服務(wù)器重新啟動。

需要應(yīng)對的災(zāi)難

硬件故障：

1. 數(shù)據(jù)庫服務(wù)器硬件部件損壞；

2. 服務(wù)器斷電或者其他原因?qū)е路?wù)器在數(shù)據(jù)庫服務(wù)器運行期間退出

3. 數(shù)據(jù)文件所在的存儲介質(zhì)損壞或丟失

軟件故障：

1. 操作系統(tǒng)bug或者人為錯誤導(dǎo)致操作系統(tǒng)異常退出，或者系統(tǒng)調(diào)用失敗

2. 軟件bug或者人為錯誤導(dǎo)致DBMS進程異常退出（也就是DBMS進程crash，被kill掉等情況）

3. 寫入存儲介質(zhì)或者從其中讀出的頁面數(shù)據(jù)錯誤

可能產(chǎn)生的錯誤

1. 已提交的事務(wù)的數(shù)據(jù)或者修改丟失

2. 數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)文件不可用導(dǎo)致數(shù)據(jù)全部或者部分丟失

3. 沒有直接修改DBMS的數(shù)據(jù)文件的情況下，其數(shù)據(jù)文件的內(nèi)容損壞導(dǎo)致無法被 數(shù)據(jù)庫服務(wù)器程序使用，從而丟失部分或者全部數(shù)據(jù)

對容災(zāi)能力的要求

1．如果存儲介質(zhì)未損壞，那么數(shù)據(jù)庫服務(wù)器進程可以正常重新啟動，并且重新啟動后，所有已提交的事務(wù)的修改不丟失（durability），可以正常使用。

2．能夠確保DBMS不會在任何情況下?lián)p壞其數(shù)據(jù)文件（首選），或者損壞后可以完全修復(fù)（比如mysql myisam引擎的repair工具）其數(shù)據(jù)文件。

3．能夠發(fā)現(xiàn)數(shù)據(jù)文件頁面的發(fā)生的數(shù)據(jù)錯誤并報告給數(shù)據(jù)庫管理員，以便DBA使用備份的數(shù)據(jù)來恢復(fù)數(shù)據(jù)文件到最新備份的版本。

容災(zāi)能力的實現(xiàn)方法

單機數(shù)據(jù)庫實現(xiàn)容災(zāi)能力最重要的方法就是經(jīng)典的數(shù)據(jù)庫事務(wù)處理技術(shù)，也就是write ahead logging（WAL）。通過為每個事務(wù)記錄redo log和undo log，在數(shù)據(jù)庫服務(wù)器啟動時使用redo log做事務(wù)恢復(fù)，使用undo log回滾掉未提交的事務(wù)。刷任何數(shù)據(jù)頁面P到數(shù)據(jù)文件之前必須將記錄了修改這個頁面的redo日志R先刷到事務(wù)日志文件。并且日志R與頁面P通過P頭部的lsn關(guān)聯(lián)起來，即P.lsn = R.lsn，這樣恢復(fù)機制就可以把每一個數(shù)據(jù)頁面恢復(fù)到系統(tǒng)上次退出前最后一次刷redo log時的狀態(tài)。 同時，在回滾段中記錄每個修改了的數(shù)據(jù)行的前鏡像變動（before image delta），也就是使用當前行數(shù)據(jù)得到修改之前的行數(shù)據(jù)的變化。這樣數(shù)據(jù)庫恢復(fù)機制就可以恢復(fù)已提交的事務(wù)，并回滾問提交的事務(wù)。

為了應(yīng)對存儲介質(zhì)損壞和丟失，以及數(shù)據(jù)文件頁面發(fā)生數(shù)據(jù)錯誤，DBMS需要發(fā)現(xiàn)并報告這樣的數(shù)據(jù)錯誤，以便DBA使用最新的全量備份和增量備份恢復(fù)到最新備份的一致的數(shù)據(jù)版本。

單機數(shù)據(jù)庫時代一旦服務(wù)器軟硬件故障則數(shù)據(jù)庫服務(wù)就會在一段時間內(nèi)不可用。為了解決這個問題，在上世紀90年代開始業(yè)界逐步進入了高可用(high availability, HA) 時代。通過建立主備節(jié)點集群，從主節(jié)點持續(xù)傳輸對數(shù)據(jù)的增刪改操作數(shù)據(jù)到備機節(jié)點并在備機實施這些操作，就可以將同樣的數(shù)據(jù)存儲多個copy到多個備機節(jié)點上面。一旦主節(jié)點發(fā)生故障無法工作，具備HA 能力的DBMS可以自動發(fā)現(xiàn)主節(jié)點故障并把合適的備機節(jié)點升級為新的主節(jié)點，從而不間斷數(shù)據(jù)讀寫服務(wù)。

不過HA時代由于引入了更多的計算機服務(wù)器和網(wǎng)絡(luò)來構(gòu)成集群，因而可能出現(xiàn)故障的點也更多了，也就需要處理更多的故障情形。

（未完待續(xù)）

總結(jié)

以上是生活随笔為你收集整理的数据库表的软硬关联_数据库容灾能力的探讨（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。