1. Distributed DBMSPage 10-12. 1© 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database Design Distributed Query Processing Distributed Transaction Management  Transaction Concepts and Models  Distributed Concurrency Control  Distributed Reliability n Building Distributed Database Systems (RAID) Mobile Database Systems Privacy, Trust, and Authentication Peer to Peer Systems

2. Distributed DBMSPage 10-12. 2© 1998 M. Tamer Özsu & Patrick Valduriez Useful References D. Skeen and M Stonebraker, A Formal Model of Crash Recovery in a Distributed System, IEEE Trans. Software Eng. 9(3): 219-228, 1983. D. Skeen, A Decentralized Termination Protocol, IEEE Symposium on Reliability in Distributed Software and Database Systems, July 1981.

3. Distributed DBMSPage 10-12. 3© 1998 M. Tamer Özsu & Patrick Valduriez Byzantine General Problem Two generals are situated on adjacent hills and enemy is in the valley in between. Enemy can defeat either general, but not both. To succeed, both generals must agree to either attack or retreat. The generals can communicate via messengers who are subject to capture or getting lost. The general may themselves be traitors or send inconsistent information.

4. Distributed DBMSPage 10-12. 4© 1998 M. Tamer Özsu & Patrick Valduriez Byzantine Agreement Problem of a set of processors to agree on a common value for an object. Processors may fail arbitrarily, die and revive randomly, send messages when they are not supposed to etc.

5. Distributed DBMSPage 10-12. 5© 1998 M. Tamer Özsu & Patrick Valduriez Atomicity Control from Book Commit protocols  How to execute commit command for distributed transactions.  Issue: how to ensure atomicity and durability? Termination protocols  If a failure occurs, how can the remaining operational sites deal with it.  Non-blocking : the occurrence of failures should not force the sites to wait until the failure is repaired to terminate the transaction. Recovery protocols  When a failure occurs, how do the sites where the failure occurred deal with it.  Independent : a failed site can determine the outcome of a transaction without having to obtain remote information. Independent recovery  non-blocking termination

6. Distributed DBMSPage 10-12. 6© 1998 M. Tamer Özsu & Patrick Valduriez Committed:Effects are installed to the database. Aborted:Does not execute to completion and any partial effects on database are erased. Consistent state: Derived state from serial execution. Inconsistency caused by: 1.Concurrently executing transaction. 2.Failures causing partial or incorrect execution of a transaction. General Terminology for Commit/Termination/Recovery Protocols

7. Distributed DBMSPage 10-12. 7© 1998 M. Tamer Özsu & Patrick Valduriez General Terminology for Commit/Termination/Recovery Protocols Commit protocols  Protocols for directing the successful execution of a simple transaction Termination protocols  Protocols at operational site to commit/abort an unfinished transaction after a failure Recovery protocols  Protocols at failed site to complete all transactions outstanding at the time of failure

8. Distributed DBMSPage 10-12. 8© 1998 M. Tamer Özsu & Patrick Valduriez General Terminology for Commit/Termination/Recovery Protocols Distributed Crash Recovery:  Centralized Protocols  Hierarchical Protocols  Linear Protocols  Decentralized Protocols Phase:  Consists of a message round where all Sites exchange messages. Two Phase Commit Protocol:  ARGUS, LOCUS, INGRES Four Phase Commit Protocol:  SSD-1 Quorum:  Minimum number of sites needed to proceed with an action

9. Distributed DBMSPage 10-12. 9© 1998 M. Tamer Özsu & Patrick Valduriez Commit/Termination Protocols Two Phase Commit Three Phase Commit Four Phase Commit Linear, Centralized, Hierarchical, Decentralized Protocols

10. Distributed DBMSPage 10-12. 10© 1998 M. Tamer Özsu & Patrick Valduriez Two Phase Commit Site 1Site 2 1.Trans. arrives. Message to ask for vote is sent to other site(s) Message is recorded. Site votes Y or N (abort) Vote is sent to site 1 2.The vote is received. If vote = Y on both sites, then Commit else Abort Either Commit or Abort based on the decision of site 1

11. Distributed DBMSPage 10-12. 11© 1998 M. Tamer Özsu & Patrick Valduriez Two-Phase Commit (2PC) Phase 1 : The coordinator gets the participants ready to write the results into the database Phase 2 : Everybody writes the results into the database  Coordinator :The process at the site where the transaction originates and which controls the execution  Participant :The process at the other sites that participate in executing the transaction Global Commit Rule:  The coordinator aborts a transaction if and only if at least one participant votes to abort it.  The coordinator commits a transaction if and only if all of the participants vote to commit it.

12. Distributed DBMSPage 10-12. 12© 1998 M. Tamer Özsu & Patrick Valduriez Local Protocols for the Centralized Two-Phase Commit Protocol q1q1 w1w1 a1a1 c1c1 c2c2 xact request start xact yes abort yes commit a2a2 no w2w2 q2q2 start xact yes start xact no abort commit Site 1 (co-ordinator) Site 2 (slave)

13. Distributed DBMSPage 10-12. 13© 1998 M. Tamer Özsu & Patrick Valduriez Decentralized Two-Phase Commit Protocol cici aiai wiwi qiqi xact no i1 no in xact yes i1 yes in … … no 1i | |no ni … yes 1i | |yes ni … Site i (i = 1,2,…n) send receive

14. Distributed DBMSPage 10-12. 14© 1998 M. Tamer Özsu & Patrick Valduriez Centralized 2PC (see book) ready?yes/nocommit/abort?commited/aborted Phase 1Phase 2 CCC P P P P P P P P

15. Distributed DBMSPage 10-12. 15© 1998 M. Tamer Özsu & Patrick Valduriez SDD-1 Four-Phase Commit Protocol q1q1 a1’a1’c1’c1’ w1’w1’ w1w1 a1a1 c1c1 c2c2 a2a2 q2q2 w2w2 Site 1 (co-ordinator) Site 2 (back-up) request xact 2 act 2 xact 3 xact 4 abort 2 act 2 commit 2 act 2 yes 3 yes 4 commit 2 no 3 |no 4 abort 2 ack 2 commit 3 commit 4 ack 2 abort 3 abort 4 cici aiai wiwi qiqi xact i no i xact i yes i … abort i commit i Site i (i = 3,4) (slave)

16. Distributed DBMSPage 10-12. 16© 1998 M. Tamer Özsu & Patrick Valduriez 2PC Protocol Actions (see book) Participant Coordinator No Yes VOTE-COMMIT Yes GLOBAL-ABORT No write abort in log Abort Commit ACK INITIAL write abort in log write ready in log write commit in log Type of msg WAIT Ready to Commit? write commit in log Any No? write abort in log ABORTCOMMIT ABORT write begin_commit in log write end_of_transaction in log READY INITIAL PREPARE VOTE-ABORT VOTE-COMMIT

17. Distributed DBMSPage 10-12. 17© 1998 M. Tamer Özsu & Patrick Valduriez Linear 2PC PrepareVC/VA Phase 1 Phase 2 GC/GA VC/VA VC: Vote-Commit, VA: Vote-Abort, GC: Global-commit, GA: Global-abort 12345N GC/GA

18. Distributed DBMSPage 10-12. 18© 1998 M. Tamer Özsu & Patrick Valduriez State Transitions in 2PC (see book) INITIAL WAIT Commit command Prepare Vote-commit (all) Global-commit INITIAL READY Prepare Vote-commit Global-commit Ack Prepare Vote-abort Global-abort Ack Coordinator Participants Vote-abort Global-abort ABORTCOMMIT ABORT

19. Distributed DBMSPage 10-12. 19© 1998 M. Tamer Özsu & Patrick Valduriez Site Failures - 2PC Termination (see book) Timeout in INITIAL  Who cares Timeout in WAIT  Cannot unilaterally commit  Can unilaterally abort Timeout in ABORT or COMMIT  Stay blocked and wait for the acks COORDINATOR INITIAL WAIT Commit command Prepare Vote-commit Global-commit ABORTCOMMIT Vote-abort Global-abort

20. Distributed DBMSPage 10-12. 20© 1998 M. Tamer Özsu & Patrick Valduriez Timeout in INITIAL  Coordinator must have failed in INITIAL state  Unilaterally abort Timeout in READY  Stay blocked Site Failures - 2PC Termination INITIAL READY Prepare Vote-commit Global-commit Ack Prepare Vote-abort Global-abort Ack ABORTCOMMIT PARTICIPANTS

21. Distributed DBMSPage 10-12. 21© 1998 M. Tamer Özsu & Patrick Valduriez Site Failures - 2PC Recovery Failure in INITIAL  Start the commit process upon recovery Failure in WAIT  Restart the commit process upon recovery Failure in ABORT or COMMIT  Nothing special if all the acks have been received  Otherwise the termination protocol is involved COORDINATOR INITIAL WAIT Commit command Prepare Vote-commit Global-commit ABORTCOMMIT Vote-abort Global-abort

22. Distributed DBMSPage 10-12. 22© 1998 M. Tamer Özsu & Patrick Valduriez Failure in INITIAL  Unilaterally abort upon recovery Failure in READY  The coordinator has been informed about the local decision  Treat as timeout in READY state and invoke the termination protocol Failure in ABORT or COMMIT  Nothing special needs to be done INITIAL READY Prepare Vote-commit Global-commit Ack Prepare Vote-abort Global-abort Ack ABORT COMMIT PARTICIPANTS Site Failures - 2PC Recovery