(c) Oded Shmueli 20041 Distributed Recovery, Lecture 7 (BHG, Chap.7)

Slides:



Advertisements
Similar presentations
Two phase commit. Failures in a distributed system Consistency requires agreement among multiple servers –Is transaction X committed? –Have all servers.
Advertisements

6.852: Distributed Algorithms Spring, 2008 Class 7.
CS542: Topics in Distributed Systems Distributed Transactions and Two Phase Commit Protocol.
CS 603 Handling Failure in Commit February 20, 2002.
Nummenmaa & Thanish: Practical Distributed Commit in Modern Environments PDCS’01 PRACTICAL DISTRIBUTED COMMIT IN MODERN ENVIRONMENTS by Jyrki Nummenmaa.
1 ICS 214B: Transaction Processing and Distributed Data Management Lecture 12: Three-Phase Commits (3PC) Professor Chen Li.
Consensus Algorithms Willem Visser RW334. Why do we need consensus? Distributed Databases – Need to know others committed/aborted a transaction to avoid.
CIS 720 Concurrency Control. Timestamp-based concurrency control Assign a timestamp ts(T) to each transaction T. Each data item x has two timestamps:
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg This material is made available for private study and for direct.
Computer Science Lecture 18, page 1 CS677: Distributed OS Last Class: Fault Tolerance Basic concepts and failure models Failure masking using redundancy.
E-Transactions: End-to-End Reliability for Three-Tier Architectures Svend Frølund and Rachid Guerraoui.
ICS 421 Spring 2010 Distributed Transactions Asst. Prof. Lipyeow Lim Information & Computer Science Department University of Hawaii at Manoa 3/16/20101Lipyeow.
Distributed Transaction Processing Some of the slides have been borrowed from courses taught at Stanford, Berkeley, Washington, and earlier version of.
Termination and Recovery MESSAGES RECEIVED SITE 1SITE 2SITE 3SITE 4 initial state committablenon Round 1(1)CNNN-NNNN Round 2FAILED(1)-CNNN--NNN Round 3FAILED.
Transaction Processing Lecture ACID 2 phase commit.
Systems of Distributed Systems Module 2 -Distributed algorithms Teaching unit 3 – Advanced algorithms Ernesto Damiani University of Bozen Lesson 6 – Two.
Computer Science Lecture 17, page 1 CS677: Distributed OS Last Class: Fault Tolerance Basic concepts and failure models Failure masking using redundancy.
Non-blocking Atomic Commitment Aaron Kaminsky Presenting Chapter 6 of Distributed Systems, 2nd edition, 1993, ed. Mullender.
The Atomic Commit Problem. 2 The Problem Reaching a decision in a distributed environment Every participant: has an opinion can veto.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
Chapter 18: Distributed Coordination (Chapter 18.1 – 18.5)
1 CS 194: Distributed Systems Distributed Commit, Recovery Scott Shenker and Ion Stoica Computer Science Division Department of Electrical Engineering.
CS 603 Three-Phase Commit February 22, Centralized vs. Decentralized Protocols What if we don’t want a coordinator? Decentralized: –Each site broadcasts.
©Silberschatz, Korth and Sudarshan19.1Database System Concepts Distributed Transactions Transaction may access data at several sites. Each site has a local.
1 ICS 214B: Transaction Processing and Distributed Data Management Distributed Database Systems.
Distributed Commit. Example Consider a chain of stores and suppose a manager – wants to query all the stores, – find the inventory of toothbrushes at.
CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture XI: Distributed Transactions.
CMPT Dr. Alexandra Fedorova Lecture XI: Distributed Transactions.
1 Formal Models for Distributed Negotiations Commit Protocols Roberto Bruni Dipartimento di Informatica Università di Pisa XVII Escuela de Ciencias Informaticas.
CMPT Dr. Alexandra Fedorova Lecture XI: Distributed Transactions.
Commit Protocols. CS5204 – Operating Systems2 Fault Tolerance Causes of failure: process failure machine failure network failure Goals : transparent:
Distributed Commit Dr. Yingwu Zhu. Failures in a distributed system Consistency requires agreement among multiple servers – Is transaction X committed?
CS162 Section Lecture 10 Slides based from Lecture and
Distributed Transactions March 15, Transactions What is a Distributed Transaction?  A transaction that involves more than one server  Network.
Distributed Txn Management, 2003Lecture 3 / Distributed Transaction Management – 2003 Jyrki Nummenmaa
Chapter 19 Recovery and Fault Tolerance Copyright © 2008.
Distributed Transactions Chapter 13
Distributed Transaction Recovery
Distributed Txn Management, 2003Lecture 4 / Distributed Transaction Management – 2003 Jyrki Nummenmaa
Consensus and Its Impossibility in Asynchronous Systems.
Operating Systems Distributed Coordination. Topics –Event Ordering –Mutual Exclusion –Atomicity –Concurrency Control Topics –Event Ordering –Mutual Exclusion.
Distributed Transaction Management, Fall 2002Lecture Distributed Commit Protocols Jyrki Nummenmaa
Fault Tolerance CSCI 4780/6780. Distributed Commit Commit – Making an operation permanent Transactions in databases One phase commit does not work !!!
University of Tampere, CS Department Distributed Commit.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved Chapter 8 Fault.
XA Transactions.
Commit Algorithms Hamid Al-Hamadi CS 5204 November 17, 2009.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved Chapter 8 Fault.
Committed:Effects are installed to the database. Aborted:Does not execute to completion and any partial effects on database are erased. Consistent state:
Two-Phase Commit Brad Karp UCL Computer Science CS GZ03 / M th October, 2008.
1 Advanced Database Topics Copyright © Ellis Cohen Concurrency Control for Distributed Databases These slides are licensed under a Creative Commons.
Revisiting failure detectors Some of you asked questions about implementing consensus using S - how does it differ from reaching consensus using P. Here.
Multi-phase Commit Protocols1 Based on slides by Ken Birman, Cornell University.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
Topics in Distributed Databases Database System Implementation CSE 507 Some slides adapted from Navathe et. Al and Silberchatz et. Al.
Chapter 8 – Fault Tolerance Section 8.5 Distributed Commit Heta Desai Dr. Yanqing Zhang Csc Advanced Operating Systems October 14 th, 2015.
Distributed Databases – Advanced Concepts Chapter 25 in Textbook.
Outline Introduction Background Distributed DBMS Architecture
Database System Implementation CSE 507
Two phase commit.
Commit Protocols CS60002: Distributed Systems
RELIABILITY.
Outline Introduction Background Distributed DBMS Architecture
Outline Announcements Fault Tolerance.
Assignment 5 - Solution Problem 1
Distributed Transactions
Distributed Databases Recovery
CIS 720 Concurrency Control.
Last Class: Fault Tolerance
Presentation transcript:

(c) Oded Shmueli Distributed Recovery, Lecture 7 (BHG, Chap.7)

(c) Oded Shmueli Types of Failures Site failure – assume all or nothing (fail-stop). Total failure – all sites fail. Partial failure – some sites fail. Communication failure:  corruption.  broken kink.  network partition. Undelivered messages are dropped (assumption). Detecting failures via timeouts. Timeout failures are possible.

(c) Oded Shmueli Atomic Commitment Model: Coordinator, participants, local DM that uses some recovery scheme. Each site has a distributed transaction log – DT. ACP: Atomic Commitment Protocol  A participant can vote Yes or No.  Either all processes commit or all abort.

(c) Oded Shmueli ACP Requirements All Processes that reach a decision reach the same decision. A process cannot reverse a decision once it reached it. The Commit decision can only be reached if all processes voted YES. If there are no failures and all processes voted Yes then the decision will be Commit. Consider an execution with failures tolerable by the algorithm. If all current failures are repaired and none occurs thereafter, all process will eventually reach a decision.

(c) Oded Shmueli Blocking, Uncertainty Uncertainty period – between voting Yes and being able to know a definite decision. Blocked – a condition describing a process that cannot proceed to abort or commit until some failures are first repaired. Independent recovery – the ability of a recovering process to reach a decision concerning a transaction without communicating with other sites.

(c) Oded Shmueli Impossibility Results If communication failures or total failures are possible, then every ACP may cause processes to become blocked. (An ACP in presence of site failures – but not total site failures- does exist). No ACP can guarantee independent recovery of failed processes.

(c) Oded Shmueli Two Phase Commit (2PC) Voting phase:  Coordinator sends vote request to participants.  Participants respond with Yes or No. Decision phase:  If all votes are Yes, the coordinator decides to commit.  If any vote is No, the coordinator decides to abort. Timeout actions are taken when processes expect messages for ‘too long’. These actions may include a termination protocol, designed to conclude (although it may be blocked) the status of a transaction. There may be a number of possible communication topologies.

(c) Oded Shmueli The 2PC Algorithm Figure 7-3. Figure 7-4. Note the small bug.

(c) Oded Shmueli Three Phase Commit (3PC) Version 1: Non-blocking in presence of site failure but not in presence of communication failures or total site failure. Version 2: Can handle both communication and site failure, can block. Still, blocking is less frequent. We will not cover this version. Both versions are considered “impractical” due to message and round overhead. But, they are interesting and reveal many intricacies.

(c) Oded Shmueli PC – Assumptions and Invariant Major assumption: no communication failures, only site failures:  time out  process is down.  all operational process can communicate with each other. Invariant NB: If any operational process is uncertain then no process (whether operational or failed) can have decided to commit.

(c) Oded Shmueli PC Stages – No Failures 1)Coordinator sends VOTE-REQ to participants. 2)Participant responds with YES or NO (decides abort and stops). 3)Any NO votes or coordinator says NO  decide abort, send ABORT to all YES voters. Otherwise – send PRE-COMMIT to all. 4)Participants wait for ABORT or PRE-COMMIT: 1)ABORT: decide abort and stop. 2)PRE-COMMIT: Respond with ACK. 5)When all ACK arrive, Coordinator sends COMMIT. 6)A participant waits for COMMIT. Upon receipt, it decides commit and stops.

(c) Oded Shmueli Failures  Timeouts  Actions 1. Participant waits for VOTE-REQ: unilateral abort. 2. Coordinator waits for a vote: decide abort and send ABORT to all. 3. Participant waits for PRE-COMMIT or ABORT: Communicate with other processes so as to reach a consistent decision. 4. Coordinator waits for ACKS: Coordinator knows the failed participants voted YES. Coordinator ignores failure, sends COMMITS. So, processes may decide commit when failed processes are uncertain. NB is maintained.

(c) Oded Shmueli Failures  Timeouts  Actions 5. Participant p waits for COMMIT: 1. Communicate with other processes so as to reach a consistent decision. 2. Why shouldn’t p just commit? Reason: some other process might not have received the PRE- COMMIT. It is uncertain. Committing would violate NB.

(c) Oded Shmueli The 3PC Algorithm Figure Figure 7-11.

(c) Oded Shmueli States Aborted: not voted, voted NO, or received ABORT. So it either decided ABORT or can unilaterally decide abort. Uncertain: voted YES, has not received PRE- COMMIT. Committable: received PRE-COMMIT, has not received COMMIT. Committed: received COMMIT and decided COMMIT.

(c) Oded Shmueli State Compatibility AbortedUncertainCommittableCommitted Aborted YYNN Uncertain YYN Committable YY Committed Y

(c) Oded Shmueli Participant Termination Protocol Initialize an election protocol to elect a new coordinator. Coordinator sends STATE-REQ to all operational processes. Participants send their state information. Coordinator applies termination rules and decides to commit or abort. If new coordinator fails, another will be elected … Processes that failed do not participate in the termination protocol when they recover.

(c) Oded Shmueli Termination Rules 1. If some process is Aborted, decide abort, send ABORT messages. 2. If some process is Committed, decide commit, send COMMIT messages. 3. If all reporting processes are Uncertain, decide abort, send ABORT messages. 4. If some process is committable and none is Committed: 1. Send PRE-COMMIT to all Uncertain processes. 2. Wait for ACKS. 3. After receiving ACKS, decide commit, send COMMIT messages to all processes. Ignore non-responders. Note: Exactly one of 1-4 will apply.

(c) Oded Shmueli Recovering from non-total Failure A process recovers from failure. DT log records significant events. Extracts its state from the DT log. Can unilaterally recover if never voted YES, has received COMMIT or ABORT. Voted YES but has not received ABORT or COMMIT. Asks for help.  What if it has received PRE-COMMIT, can it decide unilaterally? No, the failure could have happened so that the operational processes decided to abort …

(c) Oded Shmueli Recovering from Total Failure Total failure – all processes. Suppose p recovers. If p failed while Uncertain and was not the last to fail, it cannot recover independently. So, p must wait for some q to recover that can make this decision. Process q either decided already or starts the termination protocol. Recovered processes will decide this way. Without the last process to have failed, inconsistent decisions may be reached.

(c) Oded Shmueli Election Protocol Each process maintains a list UP of live processes. If a process detects another process is failed, it removes that process from its UP list. If a process detects the coordinator failed, it sends URELECTED to highest numbered UP process. The elected coordinator starts requesting states. Other processes may deduce the change of guards once they receive STATE-REQ from the new coordinator.

(c) Oded Shmueli Determining the Last Process to Fail The UP sets are kept in stable storage. UPi helps a set of processes, Pi, in determining whether the last process to fail is among them. A set R of processes contains the last process to fail iff R   Pi  R UP i.

(c) Oded Shmueli Correctness. See BHG.