Post on 27-Apr-2015
transcript
Distributed Database SystemsAutumn, 2007
Chapter 12 – Part 3 of 3
Distributed DBMS Reliability
1Distributed Database Systems
12.1 Reliability Concepts And Measures12.2 Failures And Fault Tolerance In
Distributed Systems12.3 Failures In Distributed DBMS12.4 Local Reliability Protocols12.5 Distributed Reliability Protocols
Distributed Database Systems 2
Dealing with Site FailuresSection 12.6
Distributed Database Systems 3
Problem with 2PC2PC is designed for dealing with system crashes.
Distributed Database Systems 4
Failed site can properly recover without consulting other sites.
Operational site can properly terminate properly without waiting for the recovery of failed site.
Independent recovery and non-blocking protocols exist only for single-site failures.
Problem with 2PC
2PC is inherently blocking !
Distributed Database Systems 5
Subsection 12.6.1
Termination and Recovery Protocols of 2PC
State transition in 2PC protocol
Distributed Database Systems 7
Coordinator time-outsThe coordinator can time-out in WAIT, ABORT, and COMMIT states.
WAIT◦ The coordinator is waiting for the local
decisions from the participants.◦ Solution: the coordinator decides to globally
abort the transaction by writing an abort record in the log, and sending a global abort to all participants
Distributed Database Systems 8
Coordinator time-outs
COMMIT or ABORT◦ The coordinator is not certain if the commit
or abort procedures have been completed by the LRMs of all participants.◦ Solution: resend the "global-commit" or
"global abort" to the site that have not acknowledged.
Distributed Database Systems 9
Participant time-outsA participant can time-out in INITIAL or READY states.INITIAL◦ The participant is waiting for a “prepare” message.◦ The coordinator must have failed in INITIAL state.◦ Solution: the participant unilaterally aborts the
transaction. If the "prepare" message arrives later. It can be responded by
vote abort, orjust ignoring the message. This causes the time-out of the coordinator in the WAIT state (see the previous discussion for this case).
Distributed Database Systems 10
Participant time-outsREADY◦ The participant must have "voted commit" and
therefore cannot change it and unilaterally abort it.◦ Solution: blocked until it can learn (from the
coordinator or other participants) the ultimate fate of the transaction.
In centralized communication structure, a participant has to ask the coordinator for its decision. If the coordinator failed, the participant will remain blocked.
Distributed Database Systems 11
Can blocking problem be overcome?
No!2PC is an inherently blocking protocol.
Distributed Database Systems 12
Analysis
Assumptions and definitions
Assume participants can communicate each other.Let Pi be the participant that time-outs in the READY state, and Pj be the participant to be asked.
Distributed Database Systems 14
All the cases that Pj can respond1. Pj is in the INITIAL state. This means Tj has
not voted yet. Pj can unilaterally abort the transaction and reply to Pi with a “vote-abort” message.
2. Pj is in the READY state. Pj does not know the global decision and cannot help.
3. Pj is in COMMIT or ABORT state. Pj can send global "vote-commit" or global "vote-abort" to Pi.
Distributed Database Systems 15
How Pi interprets these responses
1. Pi receives “vote-abort” from all Pj. Pi just proceed to abort the transaction.
2. Pi receives "vote-abort" from some Pj, but some other participants are in READY state. Pi go ahead and abort the transaction.
3. Pi receives the information that all Pj are READY. Pi is blocked, since it has no knowledge about the global decision.
Distributed Database Systems 16
How Pi interprets these responses
4. Pi receives either “global-abort” or “global-commit” messages from all Pj. Pi can go ahead and terminate the transaction according to the message.
5. Pi receives either “global-abort” or “global-commit” messages from some Pj, but others are in READY. Pi takes action same as (4).
Distributed Database Systems 17
These are all the alternatives that a termination protocol needs to handle.
Recovery protocols
The protocols that a failed coordinator or participant can use to recover when they restart.Assuming: 1. Writing log and sending messages are in an
atomic action,2. The state transition occurs after message
sending.
Distributed Database Systems 18
Coordinator site failureThe coordinator fails while in the INITIAL state.◦ Action: restart the transaction.
The coordinator fails while in the WAIT state.◦ Action: restart the commit process by sending the
“prepare” message once more.
The coordinator fails while in the COMMIT or ABORT state.◦ Action: If all ACK messages have been received, then
no action is needed; otherwise follow the termination protocols.
Distributed Database Systems 19
Participant site failuresA participant fails while in the INITIAL state.◦ Action: Upon recovery the participant should abort
the transaction unilaterally.
A participants fails while in the READY state.◦ Action: Same as time-out in the READY state and
follow its termination protocols (ask for help).
A participant fails while in the ABORT or COMMIT state.◦ Action: No action.
Distributed Database Systems 20
Additional casesThe first assumption of recovery protocols is relaxed, i.e. it is possible to fail after writing log but before sending a message to a site.The coordinator fails after begin_commit is written in the log but before the "prepare" message is sent.◦ Action: Same as a failure in the WAIT state, and send
the “prepare” message upon recovery.
All other additional cases can be treated on the basis on techniques discussed in this chapter.
Distributed Database Systems 21
Subsection 12.6.2
Three-Phase Commit Protocol
3PC – A non-blocking protocol
A commit protocol that is synchronous within one state transition is non-blockingif and only if its state transition diagram contains neither of following:1. A state that is adjacent to both commit and
abort state;2. A non-commitable state that is adjacent to
a commit state.
Distributed Database Systems 23
Action diagramCOMMIT – commitablestateWAIT, READY – non-commitable stateAdd a PRE-COMMITstate between WAIT and COMMIT for the coordinator, and between REDAY and COMMIT for participants.
Distributed Database Systems 24
State transitions
Distributed Database Systems 25
Termination protocolCoordinator time-out1. In the WAIT state
Same as in 2PC. The coordinator unilaterally aborts the transaction and send a “global abort” message to all participants that have voted to commit.
2. In the PRE-COMMIT stateAll participant must at least be in READY state (have voted to commit).The coordinator globally commit the transaction and send GC message to all operational participants.
3. In the COMMIT (or ABORT) stateNo action to take.
Distributed Database Systems 26
Termination protocolParticipants time-out1. In the INTIAL state
Same as 2PC.
2. In the READY stateThe participant does not know the global decision.Elect a new coordinator and the new coordinator terminates the transaction according to the termination protocols to be discussed below.
3. In the PRE-COMMIT stateThe participant is waiting for the "global commit" message from the coordinator.Solution: same as case 2.
Distributed Database Systems 27
For above case 2 and 3The new coordinator (elected from old participants) may be in WAIT, PRE-COMMIT, or ABORT sate.If the new coordinator is in WAIT, it will globally abort the transaction. The participants may be in◦ INITIAL
◦ READY
◦ ABORT
PRE-COMMIT: add an edge from PRE-COMMIT to ABORT
Distributed Database Systems 28
No problem for taking global or abort action
For above case 2 and 3If the new coordinator is in the PRE-COMMIT state, the participants can be in PRE-COMMIT or COMMIT (but no one can be in ABORT).◦ Solution: globally commit the transaction and send a
GC message to all participants.
If the new coordinator is in ABORT, all participants have to move to abort.
Distributed Database Systems 29
Recovery Protocols
The coordinator fails while in WAITThis causes participants time-out (see above discussion)◦ Solution: the recovered coordinator asks around to determine
the fate of the transaction.
The coordinator fails while in the PRE-COMMIT state.This causes participants time-out in the PRE-COMMIT state.◦ Solution: ask around upon recovery.
A participant fails while in the PRE-COMMIT state.◦ Solution: ask other participants when recovered.
Distributed Database Systems 30
Only indicate the differences from those in 2PC.
More about 3PC
Advantages
◦ non-blockingDisadvantages
◦ Fewer independent recovery cases◦More messages
Distributed Database Systems 31
Network PartitioningSection 12.7
Distributed Database Systems 32
Network PartitioningSimple partitioning◦ The network is partitioned into two parts.
Multiple partitioning◦ More than two parts.
In general, it is not possible to find a non-blocking termination protocols in the presence of network partitioning.It is possible to design an atomic non-blocking protocols that are resilient to simple partitioning.
Distributed Database Systems 33
Design decision
Allow partitions to continue their operations and compromise database consistency, orGuarantee the consistency by permitting one partition work, while the sites in other partitions remain blocked.
Distributed Database Systems 34
The End of Chapter 12