C store concurrency control and recovery
Download
1 / 18

C-Store: Concurrency Control and Recovery - PowerPoint PPT Presentation


  • 113 Views
  • Uploaded on

C-Store: Concurrency Control and Recovery. Jianlin Feng School of Software SUN YAT-SEN UNIVERSITY Jun. 5, 2009. Concurrency Control vs. Recovery. Concurrency Control Provide correct control of concurrent running of multiple transactions to maximize system throughput .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' C-Store: Concurrency Control and Recovery' - naomi-olson


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
C store concurrency control and recovery

C-Store: Concurrency Control and Recovery

Jianlin Feng

School of Software

SUN YAT-SEN UNIVERSITY

Jun. 5, 2009


Concurrency control vs recovery
Concurrency Control vs. Recovery

  • Concurrency Control

    • Provide correct control of concurrent running of multiple transactions to maximize system throughput.

      • i.e., the average number of transactions completed in a given time.

  • Recovery

    • Ensures database is fault tolerant, and not corrupted by software, system or media failure


Concurrency control in c store
Concurrency Control in C-Store

  • Uses strict two-phase locking to control concurrent running of read-write transactions.

    • each node (a site in the shared-nothing system architecture) sets locks on data objects that the runtime system reads or writes.

  • Resolves deadlocks via timeouts.

    • aborting one of the deadlocked transactions.

  • Does not use strict two-phase distributed commit.

    • avoiding the PREPARE phase.


Strict two phase locking strict 2pl
Strict Two-Phase Locking (Strict 2PL)

  • It is the most widely used locking protocol.

  • Two rules

    (1) If a transaction T wants to read (respectively, modify) a database object, it first requires a shared (respectively, exclusive) lock on the object.

    (2) All locks held by a transaction are released when the transaction is completed.


Distributed commit processing in c store 1 master and worker
Distributed COMMIT Processing in C-store (1): Master and Worker

  • Each transaction T has a master that is responsible for

    • assigning T ’ssub-transactions to appropriate nodes (workers).

    • and determining the ultimate commit state of T.


Distributed commit processing in c store 2 the protocol
Distributed COMMIT Processing in C-store (2): The Protocol Worker

  • 1st Phase

    • When the master receives a COMMIT statement for the transaction T, it waits until all workers have completed all outstanding actions

    • And then issues a commit (or abort) message to each worker.

  • 2nd Phase

    • Once a worker has received a commit message, it can releases all locks related to the transaction T

    • And delete the UNDO log for T.

      • T is completed, and hence has no need for UNDO in recovery.


Distributed commit processing in c store 3 the implications
Distributed COMMIT Processing in C-store (3): The Implications

  • In C-Store, the master does not PREPARE the workers.

  • So it is possible for a worker the master has told to commit to crash before writing any updates or log records related to a transaction to stable storage.

  • The failed worker will recover its state from other projections on other nodes during recovery.


Overview of recovery in c store
Overview of Recovery in C-Store Implications

  • Uses standard write-ahead logging protocol for recovery.

  • Uses a STEAL, NO-FORCE policy for writing database objects.

    • Possibly results in UNDO and REDO.

  • Only logs UNDO records.

  • Performs REDO by executing updates which have been queued on other nodes.


Write ahead logging property wal
Write-Ahead Logging Property(WAL) Implications

  • The Protocol

    • Each write must be recorded in the log (on disk) before the corresponding change is reflected in the database itself.

  • To ensure this protocol, the DBMS must be able to selectively force a page in memory to disk.

    • i.e., the page containing information on the write.


Contents of an update log record
Contents of an Update Log Record Implications

  • <prevLSN, transID, type, pageID, length, offset, before-image, after-image>

    • The first 3 fields are common to all log records.

    • The other fields are for updates.


Steal no force
STEAL / NO-FORCE Implications

  • STEAL

    • Allowing an updated page P of an uncommitted transaction T to be swapped from memory to disk.

    • T can abort later,so the DBMS must remember the old value of P to support UNDO.

  • NO-FORCE

    • When a transaction T commits, pages in the buffer that are modified by T are not forced to disk.

    • System can crash before all the pages are written to disk, so the DBMS must remember the updates of T to support REDO.


The recovery algorithm aries three phases
the Recovery Algorithm ARIES: Implicationsthree phases

  • Analysis: Identifies dirty pages in the buffer (i.e., changes that have not been written to disk) and active transactions at the time of the crash.

  • REDO: Repeats all actions and restores the database state to what it was at the time of the crash.

  • UNDO: Undoes the actions of aborted transactions.


Recovery in c store
Recovery in C-Store Implications

  • Basic idea

    • A crashed node recovers by running a query (copying state) from other projections.

  • K-Safety

    • Sufficient projections and join indexes are maintained,

    • So that K nodes can fail within time t, the time to recover,

    • And the system will be able to maintain transactional consistency.

  • Three cases to consider.


Recovery case 1
Recovery: Case 1 Implications

  • If the failed node suffered no data loss,

    • No dirty pages are found for aborted transactions.

  • Then we can restore it by executing updates that will be queued for it elsewhere in the system.

    • Assuming those updates are successfully saved in other nodes, and the updates can be identified by conditions on timestamp, transaction ID and etc.

    • Pages of committed transactions were not written to disk. So we simply need REDO.


Recovery case 2
Recovery: Case 2 Implications

  • If both the RS and WS are destroyed in the failed node,

  • Then we have to reconstruct both segments from other projections and join indexes in the system.

    • First restore segments by exploiting Insertion Vectors and Deleted Record Vectors from other nodes.

    • Second the queued updates must be run as in Case 1.


Recovery case 3
Recovery: Case 3 Implications

  • If WS is damaged but RS is good in the failed node,

  • Then we can reconstruct the WS from other corresponding WS segments and/or RS segments.

    • Identifying corresponding WS segments by checking the range of sort key.

    • Using the sort keys to find storage keys,

    • And then finding other tuple columns by following appropriate join indexes.


Queries for recovering ws
Queries for Recovering WS Implications

  • Note that each WS segment, S, contains only tuples with an insertion timestamp later than some time tlastmove(S).


References
References Implications

  • Mike Stonebraker, Daniel Abadi, Adam Batkin, Xuedong Chen, Mitch Cherniack, Miguel Ferreira, Edmond Lau, Amerson Lin, Sam Madden, Elizabeth O'Neil, Pat O'Neil, Alex Rasin, Nga Tran and Stan Zdonik. C-Store: A Column Oriented DBMS VLDB, pages 553-564, 2005.

  • Raghu Ramakrishnan and Johannes Gehrke. Database Management Systems (3rd edition).


ad