1 / 49

ICS 214B: Transaction Processing and Distributed Data Management

ICS 214B: Transaction Processing and Distributed Data Management. Replication Techniques. Data Replication. Database node 1 node 2 node 3. item. fragment. Goals for Data replication Higher throughput Better response time Higher availability.

hector
Download Presentation

ICS 214B: Transaction Processing and Distributed Data Management

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. ICS 214B: Transaction Processing and Distributed Data Management Replication Techniques

  2. Data Replication Database node 1 node 2 node 3 item fragment Notes 14

  3. Goals for Data replication • Higher throughput • Better response time • Higher availability • Assumption: Reliable network, fail-stop nodes Notes 14

  4. Basic Solution(for Concurrency Control) • Treat each copy as an independent data item Txi Txj Txk Lock mgr X2 Lock mgr X3 Lock mgr X1 X1 X2 X3 Object X has copies X1, X2, X3 Notes 14

  5. Read(X): • get shared X1 lock • get shared X2 lock • get shared X3 lock • read one of X1, X2, X3 • at end of transaction, release X1, X2, X3 locks X1 X2 X3 read lock mgr lock mgr lock mgr Notes 14

  6. Write(X): • get exclusive X1 lock • get exclusive X2 lock • get exclusive X3 lock • write new value into X1, X2, X3 • at end of transaction, release X1, X2, X3 locks lock lock lock X1 X2 X3 write write write Notes 14

  7. RAWA (read lock all, write lock all) • Correctness OK • 2PL  serializability • Problem: Low availability down! X1 X2 X3  cannot access X! Notes 14

  8. Basic Solution — Improvement • Readers lock and access a single copy • Writers lock all copies and update all copies X1 X2 X3 reader has lock writer will conflict! Notes 14

  9. ROWA • Good availability for reads • Poor availability for writes Notes 14

  10. Reminder • With basic solution • use standard 2PL • use standard commit protocols (e.g., 2PC) Notes 14

  11. Another approach: Primary copy reader • Select primary site • All read/write locks requested at the primary site • All data read at primary • Updates are propagated to backups (using sequence numbers) • Probability a transaction blocks = prob. that primary is down • Availability is the same as the primary node X1 * X2 X3 lock write writer Notes 14

  12. Update Propagate Options • Immediate Write • Write all copies at the same time • Deferred Write • Wait until commit Notes 14

  13. Electing a new primary Backup 1 Backup n PRIMARY • Elect New Primary Pnew • Make sure Pnew has committed T0,…,Tk and has locks for Tk+1,…,Tm • Therefore, before each transaction Ti commits, we should ensure backups (potential future primaries) have Ti’s updates Committed: T1, T2, …, Tk Pending: Tk+1, …, Tm Notes 14

  14. commit (write) Distributed Commit lock, compute new value X1* X2 X3 writer prepare to write new value ok Notes 14

  15. Example X1: 0 Y1: 0 Z1: 0 * X2: 0 Y2: 0 Z2: 0 T1: X 1; Y  1; T2: Y  2; T3: Z  3; Notes 14

  16. Write(X): • Get exclusive X1* lock • Write new value into X1* • Commit at primary; get sequence number • Perform X2, X3 updates in sequence-number order ... ... Local Commit lock, write, commit X1 * X2 X3 writer propagate update Notes 14

  17. Example t = 0 X1: 0 Y1: 0 Z1: 0 * X2: 0 Y2: 0 Z2: 0 T1: X 1; Y  1; T2: Y  2; T3: Z  3; Notes 14

  18. Example t = 1 X1: 1 Y1: 1 Z1: 3 * X2: 0 Y2: 0 Z2: 0 T1: X 1; Y  1; T2: Y  2; T3: Z  3; active at node 1 waiting for lock at node 1 active at node 1 Notes 14

  19. Example t = 2 X1: 1 Y1: 2 Z1: 3 * X2: 0 Y2: 0 Z2: 0 #2: X  1; Y  1 committed active at 1 committed T1: X 1; Y  1; T2: Y  2; T3: Z  3; #1: Z  3 Notes 14

  20. Example t = 3 X1: 1 Y1: 2 Z1: 3 * X2: 1 Y2: 2 Z2: 3 #1: Z  3 #2: X  1; Y  1 #3: Y  2 committed committed committed T1: X 1; Y  1; T2: Y  2; T3: Z  3; Notes 14

  21. What good is RPWP-LC? primary backup backup updates can’t read! Answer: Can read “out-of-date” backup copy (also useful with 1-safe backups... later) Notes 14

  22. Basic Solution • Read lock all; write lock all: RAWA • Read lock one; write lock all: ROWA • Read and write lock primary: RPWP • local commit: LC • distributed commit: DC Notes 14

  23. Comparison N = number of nodes with copies P = probability that a node is operational • *: assuming the read/write waits until all sites are active • **: assuming we don’t care if other backups are active Notes 14

  24. Failures in Primary Copy model • Backup fails • Asks primary for “lost” updates • Primary fails • Data unavailable Notes 14

  25. Mobile Primary primary backup backup (1) Elect new primary (2) Ensure new primary has seen all previously committed transactions (3) Resolve pending transactions (4) Resume processing Notes 14

  26. (1) Elections • Similar to 3PC termination protocol • Nodes have IDs • Largest (or smallest) ID wins Notes 14

  27. (2) Ensure new primary has previously committed transactions primary new primary backup need to get and apply: T1, T2 committed:T1, T2  cannot use local commit Notes 14

  28. Failed Nodes: Example P1 P2 P3 now: primary backup backup -down- -down- later: -down- -down- -down- later primary backup still: commits T1 P1 P2 P3 P1 P2 P3 -down- commit T2 (unaware of T1!) Notes 14

  29. (3) Resolve pending transactions primary new primary backup T3 in “W” state T3 in “W” state T3?  should not use blocking commit Notes 14

  30. 3PC takes care of this problem! • Option A • Failed node waits for: • commit info from active node, or • all nodes are up and recovering • Option B • Majority voting Notes 14

  31. Node Recovery • All transactions have commitsequence number • Active nodes save update values“as long as necessary” • Recovering node asks active primary formissed updates; applies in order Notes 14

  32. Example: Majority Commit C2 C3 C1 state: C T1,T2,T3 T1,T2 T1,T3 P T3 T2 W T4 T4 T4 Notes 14

  33. Example: Majority Commit t1: C1 fails t2: C2 new primary t3: C2 commits T1, T2, T3; aborts T4 t4: C2 resumes processing t5: C2 commits T5, T6 t6: C1 recovers; asks C2 for latest state t7: C2 sends committed and pending transactions; C2 involves C1 in any future transactions Notes 14

  34. 2-safe vs. 1-safe Backups • Distributed commit results in 2-safe backups primary backup 1 backup 2 (1) T end work (2) send data (3) get acks (4) commit time Notes 14

  35. Guarantee • After transaction T commits at primary,any future primary will “see” T now: primary backup 1 backup 2 T1, T2, T3 later: next primary primary backup 2 T1, T2, T3 Notes 14

  36. Performance Hit • 3PC is very expensive • many messages • locks held longer (less concurrency)[Note: group commit may help] • Can use 2PC • may have blocking • 2PC still expensive[up to 1 second reported] Notes 14

  37. Alternative: 1-safe • Commit transactions unilaterally at primary • Send updates to backups as soon as possible primary backup 1 backup 2 (1) T end work (2) T commit (3) send data (4) purge data time Notes 14

  38. Problem: Lost Transactions now: primary backup 1 backup 2 T1, T2, T3 T1 T1 later: next primary primary backup 2 T1, T4 T1, T4, T5 Notes 14

  39. Claim • Lost transaction problem tolerable • failures rare • only a “few” transactions lost Notes 14

  40. Primary Recovery with 1-safe • When failed primary recovers, need to“compensate” for missed transactions now: next primary primary backup 2 T1, T2, T3 T1, T4 T1, T4, T5 later: next primary backup 3 backup 2 T1, T2, T3, T3-1, T2-1, T4, T5 T1, T4, T5 T1, T4, T5 compensation Notes 14

  41. Log Shipping • “Log shipping:” propagate updates to backup log primary backup • Backup replays log • How to replay log efficiently? • e.g., elevator disk sweeps • e.g., avoid overwrites Notes 14

  42. So Far in Data Replication • RAWA • ROWA • Primary copy • static • local commit • distributed commit • mobile primary • 2-safe (blocking or non-blocking) • 1-safe Notes 14

  43. Correctness with replicated data S1: r1[X1]  r2[X2]  w1[X1]  w2[X2]  Is this schedule serializable? X2 X1 Notes 14

  44. One copy serializable (1SR) A schedule S on replicated data is 1SR if it is equivalent to a serial history of the same transactions on a one-copy database Notes 14

  45. To check 1SR • Take schedule • Treat ri[Xj] as ri[X] Xj is copy of X wi[Xj] as wi[X] • Compute P(S) • If P(S) acyclic, S is 1SR Notes 14

  46. Example S1: r1[X1]  r2[X2]  w1[X1]  w2[X2] S1’: r1[X]  r2[X]  w1[X]  w2[X] S1 is not 1SR! T2T1 T1T2 Notes 14

  47. Second example S2: r1[X1]  w1[X1]  w1[X2] r2[X1]  w2[X1]  w2[X2] S2’: r1[X]  w1[X]  w1[X] r2[X]  w2[X]  w2[X] P(S2): Notes 14

  48. Second example S2: r1[X1]  w1[X1]  w1[X2] r2[X1]  w2[X1]  w2[X2] S2’: r1[X]  w1[X]  w1[X] r2[X]  w2[X]  w2[X] • Equivalent serial scheduleSS: Notes 14

  49. Next lecture • Multiple fragments • Network partitions Notes 14

More Related