Two Phase Commit Protocol

2단계 커밋 프로토콜...

얘기는 많이 나오는데 자세히 모르는 분들이 많을 것 같다.

컴퓨터 공학을 전공했다면, 물론 수업시간에 배웠을 내용이겠지만...

 

쓸만한 자료가 있어서 퍼 왔다.

 

-------------------------------------

 

..more

>접기

 

The Two-Phase Commit Protocol

 

The Two-Phase Commit (2PC) protocol is a simple and elegant ACP with two types of processes: A single coordinator that decides whether to reach a global commit or abort decision, and the participants that execute the transaction's resource accesses and vote whether to commit or abort. The commit decision is made according to the global commit rule [11]:

-

If even one participant votes to abort the transaction, the coordinator has to reach a global abort decision.

-

If all participants vote to commit the transaction, the coordinator has to reach a global commit decision.

A description of 2PC that does not consider failures is provided in this section. Failure scenarios and a recovery protocol is described in section 2.6.2. Figure 2 should be helpful: The circles represent states, the whole lines represent state changes, the dashed lines represent messages (labeled with the message types), and the rectangles represent logging actions.

 

 

Figure 2: The Two-Phase Commit protocol

 

2PC has, not surprisingly, two phases:

 

Phase 1: A coordinator process is started (usually at the site where the transaction is initialized), writes a begin commit record in its log, sends a prepare message to the participants, and enters the wait state. This message also contains a unique transaction id (TID), which is also in all further messages in this protocol run.

 

When a participant receives a prepare message, it checks if it can commit the transaction. If it can, the participant writes a ready record in its log, sends a vote_commit message to the coordinator, and enters the ready state. Otherwise, the participants decides to unilaterally abort¹⁰ the transaction--it writes an abort record in the log and sends a vote_abort message to the coordinator. It enters the abort state and can forget about the transaction.

 

Phase 2: After the coordinator has received votes from all participants it decides whether to commit or abort according to the global commit rule, and writes this decision in the log. If the decision is to commit, it sends a global_commit message to all sites. Otherwise, it sends a global_abort message to all sites that voted to commit. Finally, it writes an end of transaction record in its log. The participants finish the transaction according to the decision and write the result in their logs [11].

 

To be accurate, the protocol described here is centralized 2PC with reliable message channels. There are many variations on 2PC that account for different network topologies, channel reliability and synchrony. These will not be discussed further here, as the described protocol is usable in our network model (see section 2.1) and strikes a balance between few messages and high concurrency.

 

출처 : http://www.vermicelli.pasta.cs.uit.no/ipv6/students/andrer/doc/html/node18.html

------------------------------------------------------------------------

 

윗 글은 2단계 커밋 프로토콜에 대한 설명이고... 아래 글은 각 단계에서의 오류 발생 시 처리되는 것에 대한 설명이다.

 

Failure scenarios and a recovery protocol for 2PC

 

In this section we will describe all possible crash failures of the coordinator and participant processes in the protocol described in section 2.6.1 and how to recover from them, i.e. we will describe the recovery protocol, which is adapted from [11] to fit our asynchronous store-and-forward network. We still assume that messages are never lost (although they can take an arbitrarily long time to arrive at their destination). Note that if a process fails during message transmission, we regard the message as unsent, and if a process fails during logging, the last entry in the log is invalid and not used for restoring state. Figure 2 should still be helpful. First, the coordinator:

1. The coordinator fails in the initial state: The coordinator must simply be restarted and reinitialized.
2. The coordinator fails after the begin commit record is written to the log but before the prepare command is sent: On recovery, the coordinator knows from the log that the commit process is started, but it does not know whether the prepare command has been sent, so it must be (re)transmitted. Note that this may cause duplicate messages. We will explain later how this protocol can be implemented in a manner that makes duplicate messages harmless.
3. The coordinator fails while in the wait state: If there are votes on the channel, it must have sent the prepare command, so it can reenter the wait state. If not, the coordinator does not know if it has sent the prepare command, so it is (re)transmitted.
4. The coordinator fails after logging its final decision, but before informing the participants of the decision: The decision has been recorded on the log, so it only needs to transmit it to the participants.
5. The coordinator fails in the commit or abort states: The decision is already logged and broadcast, so it only needs to write an end of transaction record in the log.

Then the failures and recovery for the participant:

1. The participant fails in the initial state: The participant will automatically be restarted when the system is restarted, and it will find the prepare message on the channel.
2. The participant fails after writing the abort record in the log but before sending vote_abort: Simply retransmit the vote_abort message.
3. The participant fails in the ready state: If there is a global_commit or global_abort message on the channel, act on it. Otherwise, (re)transmit the vote_commit message.
4. The participant fails while writing the data to be committed: The participant still has locks on the items the transaction is executed on, so it can just rewrite the data (which will be available on the channel).
5. The participant fails in the abort or commit states: The transaction is complete, so nothing needs to be done.

We see that with an asynchronous reliable store-and-forward channel we can, given enough time, recover from any site failure without using a termination protocol.

 

출처 : http://www.vermicelli.pasta.cs.uit.no/ipv6/students/andrer/doc/html/node19.html#sec:thf:acp:rcp