1 / 9

Don’t be lazy, be consistent: Postgres-R, A new way to implement Database Replication

Don’t be lazy, be consistent: Postgres-R, A new way to implement Database Replication. Paper by Bettina Kemme and Gustavo Alonso, VLDB 2000 Presentation and Discussion led by Nickolay Tchervenski Sept 27, 2007, CS 848, University of Waterloo. Intro.

cili
Download Presentation

Don’t be lazy, be consistent: Postgres-R, A new way to implement Database Replication

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Don’t be lazy, be consistent: Postgres-R, A new way to implement Database Replication Paper by Bettina Kemme and Gustavo Alonso, VLDB 2000 Presentation and Discussion led by Nickolay Tchervenski Sept 27, 2007, CS 848, University of Waterloo

  2. Intro • Eager vs Lazy schemes. Issues and benefits. • If we want consistency and have the resources  go with eager • Paper proposes: • Run transaction locally with shadow copies • Propagate updates at the end • Acquire all locks in an atomic step • DB engine modifications necessary

  3. Replication Model • Shadow copies – use local DBMS to do updates  triggers/consistency checks/write-read dependencies for “free” • Propagate all updates at commit time • Local reads  don’t tell anyone • Group communication – multicast write set in total order and serialization order of transactions

  4. Replication Protocol • Local Read Phase and “shadow” updates • Send Phase – multicast the write set • Lock Phase • Obtain all transaction’s locks in an atomic step • Conflict test with local transaction. Abort it if in first two phases. Multicast abort when in send phase • Enqueue lock request after other transactions in write phase • Multicast commit if transaction local • Write Phase – remote transactions wait until commit arrives

  5. Architecture of Postgres-R

  6. Postgres-R Implementation Highlights • Shadow copies – tuple-based multiversion • Locking – simple tuple level locking • Index locking – issues with B-Trees • Write set – SQL or data

  7. Neat Ideas • Local vs Remote transactions and how they are handled • Updates are bundled in write-sets • Two messages per transaction • Write-set (ordered) – group communication • Commit/abort (unordered) • Significant reuse of DB and not hard to integrate into an appropriate existing DB

  8. Issues • Group communication necessary • Abort readers when write arrives (Read vs Lock phases). Other ways to tackle this, different isolation levels – CS / SI. • Need to modify DB engine code, not all DBs may be suitable for this (multiversion tuples, etc.) • Performance tests – • tweaks – not forcing bufferpool pages to disk @ commit • Better communication module – less cpu intensive

  9. Conclusion • Synchronous model that ensures consistency at a lower cost and with better scalability • Using group communication services, incl. for crash recovery • Can be improved

More Related