csce824-lecture9

csce824-lecture9 - Replicated Databases Replicated...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Replicated Databases Replicated Databases Reading Reading Farkas Textbook: Ch.13 CSCE 824 ­ Spring 2011 2 Review Review Centralized DBMS Distributed DBMS – Data fragmentation and allocation Top­down design Bottom­up design – Transaction processing Serializability theorem Locking protocols Reliability Farkas CSCE 824 ­ Spring 2011 3 Compatibility IS IX S SIX X IS IX S SIX X Farkas Farkas CSCE 824 ­ Spring 2011 4 Compatibility IS IX S SIX X IS T T T T F IX T T F F F S T F T F F SIX T F F F F X F F F F F Farkas Farkas CSCE 824 ­ Spring 2011 5 EXAMPLE EXAMPLE What type of locks should these transactions should obtain? Database T1: read: Record 2 T2: read: Relation write: Record 1 Relation Record 1 Farkas Record 2 CSCE 824 ­ Spring 2011 6 EXAMPLE T2: IX T1: IS T2: SIX T1: IS Database T2: read: Relation write: Record 1 Relation T2: X Record 1 Farkas Farkas T1: read: Record 2 Record 2 CSCE 824 ­ Spring 2011 T1: S 7 Replicated Databases Replicated Databases Multiple copies of the same data items (databases) Consistency: – Local consistency – Mutual consistency Farkas CSCE 824 ­ Spring 2011 8 Why Replication? Why Replication? Farkas System availability Performance Scalability Application requirements CSCE 824 ­ Spring 2011 9 Risk of Replication Risk of Replication Farkas Worse performance: updates must be applied to all replicas and synchronized Worse availability: some algorithms require multiple replicas to be operational for any of them to be used CSCE 824 ­ Spring 2011 10 Transaction Correctness Transaction Correctness 2­Phase Locking – serializability 2­Phase Commit – reliability Replica control – mutual consistency – Database design: local vs. global transactions – Database consistency: strong consistency vs. weak consistency – Location of updates: master vs. distributed – Update propagation: eager vs. lazy – Degree of transparency: limited vs. full Farkas CSCE 824 ­ Spring 2011 11 Mutual Consistency vs. Mutual Consistency vs. Transaction Consistency Transaction consistency: global serializability Mutual consistency: replicas having the same values – Strong: all replicas have the same value at the end of the execution of an update transaction – Quorum: a quorum of replicas have the same value – Weak: eventually the values of all replicas become identical Farkas CSCE 824 ­ Spring 2011 12 Replica Control Hides replication from transaction Knows location of all replicas Translates transaction’s request to access an item into request to access particular replica(s) Maintains some form of mutual consistency Farkas Farkas CSCE 824 ­ Spring 2011 13 13 One­Copy Serializability One­Copy Serializability (1SR) Farkas Extension of the serializability theory Effects of transactions on replicated data items should be the same as if they had been performed one at­a­time on a single set of date items CSCE 824 ­ Spring 2011 14 Example Replication x1 x2 Transaction x3 Issues – May reduce performance (complex operations) – Too expensive – Can’t control when replicas are updated Farkas Farkas 7/22/99 CSCE 824 ­ Spring 2011 15 15 Replica Control Replica Control Farkas Pessimistic replica control: at most one group can make an update – mutual consistency at all times Optimistic replica control: system must be available at all times. Correct if there is any violation of mutual consistency CSCE 824 ­ Spring 2011 16 Read One / Write All Replica Control Pessimistic approach Read the nearest replica Write all replicas – Synchronous : before transaction commits – Asynchronous case: eventually Advantage: − Mutual consistency − Performance benefits: reads transactions Disadvantage: availability is not always guaranteed E.g., Primary site approach Farkas Farkas CSCE 824 ­ Spring 2011 17 17 Primary Site – static Primary Site – static Primary site: most recent copy What happens if the network is partitioned? 1 DB1 DB0 Primary DB3 DB2 DB6 DB5 DB4 Farkas 2 CSCE 824 ­ Spring 2011 18 Majority Approach Majority Approach The group that contains the majority of the sites can process an update 1 DB0 DB3 DB1 DB2 DB5 DB4 Farkas DB6 CSCE 824 ­ Spring 2011 19 Majority Approach The group that contains the majority of the sites can process an update 2 1 DB3 DB1 DB2 DB6 DB5 DB4 Farkas Farkas (N+1)/2 DB0 CSCE 824 ­ Spring 2011 20 Majority Approach Majority Approach Farkas Advantages: more flexible than primary site Disadvantages: zero availability may still happen Who has the most recent copy? – Version number: Each site assigns a version number to the copy (initially VN=0) After an update, the VN is incremented by 1 CSCE 824 ­ Spring 2011 21 Quorum Consensus Quorum Consensus Each sites are not equal Special case of majority approach W=5 DB0 W=2 DB1 W=3 W=1 DB2 W=1 DB6 DB5 W=1 DB4 W=15 Farkas DB3 CSCE 824 ­ Spring 2011 22 Other Approaches Other Approaches Farkas Dynamic Linear: order sites linearly to calculate majority Token­based primary site (moving token): change the location of the primary site CSCE 824 ­ Spring 2011 23 Pessimistic Replica Control Pessimistic Replica Control Advantages: – Mutual consistency at all times – Know the latest version ( between two consecutive updates, there is a site in common) Disadvantage: – May result in zero availability Farkas CSCE 824 ­ Spring 2011 24 Optimistic Replica Control Optimistic Replica Control Goal: availability at all time Issues: consistency may not be guaranteed – Need an algorithm to detect whether an inconsistency occurred – Take actions to fix any inconsistencies Farkas CSCE 824 ­ Spring 2011 25 Example Optimistic Alg. Example Optimistic Alg. Farkas Two partitions P1, P2 Assumption: separately, P1 and P2 produces serializable histories Need: after P1 and P2 joins again: Detect which transactions violate global serializability CSCE 824 ­ Spring 2011 26 Example cont. Example cont. Farkas Items read by transaction T: read(T) Items written by transaction T: write(T) Assume: write(T) ⊆ read(T) Transactions in P1: T1i , in P2: T2i CSCE 824 ­ Spring 2011 27 Example cont. Example cont. Precedence graph: G – Nodes: {T11, …,T1n, T21, …, T2m} – Edges: Farkas Dependency edge (ripple effect): there is an edge Tij→ Tik if j<k and there is a data item d, s.t., d ∈ write (Tij) ∩ read(Tik) and there is no l s.t., j<l<k and d is in the write set in Til (to consider dirty read within the same partition) CSCE 824 ­ Spring 2011 28 Example cont. Example cont. Farkas Precendence edges: there is an edge Tij→ Tik if j<k and there is a data item d, s.t., d ∈ read(Tij) ∩ write(Tik) and there is no l s.t.,j<l<k and d is in the write set in Til (to consider the first transaction to write a data item after a read within the same partition) CSCE 824 ­ Spring 2011 29 Example cont. Example cont. Farkas Interference edges: there is an edge T1i→ T2j if j<k and there is a data item d, s.t., d ∈ read(T1i) ∩ write(T2j) or vice verse (to consider when T1i reads something written by T2j) CSCE 824 ­ Spring 2011 30 Example cont. Example cont. Farkas Theorem: The combined histories are correct iff the precendence graph is acyclic Correct inconsistencies: remove (undo) transactions that make the graph cyclic CSCE 824 ­ Spring 2011 31 Summary Correctness: If the transactions are ACID, local execution in serializable, distributed transactions are reliable, and update replication is synchronous then distributed transactions are globally atomic & serializable Performance: – Applications: transactions are not always serializable (e.g., WS­transactions) – Replication: update propagation is not always asynchronous Farkas Farkas Compensating transactions CSCE 824 ­ Spring 2011 32 Next Class Review distributed databases Design Concurrency control Reliability Replication Farkas Farkas CSCE 824 ­ Spring 2011 33 ...
View Full Document

This note was uploaded on 12/13/2011 for the course CSCE 824 taught by Professor Staff during the Fall '11 term at South Carolina.

Ask a homework question - tutors are online