0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

梳理數(shù)據(jù)庫故障恢復(fù)問題的本質(zhì)及其發(fā)展優(yōu)化方向

電子工程師 ? 來源:cc ? 2019-01-18 13:46 ? 次閱讀

在數(shù)據(jù)庫系統(tǒng)發(fā)展的歷史長河中,故障恢復(fù)問題始終伴隨左右,也深刻影響著數(shù)據(jù)庫結(jié)構(gòu)的發(fā)展變化。通過故障恢復(fù)機(jī)制,可以實(shí)現(xiàn)數(shù)據(jù)庫的兩個(gè)至關(guān)重要的特性:Durability of Updates以及Failure Atomic,也就是我們常說的的ACID中的A和D。磁盤數(shù)據(jù)庫由于其卓越的性價(jià)比一直以來都占據(jù)數(shù)據(jù)庫應(yīng)用的主流位置。然而,由于需要協(xié)調(diào)內(nèi)存和磁盤兩種截然不同的存儲(chǔ)介質(zhì),在處理故障恢復(fù)問題時(shí)也增加了很多的復(fù)雜度。隨著學(xué)術(shù)界及工程界的共同努力及硬件本身的變化,磁盤數(shù)據(jù)庫的故障恢復(fù)機(jī)制也不斷的迭代更新,尤其近些年來,隨著NVM的浮現(xiàn),圍繞新硬件的研究也如雨后春筍出現(xiàn)。

本文希望通過分析不同時(shí)間點(diǎn)的關(guān)鍵研究成果,來梳理數(shù)據(jù)庫故障恢復(fù)問題的本質(zhì),其發(fā)展及優(yōu)化方向,以及隨著硬件變化而發(fā)生的變化。文章將首先描述故障恢復(fù)問題本身;然后按照基本的時(shí)間順序介紹傳統(tǒng)數(shù)據(jù)庫中故障恢復(fù)機(jī)制的演進(jìn)及優(yōu)化;之后思考新硬件帶來的機(jī)遇與挑戰(zhàn);并引出圍繞新硬件的兩個(gè)不同方向的研究成果;最后進(jìn)行總結(jié)。

問題

數(shù)據(jù)庫系統(tǒng)運(yùn)行過程中可能遇到的故障類型主要包括,Transaction Failure,Process Failure,System Failure以及Media Failure。其中Transaction Failure可能是應(yīng)用程序的主動(dòng)回滾,也可能是并發(fā)控制機(jī)制發(fā)現(xiàn)沖突后的強(qiáng)制Abort;Process Failure指的是由于各種原因?qū)е碌倪M(jìn)程退出,進(jìn)程內(nèi)存內(nèi)容會(huì)丟失;System Failure來源于操作系統(tǒng)或硬件故障,同樣會(huì)導(dǎo)致內(nèi)存丟失;Media Failure則是存儲(chǔ)介質(zhì)的不可恢復(fù)損壞。數(shù)據(jù)庫系統(tǒng)需要正確合理的處理這些故障,從而保證系統(tǒng)的正確性。為此需要提供兩個(gè)特性:

Durability of Updates:已經(jīng)Commit的事務(wù)的修改,故障恢復(fù)后仍然存在;

Failure Atomic:失敗事務(wù)的所有修改都不可見。

因此,故障恢復(fù)的問題描述為:即使在出現(xiàn)故障的情況下,數(shù)據(jù)庫依然能夠通過提供Durability及Atomic特性,保證恢復(fù)后的數(shù)據(jù)庫狀態(tài)正確。然而,要解決這個(gè)問題并不是一個(gè)簡單的事情,由于內(nèi)存及磁盤不同的數(shù)據(jù)組織方式及性能差異,為了不顯著犧牲數(shù)據(jù)庫性能,長久以來人們對(duì)故障恢復(fù)機(jī)制進(jìn)行了一系列的探索。

Shadow Paging

1981年,JIM GRAY等人在《The Recovery Manager of the System R Database Manager》采用了一種非常直觀的解決方式Shadow Paging[1]。System R的磁盤數(shù)據(jù)采用Page為最小的組織單位,一個(gè)File由多個(gè)Page組成,并通過稱為Direcotry的元數(shù)據(jù)進(jìn)行索引,每個(gè)Directory項(xiàng)紀(jì)錄了當(dāng)前文件的Page Table,指向其包含的所有Page。采用Shadow Paging的文件稱為Shadow File,如下圖中的File B所示,這種文件會(huì)包含兩個(gè)Directory項(xiàng),Current及Shawing。

事務(wù)對(duì)文件進(jìn)行修改時(shí),會(huì)獲得新的Page,并加入Current的Page Table,所有的修改都只發(fā)生在Current Directory;事務(wù)Commit時(shí),Current指向的Page刷盤,并通過原子的操作將Current的Page Table合并到Shadow Directory中,之后再返回應(yīng)用Commit成功;事務(wù)Abort時(shí)只需要簡單的丟棄Current指向的Page;如果過程中發(fā)生故障,恢復(fù)時(shí)只需要恢復(fù)Shadow Directory,相當(dāng)于對(duì)所有未提交事務(wù)的回滾操作。Shadow Paging很方便的實(shí)現(xiàn)了:

Durability of Updates:事務(wù)完成Commit后,所有修改的Page已經(jīng)落盤,合并到Shadow后,其所有的修改可以在故障后恢復(fù)出來。

Failure Atomic:回滾的事務(wù)由于沒有Commit,從未影響Shadow Directory,因此其所有修改不可見。

雖然Shadow Paging設(shè)計(jì)簡單直觀,但它的一些缺點(diǎn)導(dǎo)致其并沒有成為主流,首先不支持Page內(nèi)并發(fā),一個(gè)Commit操作會(huì)導(dǎo)致其Page上所有事務(wù)的修改被提交,因此一個(gè)Page內(nèi)只能包含一個(gè)事務(wù)的修改;其次不斷修改Page的物理位置,導(dǎo)致很難將相關(guān)的頁維護(hù)在一起,破壞局部性;另外,對(duì)大事務(wù)而言,Commit過程在關(guān)鍵路勁上修改Shadow Directory的開銷可能很大,同時(shí)這個(gè)操作還必須保證原子;最后,增加了垃圾回收的負(fù)擔(dān),包括對(duì)失敗事務(wù)的Current Pages和提交事務(wù)的Old Pages的回收。

WAL

由于傳統(tǒng)磁盤順序訪問性能遠(yuǎn)好于隨機(jī)訪問的特征,采用Logging的故障恢復(fù)機(jī)制意圖利用順序?qū)懙腖og來記錄對(duì)數(shù)據(jù)庫的操作,并在故障恢復(fù)后通過Log內(nèi)容將數(shù)據(jù)庫恢復(fù)到正確的狀態(tài)。簡單的說,采用Log機(jī)制的數(shù)據(jù)庫需要在每次修改數(shù)據(jù)內(nèi)容前先寫順序?qū)憣?duì)應(yīng)的Log,同時(shí)為了保證恢復(fù)時(shí)可以從Log中看到最新的數(shù)據(jù)庫狀態(tài),要求Log先于對(duì)應(yīng)的數(shù)據(jù)內(nèi)容落盤,也就是常說的Write Ahead Log,WAL。除此之外,事務(wù)完成Commit前還需要在Log中記錄對(duì)應(yīng)的Commit標(biāo)記,以供恢復(fù)時(shí)通過Log了解當(dāng)前的事務(wù)狀態(tài),因此還需要關(guān)注Commit標(biāo)記和事務(wù)中數(shù)據(jù)內(nèi)容的落盤順序。根據(jù)Log中記錄的內(nèi)容可以分為三類:Undo-Only,Redo-Only,Redo-Undo。

Undo-Only Logging

Undo-Only Logging的Log記錄可以表示未,事務(wù)T修改了X的值,X的舊值是v。事務(wù)提交時(shí),需要通過強(qiáng)制Flush保證Commit標(biāo)記落盤前,對(duì)應(yīng)事務(wù)的所有數(shù)據(jù)落盤,即落盤順序?yàn)長og記錄->Data->Commit標(biāo)記。恢復(fù)時(shí)可以根據(jù)Commit標(biāo)記判斷事務(wù)的狀態(tài),并通過Undo Log中記錄的舊值將未提交事務(wù)的修改回滾。我們來審視一下Undo-Only對(duì)Durability及Atomic的保證:

Durability of Updates:Data強(qiáng)制刷盤保證,已經(jīng)Commit的事務(wù)由于其所有Data都已經(jīng)在Commit標(biāo)記之前落盤,因此會(huì)一直存在;

Failure Atomic:Undo Log內(nèi)容保證,失敗事務(wù)的已刷盤的修改會(huì)在恢復(fù)階段通過Undo日志回滾,不再可見。

然而Undo-Only依然有Page內(nèi)并發(fā)的問題,如果兩個(gè)事務(wù)的修改落到一個(gè)Page中,一個(gè)事務(wù)提交前需要的強(qiáng)制Flush操作會(huì)導(dǎo)致同Page所有事務(wù)的Data落盤,可能會(huì)早于對(duì)應(yīng)的Log項(xiàng)從而損害WAL。同時(shí),Commit前的強(qiáng)制數(shù)據(jù)刷盤會(huì)導(dǎo)致關(guān)鍵路徑上過于頻繁的磁盤隨機(jī)訪問。

Redo-Only Logging

不同于Undo-Only,采用Redo-Only的Log中記錄的是修改后的新值。對(duì)應(yīng)地,Commit時(shí)需要保證Log中的Commit標(biāo)記需要在事務(wù)的任何事務(wù)羅盤前落盤,即落盤順序?yàn)長og記錄->Commit標(biāo)記->Data?;謴?fù)時(shí)同樣根據(jù)Commit標(biāo)記判斷事務(wù)狀態(tài),并通過Redo Log中記錄的新值將已經(jīng)Commit,但數(shù)據(jù)沒有落盤的事務(wù)修改重放。

Durability of Updates:Redo Log內(nèi)容保證,已提交事務(wù)的未刷盤的修改,利用Redo Log中的內(nèi)容重放,之后可見;

Failure Atomic:阻止Commit前Data落盤保證,失敗事務(wù)的修改不會(huì)出現(xiàn)在磁盤上,自然不可見。

Redo-Only同樣有Page內(nèi)并發(fā)的問題,同Page中的多個(gè)不同事務(wù),只要有一個(gè)未提交就不能刷盤,這些數(shù)據(jù)全部都需要維護(hù)在內(nèi)存中,會(huì)造成較大的內(nèi)存壓力。

Redo-Undo Logging

可以看出的只有Undo或Redo的Logging方式的問題主要來自與對(duì)Commit標(biāo)記及Data落盤順序的限制,而這種限制歸根結(jié)底來源于Log信息中對(duì)新值或舊值的缺失。因此Redo-Undo采用同時(shí)記錄新值和舊值的方式來取消對(duì)刷盤順序的限制。

Durability of Updates:Redo 內(nèi)容保證,已提交事務(wù)的未刷盤的修改,利用Redo Log中的內(nèi)容重放,之后可見;

Failure Atomic:Undo內(nèi)容保證,失敗事務(wù)的已刷盤的修改會(huì)在恢復(fù)階段通過Undo日志回滾,不再可見。

如此一來,同Page的不同事務(wù)提交就變得很簡單。同時(shí)可以將連續(xù)的數(shù)據(jù)攢著進(jìn)行批量的刷盤已利用磁盤較高的順序?qū)懶阅堋?/p>

Force and Steal

從上面看出,Redo和Undo內(nèi)容分別可以保證Durability和Atomic兩個(gè)特性,其中一種信息的缺失需要用嚴(yán)格的刷盤順序來彌補(bǔ)。這里關(guān)注的刷盤順序包含兩個(gè)維度:

Force or No-Force:Commit時(shí)是否需要強(qiáng)制刷盤,采用Force的方式由于所有的已提交事務(wù)的數(shù)據(jù)一定已經(jīng)存在與磁盤,自然而然地保證了Durability。

No-Steal or Steal,Commit前數(shù)據(jù)是否可以提前刷盤,采用No-Steal的方式由于保證事務(wù)提交前修改不會(huì)出現(xiàn)在磁盤上,自然而然地保證了Atomic

總結(jié)一下,實(shí)現(xiàn)Durability可以記錄Redo信息或要求Force刷盤順序,實(shí)現(xiàn)Atomic需要記錄Undo信息或要求No-Steal刷盤順序,組合得到如下四種模式,如下圖所示:

ARIES,一統(tǒng)江湖

1992年,IBM的研究員們發(fā)表了《ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging》[2],其中提出的ARIES逐步成為磁盤數(shù)據(jù)庫實(shí)現(xiàn)故障恢復(fù)的標(biāo)配,ARIES本質(zhì)是一種Redo-Undo的WAL實(shí)現(xiàn)。Normal過程:修改數(shù)據(jù)之前先追加Log記錄,Log內(nèi)容同時(shí)包括Redo和Undo信息,每個(gè)日志記錄產(chǎn)生一個(gè)標(biāo)記其在日志中位置的遞增LSN(Log Sequence Number);數(shù)據(jù)Page中記錄最后修改的日志項(xiàng)LSN,以此來判斷Page中的內(nèi)容的新舊程度,實(shí)現(xiàn)冪等。故障恢復(fù)階段需要通過Log中的內(nèi)容恢復(fù)數(shù)據(jù)庫狀態(tài),為了減少恢復(fù)時(shí)需要處理的日志量,ARIES會(huì)在正常運(yùn)行期間周期性的生成Checkpoint,Checkpoint中除了當(dāng)前的日志LSN之外,還需要記錄當(dāng)前活躍事務(wù)的最新LSN,以及所有臟頁,供恢復(fù)時(shí)決定重放Redo的開始位置。需要注意的是,由于生成Checkpoint時(shí)數(shù)據(jù)庫還在正常提供服務(wù)(Fuzzy Checkpoint),其中記錄的活躍事務(wù)及Dirty Page信息并不一定準(zhǔn)確,因此需要Recovery階段通過Log內(nèi)容進(jìn)行修正。

Recover過程:故障恢復(fù)包含三個(gè)階段:Analysis,Redo和Undo。Analysis階段的任務(wù)主要是利用Checkpoint及Log中的信息確認(rèn)后續(xù)Redo和Undo階段的操作范圍,通過Log修正Checkpoint中記錄的Dirty Page集合信息,并用其中涉及最小的LSN位置作為下一步Redo的開始位置RedoLSN。同時(shí)修正Checkpoint中記錄的活躍事務(wù)集合(未提交事務(wù)),作為Undo過程的回滾對(duì)象;Redo階段從Analysis獲得的RedoLSN出發(fā),重放所有的Log中的Redo內(nèi)容,注意這里也包含了未Commit事務(wù);最后Undo階段對(duì)所有未提交事務(wù)利用Undo信息進(jìn)行回滾,通過Log的PrevLSN可以順序找到事務(wù)所有需要回滾的修改。

除此之外,ARIES還包含了許多優(yōu)化設(shè)計(jì),例如通過特殊的日志記錄類型CLRs避免嵌套R(shí)ecovery帶來的日志膨脹,支持細(xì)粒度鎖,并發(fā)Recovery等。[3]認(rèn)為,ARIES有兩個(gè)主要的設(shè)計(jì)目標(biāo):

Feature:提供豐富靈活的實(shí)現(xiàn)事務(wù)的接口:包括提供靈活的存儲(chǔ)方式、提供細(xì)粒度的鎖、支持基于Savepoint的事務(wù)部分回滾、通過Logical Undo以獲得更高的并發(fā)、通過Page-Oriented Redo實(shí)現(xiàn)簡單的可并發(fā)的Recovery過程。

Performance:充分利用內(nèi)存和磁盤介質(zhì)特性,獲得極致的性能:采用No-Force避免大量同步的磁盤隨機(jī)寫、采用Steal及時(shí)重用寶貴的內(nèi)存資源、基于Page來簡化恢復(fù)和緩存管理。

NVM帶來的機(jī)遇與挑戰(zhàn)

從Shadow Paging到WAL,再到ARIES,一直圍繞著兩個(gè)主題:減少同步寫以及盡量用順序?qū)懘骐S機(jī)寫。而這些正是由于磁盤性能遠(yuǎn)小于內(nèi)存,且磁盤順序訪問遠(yuǎn)好于隨機(jī)訪問。然而隨著NVM磁盤的出現(xiàn)以及對(duì)其成為主流的預(yù)期,使得我們必須要重新審視我們所做的一切。相對(duì)于傳統(tǒng)的HDD及SSD,NVM最大的優(yōu)勢(shì)在于:

接近內(nèi)存的高性能

順序訪問和隨機(jī)訪問差距不大

按字節(jié)尋址而不是Block

在這種情況下,再來看ARIES的實(shí)現(xiàn):

No-force and Steal:同時(shí)維護(hù)Redo, Undo和數(shù)據(jù)造成的三倍寫放大,來換取磁盤順序?qū)懙男阅?,但在NVM上這種取舍變得很不劃算;

Pages:為了遷就磁盤基于Block的訪問接口,采用Page的存儲(chǔ)管理方式,而內(nèi)存本身是按字節(jié)尋址的,因此,這種適配也帶來很大的復(fù)雜度。在同樣按字節(jié)尋址的NVM上可以消除。

近年來,眾多的研究嘗試為NVM量身定制更合理的故障恢復(fù)機(jī)制,我們這幾介紹其中兩種比較有代表性的研究成果,MARS希望充分利用NVM并發(fā)及內(nèi)部帶寬的優(yōu)勢(shì),將更多的任務(wù)交給硬件實(shí)現(xiàn);而WBL則嘗試重構(gòu)當(dāng)前的Log方式。

MARS

發(fā)表在2013年的SOSP上的《"From ARIES to MARS: Transaction support for next-generation, solid-state drives." 》提出了一種盡量保留ARIES特性,但更適合NVM的故障恢復(fù)算法MARS[3]。MARS取消了Undo Log,保留的Redo Log也不同于傳統(tǒng)的Append-Only,而是可以隨機(jī)訪問的。如下圖所示,每個(gè)事務(wù)會(huì)占有一個(gè)唯一的TID,對(duì)應(yīng)的Metadata中記錄了Log和Data的位置。

正常訪問時(shí),所有的數(shù)據(jù)修改都在對(duì)應(yīng)的Redo Log中進(jìn)行,不影響真實(shí)數(shù)據(jù),由于沒有Undo Log,需要采用No-Steal的方式,阻止Commit前的數(shù)據(jù)寫回;Commit時(shí)會(huì)先設(shè)置事務(wù)狀態(tài)為COMMITTED,之后利用NVM的內(nèi)部帶寬將Redo中的所有內(nèi)容并發(fā)拷貝回Metadata中記錄的數(shù)據(jù)位置。如果在COMMITED標(biāo)記設(shè)置后發(fā)生故障,恢復(fù)時(shí)可以根據(jù)Redo Log中的內(nèi)容重放。其本質(zhì)是一種Redo加No-Steal的實(shí)現(xiàn)方式:

Durability of Updates: Redo實(shí)現(xiàn),故障后重放Redo;

Failure Atomic:未Commit事務(wù)的修改只存在于Redo Log,重啟后會(huì)被直接丟棄。

可以看出,MARS的Redo雖然稱之為Log,但其實(shí)已經(jīng)不同于傳統(tǒng)意義上的順序?qū)懳募?,允許隨機(jī)訪問,更像是一種臨時(shí)的存儲(chǔ)空間,類似于Shadow的東西。之所以在Commit時(shí)進(jìn)行數(shù)據(jù)拷貝而不是像Shadow Paging一樣的元信息修改,筆者認(rèn)為是為了保持?jǐn)?shù)據(jù)的局部性,并且得益于硬件優(yōu)異的內(nèi)部帶寬。

WBL

不同于MARS保留Redo信息的思路,2016年VLDB上的《 "Write Behind Logging" 》只保留了Undo信息。筆者認(rèn)為這篇論文中關(guān)于WBL的介紹里,用大量筆墨介紹了算法上的優(yōu)化部分,為了抓住其本質(zhì),這里先介紹最基本的WBL算法,WBL去掉了傳統(tǒng)的Append Only的Redo和Undo日志,但仍然需要保留Undo信息用來回滾未提交事務(wù)。事務(wù)Commit前需要將其所有的修改強(qiáng)制刷盤,之后在Log中記錄Commit標(biāo)記,也就是這里說的Write Behind Log?;謴?fù)過程中通過分析Commit標(biāo)記將為提交的事務(wù)通過Undo信息回滾??梢钥闯鯳BL算法本身非常簡單,在這個(gè)基礎(chǔ)上,WBL做了如下優(yōu)化:

Group Commit:周期性的檢查內(nèi)存中的修改,同樣先將所有修改刷盤后寫Log,Log項(xiàng)中記錄最新Commit并落盤的最大事務(wù)TimeStamp cp,保證早于cp的所有事務(wù)修改都已經(jīng)落盤;同時(shí)記錄當(dāng)前分配出去的最大TimeStamp cd;也就是說此時(shí)所有有修改但未提交的事務(wù)Timestamp都落在cp和cd之間。Reovery的時(shí)候只需對(duì)這部分?jǐn)?shù)據(jù)進(jìn)行回滾;

針對(duì)多版本數(shù)據(jù)庫,多版本信息已經(jīng)起到了undo的作用,因此不需要再額外記錄undo信息;

延遲回滾:Recovery后不急于對(duì)未提交事務(wù)進(jìn)行回滾,而是直接提供服務(wù),一組(cp, cd)稱為一個(gè)gap,每一次故障恢復(fù)都可能引入新的gap,通過對(duì)比事務(wù)Timestamp和gap集合,來判斷數(shù)據(jù)的可見性,需要依靠后臺(tái)垃圾回收線程真正的進(jìn)行回滾和對(duì)gap的清理,如下圖所示

可以看出,WBL本質(zhì)并沒有什么新穎,是一個(gè)Force加Undo的實(shí)現(xiàn)方式,其正確性保證如下:

Durability of Updates:Commit事務(wù)的數(shù)據(jù)刷盤后才進(jìn)行Commit,因此Commit事務(wù)的數(shù)據(jù)一定在Recovery后存在

Failure Atomic:通過記錄的Undo信息或多版本時(shí)的歷史版本信息,在Recovery后依靠后臺(tái)垃圾回收線程進(jìn)行回滾。

總結(jié)

數(shù)據(jù)庫故障恢復(fù)問題本質(zhì)是要在容忍故障發(fā)生的情況下保證數(shù)據(jù)庫的正確性,而這種正確性需要通過提供Durability of Updates和Failure Atomic來保證。其中Duribility of Update要保證Commit事務(wù)數(shù)據(jù)在恢復(fù)后存在,可以通過Force機(jī)制或者通過Redo信息回放來保證;對(duì)應(yīng)的,F(xiàn)ailure Atomic需要保證未Commit事務(wù)的修改再恢復(fù)后消失,可以通過No-Steal機(jī)制或者通過Undo信息回滾來保證。可以保證Durability和Atomic的方式,對(duì)本文提到的算法進(jìn)行分類,如下:

Shadow Paging可以看做是采用了Force加No-Steal的方式,沒有Log信息,在Commit時(shí),通過原子的修改Directory元信息完成數(shù)據(jù)的持久化更新,但由于其對(duì)Page內(nèi)并發(fā)的限制,以及對(duì)數(shù)據(jù)局部性的破壞等原因,沒有成為主流;

Logging的實(shí)現(xiàn)方式增加了Redo或Undo日志,記錄恢復(fù)需要的信息,從而放松Force或No-Steal機(jī)制對(duì)刷盤順序的限制,從而盡量用磁盤順序?qū)懘骐S機(jī)寫獲得較好的性能。ARIES算法是在這一方向上的集大成者,其對(duì)上層應(yīng)用提供了豐富靈活的接口,采用了No-Force加Steal機(jī)制,將傳統(tǒng)磁盤上的性能發(fā)揮到極致,從而成為傳統(tǒng)磁盤數(shù)據(jù)故障恢復(fù)問題的標(biāo)準(zhǔn)解決方案;

隨著NVM設(shè)備的逐步出現(xiàn),其接近內(nèi)存的性能、同樣優(yōu)異的順序訪問和隨機(jī)訪問性能,以及基于字節(jié)的尋址方式,促使人們開始重新審視數(shù)據(jù)庫故障恢復(fù)的實(shí)現(xiàn)。其核心思路在于充分利用NVM硬件特性,減少Log機(jī)制導(dǎo)致的寫放大以及設(shè)計(jì)較復(fù)雜的問題;

MARS作為其中的佼佼者之一,在NVM上維護(hù)可以隨機(jī)訪問的Redo日志,同時(shí)采用Force加Steal的緩存策略,充分利用NVM優(yōu)異的隨機(jī)寫性能和內(nèi)部帶寬。

WBL從另一個(gè)方向進(jìn)行改造,保留Undo信息,采用No-Force加No-Steal的緩存策略,并通過Group Commit及延遲回滾等優(yōu)化,減少日志信息,縮短恢復(fù)時(shí)間。

本文介紹了磁盤數(shù)據(jù)庫一路走來的核心發(fā)展思路,但距離真正的實(shí)現(xiàn)還有巨大的距離和眾多的設(shè)計(jì)細(xì)節(jié),如對(duì)Logical Log或Physical Log的選擇、并發(fā)Recovery、Fuzzy Checkpoing、Nested Top Actions等,之后會(huì)用單獨(dú)的文章以InnoDB為例來深入探究其設(shè)計(jì)和實(shí)現(xiàn)細(xì)節(jié)。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 硬件
    +關(guān)注

    關(guān)注

    11

    文章

    3181

    瀏覽量

    66018
  • 數(shù)據(jù)庫
    +關(guān)注

    關(guān)注

    7

    文章

    3739

    瀏覽量

    64183

原文標(biāo)題:數(shù)據(jù)庫故障恢復(fù)機(jī)制的前世今生

文章出處:【微信號(hào):inf_storage,微信公眾號(hào):數(shù)據(jù)庫和存儲(chǔ)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    Oracle數(shù)據(jù)恢復(fù)—異常斷電后Oracle數(shù)據(jù)庫報(bào)錯(cuò)的數(shù)據(jù)恢復(fù)案例

    Oracle數(shù)據(jù)庫故障: 機(jī)房異常斷電后,Oracle數(shù)據(jù)庫報(bào)錯(cuò):“system01.dbf需要更多的恢復(fù)來保持一致性,
    的頭像 發(fā)表于 09-30 13:31 ?172次閱讀
    Oracle<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—異常斷電后Oracle<b class='flag-5'>數(shù)據(jù)庫</b>啟<b class='flag-5'>庫</b>報(bào)錯(cuò)的<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—Oracle數(shù)據(jù)庫文件system01.dbf損壞的數(shù)據(jù)恢復(fù)案例

    打開oracle數(shù)據(jù)庫報(bào)錯(cuò)“system01.dbf需要更多的恢復(fù)來保持一致性,數(shù)據(jù)庫無法打開”。
    的頭像 發(fā)表于 09-21 14:25 ?195次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—Oracle<b class='flag-5'>數(shù)據(jù)庫</b>文件system01.dbf損壞的<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—SQL Server數(shù)據(jù)庫出現(xiàn)823錯(cuò)誤的數(shù)據(jù)恢復(fù)案例

    SQL Server數(shù)據(jù)庫故障: SQL Server附加數(shù)據(jù)庫出現(xiàn)錯(cuò)誤823,附加數(shù)據(jù)庫失敗。數(shù)據(jù)庫沒有備份,無法通過備份
    的頭像 發(fā)表于 09-20 11:46 ?239次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—SQL Server<b class='flag-5'>數(shù)據(jù)庫</b>出現(xiàn)823錯(cuò)誤的<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—SQL Server數(shù)據(jù)庫所在分區(qū)空間不足報(bào)錯(cuò)的數(shù)據(jù)恢復(fù)案例

    Server數(shù)據(jù)庫故障: 存放SQL Server數(shù)據(jù)庫的D盤分區(qū)容量不足,管理員在E盤中生成了一個(gè).ndf的文件并且將數(shù)據(jù)庫路徑指向E盤繼續(xù)使用。
    的頭像 發(fā)表于 07-10 13:54 ?384次閱讀

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)數(shù)據(jù)庫所在分區(qū)空間不足導(dǎo)致sqlserver故障數(shù)據(jù)恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)環(huán)境: 某品牌r520服務(wù)器,服務(wù)器中有7塊SAS硬盤,這7塊硬盤組建了一組2盤raid1陣列和一組5盤raid5陣列,raid1陣列存儲(chǔ)空間安裝操作系統(tǒng),raid5陣列存儲(chǔ)空間存放
    的頭像 發(fā)表于 05-22 13:16 ?341次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—<b class='flag-5'>數(shù)據(jù)庫</b>所在分區(qū)空間不足導(dǎo)致sqlserver<b class='flag-5'>故障</b>的<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—raid5陣列上層Sql Server數(shù)據(jù)庫數(shù)據(jù)恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)環(huán)境: 5塊硬盤組建一組RAID5陣列,劃分LUN供windows系統(tǒng)服務(wù)器使用。windows系統(tǒng)服務(wù)器內(nèi)運(yùn)行了Sql Server數(shù)據(jù)庫,存儲(chǔ)空間在操作系統(tǒng)層面劃分
    的頭像 發(fā)表于 05-08 11:43 ?435次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—raid5陣列上層Sql Server<b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    MongoDB數(shù)據(jù)恢復(fù)—MongoDB數(shù)據(jù)庫文件損壞的數(shù)據(jù)恢復(fù)案例

    服務(wù)器數(shù)據(jù)恢復(fù)環(huán)境: 一臺(tái)Windows Server操作系統(tǒng)服務(wù)器,服務(wù)器上部署MongoDB數(shù)據(jù)庫。 MongoDB數(shù)據(jù)庫故障&
    的頭像 發(fā)表于 04-23 14:48 ?351次閱讀
    MongoDB<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—MongoDB<b class='flag-5'>數(shù)據(jù)庫</b>文件損壞的<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—Sql Server數(shù)據(jù)庫文件丟失的數(shù)據(jù)恢復(fù)案例

    服務(wù)器數(shù)據(jù)恢復(fù)環(huán)境: 一臺(tái)安裝windows server操作系統(tǒng)的服務(wù)器。一組由8塊硬盤組建的RAID5,劃分LUN供這臺(tái)服務(wù)器使用。 在windows服務(wù)器內(nèi)裝有SqlServer數(shù)據(jù)庫
    的頭像 發(fā)表于 04-11 15:38 ?768次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—Sql Server<b class='flag-5'>數(shù)據(jù)庫</b>文件丟失的<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—未開啟binlog的Mysql數(shù)據(jù)庫數(shù)據(jù)恢復(fù)案例

    mysql數(shù)據(jù)庫數(shù)據(jù)恢復(fù)環(huán)境: 本地服務(wù)器,windows server操作系統(tǒng) ,部署有mysql單實(shí)例,數(shù)據(jù)庫引擎類型為innodb,獨(dú)立表空間,無
    的頭像 發(fā)表于 12-08 14:18 ?1010次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—未開啟binlog的Mysql<b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    聊聊日志即數(shù)據(jù)庫

    數(shù)據(jù)庫故障恢復(fù)機(jī)制的前世今生》[1]一文中介紹過,由于磁盤的的順序訪問性能遠(yuǎn)好于隨機(jī)訪問,數(shù)據(jù)庫設(shè)計(jì)中通常都會(huì)采用WAL的方式,將隨機(jī)訪問的數(shù)據(jù)庫
    的頭像 發(fā)表于 12-06 09:30 ?633次閱讀
    聊聊日志即<b class='flag-5'>數(shù)據(jù)庫</b>

    MySQL數(shù)據(jù)庫是如何應(yīng)對(duì)故障恢復(fù)數(shù)據(jù)恢復(fù)回滾的問題呢?

    今天這篇文章,我想聊一聊MySQL數(shù)據(jù)庫是如何應(yīng)對(duì)故障恢復(fù),與數(shù)據(jù)恢復(fù)回滾的問題。一個(gè)最基本的數(shù)據(jù)庫
    的頭像 發(fā)表于 11-27 10:04 ?1027次閱讀
    MySQL<b class='flag-5'>數(shù)據(jù)庫</b>是如何應(yīng)對(duì)<b class='flag-5'>故障</b><b class='flag-5'>恢復(fù)</b>與<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>回滾的問題呢?

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—MSSQL Server報(bào)錯(cuò)“附加數(shù)據(jù)庫錯(cuò)誤823”的數(shù)據(jù)恢復(fù)案例

    MSSQL Server數(shù)據(jù)庫比較常見的報(bào)錯(cuò)是“附加數(shù)據(jù)庫錯(cuò)誤823”。如果數(shù)據(jù)庫有備份,只需要還原備份即可;如果無備份或者備份不可用,則需要使用專業(yè)的數(shù)據(jù)
    的頭像 發(fā)表于 11-10 16:20 ?815次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—MSSQL Server報(bào)錯(cuò)“附加<b class='flag-5'>數(shù)據(jù)庫</b>錯(cuò)誤823”的<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—MySQL數(shù)據(jù)庫表誤刪除記錄的數(shù)據(jù)恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)環(huán)境: 一臺(tái)本地windows sever操作系統(tǒng)服務(wù)器,服務(wù)器上部署mysql數(shù)據(jù)庫單實(shí)例,引擎類型為innodb,表內(nèi)數(shù)據(jù)
    的頭像 發(fā)表于 11-09 15:16 ?1218次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>—MySQL<b class='flag-5'>數(shù)據(jù)庫</b>表誤刪除記錄的<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>恢復(fù)</b>案例

    服務(wù)器數(shù)據(jù)恢復(fù)—誤還原快照導(dǎo)致SqlServer數(shù)據(jù)庫數(shù)據(jù)丟失的數(shù)據(jù)恢復(fù)案例

    服務(wù)器數(shù)據(jù)恢復(fù)環(huán)境: vmfs文件系統(tǒng),存放的是SqlServer數(shù)據(jù)庫及其他辦公文件。 服務(wù)器故障: 工作人員誤操作還原快照,導(dǎo)
    的頭像 發(fā)表于 11-06 15:06 ?614次閱讀