Segment-oriented Recovery

Transcription

1 Advanced Tpics in Operating Systems, CS262a Prf. Eric A. Brewer (with help frm Rusty Sears) Segment-riented Recvery ARIES wrks great but is 20+ years ld and has sme prblems: viewed as very cmplex n available implementatins with surce cde part f a mnlithic DBMS: can use reuse transactins fr ther systems? LSN in the page breaks up large bjects (Fig 1), prevents efficient I/O DBMS seems hard t scale fr clud cmputing (except by partitining) Original gals (Stasis): build an pen-surce transactin system with full ARIES-style steal/n-frce transactins try t make the DBMS mre layered in the OS style try t supprt a wider array f transactinal systems: versin cntrl, file systems, biinfrmatics r science databases, graph prblems, search engines, persistent bjects,... cmpetitive perfrmance These gals were mstly met, althugh the pen-surce versin needs mre users and we have nly tried sme f the unusual applicatins. Original versin was basically straight ARIES; develpment led t many insights and the new versin based n segments. Segment-riented recvery (SOR) A segment is just a range f bytes may span multiple pages may have many per page analgus t segments and pages in cmputer architecture (but arch uses segments fr prtectin bundaries, we use them fr recvery bundaries; in bth, pages are fixed size and the unit f mvement t disk) Key idea: change tw f the cre ARIES design pints: Recver segments nt pages N LSNs n pages ARIES: LSN per page enable exactly nce red semantics SOR: estimate the LSN cnservatively (lder) => at least nce semantics [but must nw limit the actins we can take in red] The Big Fur Psitives f SOR: 1

2 1) Enable DMA and/r zer-cpy I/O N LSNs per page mean that large bjects are cntiguus n disk N segmentatin and reassembly t mve bjects t/frm the disk N need t invlve the CPU in bject I/O (very expensive); use DMA instead 2) Fix persistent bjects Prblem: cnsider page with multiple bjects, each f which has an in memry representatin (e.g. a C++ r Java bject) Suppse we update bject A and generate a lg entry with LSN=87 Next we update bject B (n the same page), generate its lg entry with LSN=94, and write it back t the disk page, updating the page LSN This pattern breaks recvery: the new page LSN (94) implies that the page reflects red lg entry 87, but it des nt. ARIES slutin : disk pages (in memry) must be updated n every lg write; this is write thrugh caching -- all updates are written thrugh t the buffer manager page SOR slutin: there is n page LSN and thus n errr Buffer manager is written n cache evictin -- write back caching. This implies much less cpying/ marshalling fr ht bjects. This is like n frce between the app cache and the buffer manager (!) 3) Enable high/lw pririty transactins (lg rerdering n the fly) With pages, we assign the LSN atmically with the page write [draw fig 2] nt pssible t rerder lg entries at all in thery, tw independent transactins culd have their lg entries rerdered based n pririty r because they are ging t different lg disks (r lg servers) SOR: d nt need t knw LSN at the time f the page update (just need t make sure it is assigned befre yu cmmit, s that it is rdered befre later transactins; this is trivial t ensure -- just use nrmal lcking and fllw WAL prtcl) High pririty updates: mve lg entry t the frnt f the lg r t high pririty fast lg disk Lw pririty updates g t end f lg as usual 2

3 4) Decuple the cmpnents; enable clud cmputing versins backgrund: pin pages t keep them frm being stlen (shrt term), latch pages t avid race cnditins within a page subtle prblem with pages: must latch the page acrss the call t lg manager (in rder t get an LSN atmically) SOR has n page LSN and in fact n shared state at all fr pages => n latch needed SOR decuple three different things: App <-> Buffer manager: this is the write-back caching described abve: nly need t interact n evictin, nt n each update Buffer manager <-> lg manager: n hlding a latch acrss the lg manager call; lg manager call can nw by asynchrnus and batched tgether Segments can be mved via zer-cpy I/O directly, with n meta data (e.g. page LSN) and n CPU invlvement. Simplifies archiving and reading large bjects (e.g. phts). Hpe: smene (ideally in CS262) will build a distributed transactin service using SOR Apps, Buffer Manager, Lg Manager, Stable strage culd all be different clusters Perfrmance: (fig 11): 1-3 rders f magnitude difference fr distributed transactins Physilgical Red (review): Reds are applied exactly nce (using the page LSN) Cmbinatin f physical and lgical lgging physical: write pre- r pst-images (r bth) lgical: write the lgical peratin ( insert ) Physilgical: 3

4 reds are physical nrmal unds are like reds and set a new LSN (des nt revert t the ld LSN -- wuldn t wrk given multiple bjects per page!) t enable mre cncurrency, d nt und structural changes f a B-Tree (r ther index); instead f a physical und, issue a new lgical und that is the inverse peratin. Enables cncurrency because we can hld shrt lcks fr the structural change rather than lng lcks (until the end f the transactin) Sltted pages: add an array f ffsets t each page (slts), then stre recrds with a slt number and use the array t lk up the current ffset fr that recrd. This allws changing the page layut withut any lg entries. SOR Red: Reds may applied mre than nce; we g back farther in time than strictly necessary Reds must be physical blind writes -- write cntent that d nt depend n the previus cntents Unds can still be lgical fr cncurrency Sltted page layut changes require red lgging Cre SOR red phase: peridically write estimated LSNs t lg (after yu write back a page) start frm disk versin f the segment (r frm snapsht r whle segment write) replay all reds since estimated LSN (wrst case the beginning f the truncated lg), even thugh sme might have been applied already fr all bytes f the segment: either it was crrect n disk and nt changed r it was written during recvery in rder by time (and thus crrectly reflects the last lg entry t tuch that byte) Hybrid Recvery: Can mix SOR and traditinal ARIES Sme pages have LSNs, sme dn t Can t easily lk at a page and tell! (all the bytes are used fr segments) Lg page type changes and zer ut the page recvery may actually crrupt a page temprarily until it gets the type crrect, at which pint it rlls frward crrectly frm the all zer page. Example f when t use: Extra stuff: B-Trees: internal ndes n pages, leaves are segments Tables f strings: shrt strings gd fr pages especially if they change size; lng strings are gd fr segments due t cntiguus layut Why are there LSNs n pages? s that we can atmically write the timestamp (LSN) with the page prblem: page writes aren t actually atmic anymre slutin: make them atmic s that ARIES still wrks 4

5 write sme bits int all sectrs f a page (8K page = B sectrs); cmpare thse bits with a value stre smewhere else. N match => recver the page (but may match and be wrng). Assumes sectrs are written atmically, which is reasnable. write a checksum fr each page (including the LSN) and check it when reading back the page Bth slutins impact I/O perfrmance sme SOR apprach: checksum each segment (r grup f segments if they are small) n checksum failure, can replay last red, which can fix a trn page (and then cnfirm using the checksum); if that desn t wrk g back t ld versin and rll frward blind writes can fix crrupted pages since they d nt depend n its cntents 5