|
我常常在想，如果數(shù)據(jù)庫不用考慮數(shù)據(jù)恢復(fù)，對(duì)我們這些做數(shù)據(jù)庫的人來說，日子也許將變過美好很多。
沒有一種軟件會(huì)象數(shù)據(jù)庫這樣，需要面對(duì)如此惡劣的環(huán)境。你需要考慮各種可能的錯(cuò)誤和故障，例如系統(tǒng)斷電、磁盤損壞、甚至是地震火災(zāi)。而給你的目標(biāo)非常明確：不論發(fā)生何種故障，數(shù)據(jù)都不能被丟失，你可能覺得這有些小題大做，可對(duì)于許多商業(yè)應(yīng)用（如銀行、火車訂票系統(tǒng)等）來說，這只不過是最基本的要求。
要保證每一步操作都不會(huì)丟失，既無必要，也無可能（除非你能發(fā)明一種和硬盤一樣大，和內(nèi)存一樣快，同時(shí)斷電時(shí)數(shù)據(jù)不丟失的東東）。因此同并發(fā)控制中一樣，數(shù)據(jù)庫同樣也利用了事務(wù)的概念。事務(wù)是這樣一組操作，這組操作要么都做，要么都不做（我們通常把這叫做事務(wù)的原子性）。而當(dāng)你決定結(jié)束一個(gè)事務(wù)時(shí)，你可能會(huì)選擇：是提交（COMMIT）這個(gè)事務(wù)，還是應(yīng)該滾回（ROLLBACK）它。如果你選擇提交，那么你在這個(gè)事務(wù)中所做的全部修改都會(huì)被存入數(shù)據(jù)庫中，如果這個(gè)數(shù)據(jù)庫系統(tǒng)足夠強(qiáng)壯，它將保證：只要事務(wù)提交完成，不管今后發(fā)生何種故障，事務(wù)所做的修改都不會(huì)丟失。如果你選擇滾回，那么系統(tǒng)將回到事務(wù)開始的狀態(tài)，你在該事務(wù)中所做的所有修改都將丟失。如果在事務(wù)運(yùn)行當(dāng)中，系統(tǒng)發(fā)生了任何故障，你會(huì)期望它的結(jié)果應(yīng)該和你滾回這個(gè)事務(wù)一樣。
恢復(fù)的本質(zhì)是數(shù)據(jù)的冗余，在眾多的冗余手段中，日志（log）也許是我們最常使用的技術(shù)（盡管我們還有許多其它的選擇，如影子頁面等）。在我們對(duì)數(shù)據(jù)庫進(jìn)行修改之前，系統(tǒng)會(huì)將數(shù)據(jù)修改前的影象（前項(xiàng)）和你要修改的數(shù)據(jù)影象（后項(xiàng)）保存在日志當(dāng)中。在這個(gè)過程中，有兩點(diǎn)需要保證。一是日志必須先于它對(duì)應(yīng)的修改被寫入數(shù)據(jù)庫，我們把這叫做先寫日志（WAL）協(xié)議，這很容易理解，想象一下，如果修改被先寫入數(shù)據(jù)庫，而系統(tǒng)在日志被寫入之前崩潰了，那么它將無法把該事務(wù)恢復(fù)到開始的狀態(tài)。二是在事務(wù)提交之前，必須將它的日志寫入數(shù)據(jù)庫。否則，系統(tǒng)無法保證后續(xù)的故障不會(huì)丟失該事務(wù)的修改。我們將不能實(shí)現(xiàn)我們?cè)谇懊鎸?duì)用戶所做出的承諾。
我們繼續(xù)上文的討論，看看我們到底有哪些故障需要應(yīng)付。
首先是應(yīng)用故障，例如用戶不小心錯(cuò)刪了一張表，或者應(yīng)用破壞了完整性約束。這種故障的恢復(fù)非常簡單，對(duì)于前者，你可以顯式地滾回事務(wù)（利用日志的前項(xiàng)），如果你不小心提交了事務(wù)，那么問題就麻煩了，系統(tǒng)也許只能把它當(dāng)作介質(zhì)故障（利用備份）來恢復(fù)了；對(duì)于后者，系統(tǒng)會(huì)強(qiáng)迫把該事務(wù)滾回。只要數(shù)據(jù)庫還在運(yùn)行，在系統(tǒng)看來，事務(wù)的滾回與其它正常操作并沒有什么區(qū)別。
然后是進(jìn)程故障，假如在系統(tǒng)運(yùn)行時(shí)，一個(gè)client崩潰了，或者網(wǎng)絡(luò)斷了（通常服務(wù)器無法區(qū)別這兩種狀態(tài)）；或者服務(wù)器端的某個(gè)進(jìn)程死了。這時(shí)我們恐怕得為系統(tǒng)配置一個(gè)監(jiān)視進(jìn)程，由它來定期地檢查系統(tǒng)狀態(tài)，恢復(fù)或清除失敗的進(jìn)程（連接），同時(shí)把對(duì)應(yīng)的事務(wù)滾回。我們會(huì)希望這個(gè)監(jiān)視進(jìn)程是所有進(jìn)程的父進(jìn)程，因此假設(shè)連它也死了，我們就能把這種情況歸結(jié)到后面將要討論的系統(tǒng)故障。
接著是系統(tǒng)故障，假如系統(tǒng)因?yàn)閮?nèi)部錯(cuò)誤（例如數(shù)據(jù)庫或操作系統(tǒng)含有bug），或者發(fā)生斷電。這時(shí)緩沖區(qū)里的數(shù)據(jù)全部丟失，但幸運(yùn)地是磁盤上的數(shù)據(jù)還在。因此系統(tǒng)在重新啟動(dòng)（RESTART）后，首先重做所有事務(wù)的修改（利用日志的后項(xiàng)），這就讓數(shù)據(jù)庫回到了發(fā)生故障時(shí)的狀態(tài)，這時(shí)再將所有在這一點(diǎn)上未提交的事務(wù)滾回就完事了。注意這一過程是自動(dòng)完成的，你完全不需要去關(guān)心它。
再接著是介質(zhì)故障，假如磁盤出現(xiàn)了壞磁道，或者整個(gè)磁盤報(bào)銷了。這時(shí)上面的數(shù)據(jù)肯定已經(jīng)丟失了。由于介質(zhì)故障只能在你試圖再次存取磁盤時(shí)被發(fā)現(xiàn)，而這時(shí)故障可能早已發(fā)生。因此對(duì)介質(zhì)故障的恢復(fù)需要你的參與才能完成。你必須定期地備份（BACKUP）數(shù)據(jù)庫，這樣，當(dāng)介質(zhì)故障發(fā)生時(shí)，你可以先用備份重新覆蓋整個(gè)數(shù)據(jù)庫（RESTORE過程），然后利用日志重做從備份那點(diǎn)到當(dāng)前的數(shù)據(jù)庫的更新（ROLL-FORWARD過程），接下來的事情就和系統(tǒng)故障完全一樣了。你可能會(huì)問，那要是日志也壞了怎么辦呢？沒辦法，雞生蛋、蛋生雞，總得有個(gè)頭吧。所以你最好祈禱日志不要壞，為了保證這一點(diǎn)，你應(yīng)該對(duì)日志文件進(jìn)行鏡象，或者干脆用RAID。
除了這種恢復(fù)方式，我們還有一種叫做邏輯恢復(fù)的方式，也就是利用我們常常在用的IMPROT/EXPORT工具對(duì)數(shù)據(jù)進(jìn)行備份/恢復(fù)。當(dāng)然我們只把它看作是介質(zhì)故障恢復(fù)的一種輔助形式（也許它更適合于恢復(fù)我們前面說的那種應(yīng)用故障），因?yàn)槟阒荒馨褦?shù)據(jù)恢復(fù)到你備份的那一點(diǎn)。
最后是災(zāi)難，象發(fā)火災(zāi)、被人黑了什么的，這時(shí)整個(gè)系統(tǒng)可能被完全破壞。你當(dāng)然仍然可以對(duì)數(shù)據(jù)庫進(jìn)行備份，然后把備份（磁盤）放到另一個(gè)安全的地方，但這樣做，備份以后數(shù)據(jù)庫所做的修改可能就永久丟失了。一個(gè)更為穩(wěn)妥的辦法是我們?cè)谶h(yuǎn)程建立一個(gè)備份系統(tǒng)，所有在本地產(chǎn)生的日志同時(shí)也送往這個(gè)遠(yuǎn)程系統(tǒng)，為了防止網(wǎng)絡(luò)發(fā)生故障，本地與遠(yuǎn)程系統(tǒng)之間應(yīng)該同時(shí)建立幾條相互獨(dú)立的網(wǎng)絡(luò)連接。這聽上去好象有點(diǎn)超前，可實(shí)際上許多關(guān)鍵應(yīng)用早就用上了。
應(yīng)該明白的是，恢復(fù)畢竟是一種非常耗時(shí)的工作，特別是進(jìn)行后三種故障的恢復(fù)時(shí)，數(shù)據(jù)庫對(duì)用戶不可用。而這對(duì)象銀行這樣的部門來說，損失實(shí)在太大了。因此在很多情況下，我們只把恢復(fù)看作是最后的一道防線，我們希望最好永遠(yuǎn)也別需要用到它。因此現(xiàn)在就出來了各種各樣的容錯(cuò)設(shè)備，象RAID、雙機(jī)系統(tǒng)什么的，它們會(huì)把故障發(fā)生的概率降低到一個(gè)實(shí)際上可能永不發(fā)生的程度。
出處：藍(lán)色理想
責(zé)任編輯：風(fēng)狗
|
