Distributed Systems Course Distributed transactions 13 1 Introduction
Distributed Systems Course Distributed transactions 13. 1 Introduction 13. 2 Flat and nested distributed transactions 13. 3 Atomic commit protocols 13. 4 Concurrency control in distributed transactions 13. 5 Distributed deadlocks 13. 6 Transaction recovery
Commitment of distributed transactions - introduction a distributed transaction refers to a flat or nested transaction that accesses objects managed by multiple servers When a distributed transaction comes to an end – the either all of the servers commit the transaction – or all of them abort the transaction. one of the servers is coordinator, it must ensure the same outcome at all of the servers. the ‘two-phase commit protocol’ is the most commonly used protocol for achieving this 2 •
Distributed transactions (a) Flat transaction (b) Nested transactions M In a nested transaction, the top-X level transaction can open subtransactions, and each subtransaction can open further subtransactions T down to any Y depth of nesting T 11 X Client T 1 N T 12 T T T 21 T 2 Client Y In the nested case, Z subtransactions at the same level can run concurrently, so T 1 and T 2 are concurrent, and as they invoke objects in different servers, they can run in parallel. P Figure 13. 1 T 22 A flat client transaction completes each of its requests before going on to the next one. Therefore, each transaction accesses • servers’ objects sequentially 3
Nested banking transaction X Client A T 1 T T = open. Transaction requests can be runopen. Sub. Transaction ina. withdraw(10); parallel withopen. Sub. Transaction several b. withdraw(20); servers, the open. Sub. Transaction nested c. deposit(10); open. Sub. Transaction transaction is d. deposit(20); more efficient close. Transaction Figure 13. 2 Y T 2 a. withdraw(10) B b. withdraw(20) C c. deposit(10) D d. deposit(20) Z T T 3 4 client transfers $10 from A to C and then transfers $20 from B to 4 •
Why might a participant abort a transaction? The coordinator of a flat distributed transaction Servers execute requests in a distributed transaction – when it commits they must communicate with one another to coordinate their actions – a client starts a transaction by sending an open. Transaction request to a coordinator in any server (next slide) w it returns a TID unique in the distributed system(e. g. server ID + local transaction number) w at the end, it will be responsible for committing or aborting it – each server managing an object accessed by the transaction is a participant - it joins the transaction (next slide) w a participant keeps track of objects involved in the transaction w at the end it cooperates with the coordinator in carrying out the commit protocol – note that a participant can call abort. Transaction in coordinator 5 •
A flat distributed banking a client’s (flat) banking transaction involves accounts A, B, C and D at servers Branch. X, Branch. Y and Branch. Z open. Transaction goes to the transactioncoordinator join open. Transaction close. Transaction. A a. withdraw(4); join Branch. X T Client Each. T server is shown = open. Transaction a. withdraw(4); which with a participant, joins thec. deposit(4); transaction by b. withdraw(3); invokingd. deposit(3); the join method close. Transaction in the coordinator participant b. withdraw(T, 3); B join b. withdraw(3); Branch. Y participant Figure 13. 3 Note: the coordinator is in one of the servers, e. g. Branch. X participant C c. deposit(4); D d. deposit(3); Branch. Z Note that the TID (T) is passed with each request e. g. withdraw(T, 3) 6 •
The join operation The interface for Coordinator is shown in Figure 12. 3 – it has open. Transaction, close. Transaction and abort. Transaction – open. Transaction returns a TID which is passed with each operation so that servers know which transaction is accessing its objects The Coordinator interface provides an additional method, join, which is used whenever a new participant joins the transaction: – – join(Trans, reference to participant) informs a coordinator that a new participant has joined the transaction Trans. the coordinator records the new participant in its participant list. the fact that the coordinator knows all the participants and each participant knows the coordinator will enable them to collect the information that will be needed at commit time. 7 •
Atomic commit protocols transaction atomicity requires that at the end, – either all of its operations are carried out or none of them. in a distributed transaction, the client has requested the operations at more than one server one-phase atomic commit protocol – the coordinator tells the participants whether to commit or abort – what is the problem with that? – this does not allow one of the servers to decide to abort – it may have discovered a deadlock or it may have crashed and been restarted two-phase atomic commit protocol – is designed to allow any participant to choose to abort a transaction – phase 1 - each participant votes. If it votes to commit, it is prepared. It cannot change its mind. In case it crashes, it must save updates in permanent store – phase 2 - the participants carry out the joint decision The decision could be commit or abort - participants record it in permanent store 8 •
Failure model for the commit protocols Recall the failure model for transactions in Chapter 12 – this applies to the two-phase commit protocol Commit protocols are designed to work in – – – asynchronous system (e. g. messages may take a very long time) servers may crash messages may be lost. assume corrupt and duplicated messages are removed. no byzantine faults – servers either crash or they obey their requests 2 PC is an example of a protocol for reaching a consensus. – Chapter 11 says consensus cannot be reached in an asynchronous system if processes sometimes fail. – however, 2 PC does reach consensus under those conditions. – because crash failures of processes are masked by replacing a crashed process with a new process whose state is set from information saved in permanent storage and information held by other processes. 9 •
Whymany doesmessages participant record inthe permanent storage at bthis stage? How are sent updates between coordinator and each participant? The two-phase commit protocol During the progress of a transaction, the only communication between coordinator and participant is the join request – The client request to commit or abort goes to the coordinator w if client or participant request abort, the coordinator informs the participants immediately w if the client asks to commit, the 2 PC comes into use 2 PC – voting phase: coordinator asks all participants if they can commit w if yes, participant records updates in permanent storage and then votes – completion phase: coordinator tells all participants to commit or abort – the next slide shows the operations used in carrying out the protocol 10 •
Operations for two-phase commit protocol This is a request with a reply can. Commit? (trans)-> Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote. do. Commit(trans) Call from coordinator to participant to tell participant to commit its part of a transaction. These are asynchronous requests to avoid delays do. Abort(trans) Call from coordinator to participant to tell participant to abort its part of a transaction. have. Committed(trans, participant) Asynchronous request Call from participant to coordinator to confirm that it has committed the transaction. get. Decision(trans) -> Yes / No Call from participant to coordinator to ask for the decision on a transaction after it has voted Yes but has still had no reply after some delay. Used to recover from server crash or delayed messages. Figure 13. 4 participant interface- can. Commit? , do. Commit, do. Abort coordinator interface- have. Committed, get. Decision 11 •
The two-phase commit protocol • • Phase 1 (voting phase): • 1. The coordinator sends a can. Commit? request to each of the participants in the transaction. • 2. When a participant receives a can. Commit? request it replies with its vote (Yes or No) to the coordinator. Before voting Yes, it prepares to commit by saving objects in permanent storage. If the vote is No the participant aborts immediately. Phase 2 (completion according to outcome of vote): • 3. The coordinator collects the votes (including its own). w (a)If there are no failures and all the votes are Yes the coordinator decides to commit the transaction and sends a do. Commit request to each of the participants. w (b)Otherwise the coordinator decides to abort the transaction and sends do. Abort requests to all participants that voted Yes. • 4. Participants that voted Yes are waiting for a do. Commit or do. Abort request from the coordinator. When a participant receives one of these messages it acts accordingly and in the case of commit, makes a have. Committed call as confirmation to the coordinator. Figure 13. 5 12 •
Communication two-phase commit Thinkaboutstep the coordinator in step 12 - what is the problem? Think 2 in - what is the problem for protocol the participant? participant before Coordinator step status 1 3 prepared to commit (waiting for votes) committed Figure 13. 6 can. Commit? Yes Participant step status 2 prepared to commit (uncertain) 4 committed do. Commit have. Committed done Time-out actions in the 2 PC w to avoid blocking forever when a process crashes or a message is lost – uncertain participant (step 2) has voted yes. it can’t decide on its own w it uses get. Decision method to ask coordinator about outcome – participant has carried out client requests, but has not had a Commit? from the coordinator. It can abort unilaterally – coordinator delayed in waiting for votes (step 1). It can abort and send do. Abort to participants. 13 •
Performance of the two-phase commit protocol if there are no failures, the 2 PC involving N participants requires – N can. Commit? messages and replies, followed by N do. Commit messages. w the cost in messages is proportional to 3 N, and the cost in time is three rounds of messages. w The have. Committed messages are not counted – there may be arbitrarily many server and communication failures – 2 PC is is guaranteed to complete eventually, but it is not possible to specify a time limit within which it will be completed w delays to participants in uncertain state w some 3 PCs designed to alleviate such delays • they require more messages and more rounds for the normal case 14 •
13. 3. 2 Two-phase commit protocol for nested transactions Recall Fig 13. 1 b, top-level transaction T and subtransactions T 1, T 2, T 11, T 12, T 21, T 22 A subtransaction starts after its parent and finishes before it When a subtransaction completes, it makes an independent decision either to commit provisionally or to abort. – A provisional commit is not the same as being prepared: it is a local decision and is not backed up on permanent storage. – If the server crashes subsequently, its replacement will not be able to carry out a provisional commit. A two-phase commit protocol is needed for nested transactions – it allows servers of provisionally committed transactions that have crashed to abort them when they recover. 15 •
Figure The TID offinishes a 13. 7 subtransaction is an transactions extension of by its parent's TID, so that a or The client a set of nested calling close. Transaction subtransaction canin out the TID offor the nested top-level transaction. Operations coordinator transactions abort. Transacation inwork the top-level transaction. open. Sub. Transaction(trans) -> sub. Trans Opens a new subtransaction whose parent is trans and returns a unique subtransaction identifier. get. Status(trans)-> committed, aborted, provisional Asks the coordinator to report on the status of the transaction trans. Returns values representing one of the following: committed, aborted, provisional. This is the interface of the coordinator of a subtransaction. – It allows it to open further subtransactions – It allows its subtransactions to enquire about its status Client starts by using Open. Transaction to open a top-level transaction. – This returns a TID for the top-level transaction – The TID can be used to open a subtransaction w The subtransaction automatically joins the parent and a TID is returned. 16 •
T 12 has provisionally committed and T 11 hasto aborted, but the fate of T T 12 has Transaction TT decides commit Although T both provisionally committed, 21 and 22 have 2 also Suppose. Tthat towhether commit although T has aborted, 2 depends on its this parent T 1 andthat eventually on the top-level transaction, T. aborted and means T and T must also abort. 21 22 has aborted that T 1 decides to commit although T 11 Figure 13. 8 T 11 T 1 provisional commit (at X) T T 2 abort (at M) aborted (at Y) T 12 provisional commit (at N) T 21 provisional commit (at N) T 22 provisional commit (at P) Recall that 1. A parent can commit even if a subtransaction aborts 2. If a parent aborts, then its subtransactions must abort – In the figure, each subtransaction has either provisionally committed or aborted 17 •
Information held by coordinators of nested transactions When a top-level transcation commits it carries out a 2 PC Each coordinator has a list of its subtransactions At provisional commit, a subtransaction reports its status and the status of its descendents to its parent If a subtransaction aborts, it tells its parent Coordinator of Child transactions T T 1, T 2 T 11 , T 12 T 21 , T 22 T 11 T 12 , T 21 Figure 13. 9 T 22 Participant Provisional commit list T 1, T 12 yes no (aborted) T 12 but not T 21 , T 12 no (parent aborted)T 22 Abort list T 11 , T 2 T 11 18 T share aan coordinator theyofboth run at parent server N When T 2 isabout aborted itoutcome. tells T (no. It information about descendents) • 12 and subtransaction (e. g. to. T 21 T 22 )T 21 is called orphan ifas one its ancestors aborts an. Aorphan uses get. Status askand its parent the should abort if its has
can. Commit? for hierarchic two-phase commit protocol Figure 13. 10 can. Commit? (trans, sub. Trans) -> Yes / No Call a coordinator to ask coordinator of child subtransaction whether it can commit a subtransaction sub. Trans. The first argument trans is the transaction identifier of top-level transaction. Participant replies with its vote Yes / No. Top-level transaction is coordinator of 2 PC. participant list: – – the coordinators of all the subtransactions that have provisionally committed but do not have an aborted ancestor E. g. T, T 1 and T 12 in Figure 13. 8 if they vote yes, they prepare to commit by saving state in permanent store w The state is marked as belonging to the top-level transaction The 2 PC may be performed in a hierarchic or a flat manner Hierarchic 2 PC - Tisasks can. Commit? tothe. T 1 objects and T 1 inasks can. Commit? to T 12 The trans argument used when saving permanent The sub. Trans argument is use to find the subtransaction to vote on. storage If absent, vote no. 19 •
Compare the advantages and disadvantages of the flat and nested approaches can. Commit? for flat two-phase commit protocol Figure 13. 11 can. Commit? (trans, abort. List) -> Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote Yes / No. Flat 2 PC – the coordinator of the top-level transaction sends can. Commit? messages to the coordinators of all of the subtransactions in the provisional commit list. – in our example, T sends to the coordinators of T 1 and T 12. – the trans argument is the TID of the top-level transaction – the abort. List argument gives all aborted subtransactions w e. g. server N has T 12 prov committed and T 21 aborted – On receiving can. Commit, participant w looks in list of transactions for any that match trans (e. g. T 12 and T 21 at N) w it prepares any that have provisionally committed and are not in abort. List and votes yes w if it can't find any it votes no 20 •
Time-out actions in nested 2 PC With nested transactions delays can occur in the same three places as before – when a participant is prepared to commit – when a participant has finished but has not yet received can. Commit? – when a coordinator is waiting for votes Fourth place: – provisionally committed subtransactions of aborted subtransactions e. g. T 22 whose parent T 2 has aborted – use get. Status on parent, whose coordinator should remain active for a while – If parent does not reply, then abort 21 •
Summary of 2 PC a distributed transaction involves several different servers. – A nested transaction structure allows w additional concurrency and w independent committing by the servers in a distributed transaction. atomicity requires that the servers participating in a distributed transaction either all commit it or all abort it. atomic commit protocols are designed to achieve this effect, even if servers crash during their execution. the 2 PC protocol allows a server to abort unilaterally. – it includes timeout actions to deal with delays due to servers crashing. – 2 PC protocol can take an unbounded amount of time to complete but is guaranteed to complete eventually. 22 •
13. 4 Concurrency control in distributed transactions Each server manages a set of objects and is responsible for ensuring that they remain consistent when accessed by concurrent transactions – therefore, each server is responsible for applying concurrency control to its own objects. – the members of a collection of servers of distributed transactions are jointly responsible for ensuring that they are performed in a serially equivalent manner – therefore if transaction T is before transaction U in their conflicting access to objects at one of the servers then they must be in that order at all of the servers whose objects are accessed in a conflicting manner by both T and U • 23
13. 4. 1 Locking In a distributed transaction, the locks on an object are held by the server that manages it. – The local lock manager decides whether to grant a lock or make the requesting transaction wait. – it cannot release any locks until it knows that the transaction has been committed or aborted at all the servers involved in the transaction. – the objects remain locked and are unavailable for other transactions during the atomic commit protocol w an aborted transaction releases its locks after phase 1 of the protocol. • 24
Interleaving of transactions T and U at servers X and Y in the example on page 529, we have – T before U at server X and U before T at server Y different orderings lead to cyclic dependencies and distributed deadlock – detection and resolution of distributed deadlock in next section T Write(A) Read(B) at X at Y U locks A Write(B) at Y locks B Read(A) at X waits for T waits for U • 25
13. 4. 2 Timestamp ordering concurrency control Single server transactions – coordinator issues a unique timestamp to each transaction before it starts – serial equivalence ensured by committing objects in order of timestamps Distributed transactions – the first coordinator accessed by a transaction issues a globally unique timestamp – as before the timestamp is passed with each object access – the servers are jointly responsible for ensuring serial equivalence w that is if T access an object before U, then T is before U at all objects – coordinators agree on timestamp ordering w a timestamp consists of a pair <local timestamp, server-id>. w the agreed ordering of pairs of timestamps is based on a comparison in which the server-id part is less significant – they should relate to time • 26
Can the same ordering be achieved at all servers without clock synchronization? Timestamp control Why is it better to ordering have roughlyconcurrency synchronized clocks? (continued) The same ordering can be achieved at all servers even if their clocks are not synchronized – for efficiency it is better if local clocks are roughly synchronized – then the ordering of transactions corresponds roughly to the real time order in which they were started Timestamp ordering – conflicts are resolved as each operation is performed – if this leads to an abort, the coordinator will be informed w it will abort the transaction at the participants – any transaction that reaches the client request to commit should always be able to do so w participant will normally vote yes w unless it has crashed and recovered during the transaction • 27
Use backward validation Optimistic concurrency control 1. write/read, 2. read/write, 3. write/write each transaction is validated before it is allowed to commit – transaction numbers assigned at start of validation – transactions serialized according to transaction numbers – validation takes place in phase 1 of 2 PC protocol 1. 2. 3. satisfied checked paralllel consider the following interleavings of T and U – T before U at X and U before T at YT & U start validation at about the same time Suppose Read(A) Write(A) Read(B) Write(B) T at X at Y Read(B) Write(B) Read(A) Write(A) 28 U at Y at X X does T first Y does U first No parallel Validation –. commitment deadlock •
Commitment deadlock in optimistic concurrency control servers of distributed transactions do parallel validation – therefore rule 3 must be validated as well as rule 2 w the write set of Tv is checked for overlaps with write sets of earlier transactions – this prevents commitment deadlock – it also avoids delaying the 2 PC protocol another problem - independent servers may schedule transactions in different orders – e. g. T before U at X and U before T at Y – this must be prevented - some hints as to how on page 531 • 29
13. 5 Distributed deadlocks Single server transactions can experience deadlocks – prevent or detect and resolve – use of timeouts is clumsy, detection is preferable. w it uses wait-for graphs. Distributed transactions lead to distributed deadlocks – in theory can construct global wait-for graph from local ones – a cycle in a global wait-for graph that is not in local ones is a distributed deadlock • 30
Figure 13. 12 Interleavings of transactions U, V and W objects A, B managed by X and Y ; C and D by Z – next slide has global wait-for graph U d. deposit(10) V W lock D lock B at Y b. deposit(10) a. deposit(20) U V at Y b. withdraw(30) lock A at X c. deposit(30) wait at Y V W at Z wait at Z c. withdraw(20) W U at X a. withdraw(20) 31 lock C at Z wait at X •
Figure 13. 13 Distributed deadlock a deadlock cycle has alternate edges showing wait-for and held-by wait-for added in order: U V at Y; V W at Z and W U at X (a) (b) W Held by D C A X Z Waits for W Waits for V Held by V U U Waits for B Held by Y • 32
Deadlock detection - local wait-for graphs Local wait-for graphs can be built, e. g. – server Y: U V added when U requests b. withdraw(30) – server Z: V W added when V requests c. withdraw(20) – server X: W U added when W requests a. withdraw(20) to find a global cycle, communication between the servers is needed centralized deadlock detection – one server takes on role of global deadlock detector – the other servers send it their local graphs from time to time – it detects deadlocks, makes decisions about which transactions to abort and informs the other servers – usual problems of a centralized service - poor availability, lack of fault tolerance and no ability to scale • 33
Figure 13. 14 Local and global wait-for graphs Phantom deadlocks – a ‘deadlock’ that is detected, but is not really one – happens when there appears to be a cycle, but one of the transactions has released a lock, due to time lags in distributing graphs – in the figure suppose U releases the object at X then waits for V at Y w and the global detector gets Y’s graph before X’s (T U V T) local wait-for graph T U X local wait-for graph V global deadlock detector T T U Y V • 34
Edge chasing - a distributed approach to deadlock detection a global graph is not constructed, but each server knows about some of the edges – servers try to find cycles by sending probes which follow the edges of the graph through the distributed system – when should a server send a probe (go back to Fig 13. 13) – edges were added in order U V at Y; V W at Z and W U at X w when W U at X was added, U was waiting, but w when V W at Z, W was not waiting – send a probe when an edge T 1 T 2 when T 2 is waiting – each coordinator records whether its transactions are active or waiting w the local lock manager tells coordinators if transactions start/stop waiting w when a transaction is aborted to break a deadlock, the coordinator tells the participants, locks are removed and edges taken from wait-for graphs • 35
Edge-chasing algorithms Three steps – Initiation: w When a server notes that T starts waiting for U, where U is waiting at another server, it initiates detection by sending a probe containing the edge < T U > to the server where U is blocked. w If U is sharing a lock, probes are sent to all the holders of the lock. – Detection: w Detection consists of receiving probes and deciding whether deadlock has occurred and whether to forward the probes. • e. g. when server receives probe < T U > it checks if U is waiting, e. g. U V, if so it forwards < T U V > to server where V waits • when a server adds a new edge, it checks whether a cycle is there – Resolution: w When a cycle is detected, a transaction in the cycle is aborted to break the deadlock. • 36
Figure 13. 15 Probes transmitted to detect deadlock example of edge chasing starts with X sending <W U>, then Y sends <W U V >, then Z sends <W U V W> W W U V W Deadlock detected C Held by Waits for A Z W U V Waits for Initiation X W U V U Held by Y 37 B Waits for •
Edge chasing conclusion probe to detect a cycle with N transactions will require 2(N-1) messages. – Studies of databases show that the average deadlock involves 2 transactions. the above algorithm detects deadlock provided that – waiting transactions do not abort – no process crashes, no lost messages – to be realistic it would need to allow for the above failures refinements of the algorithm (p 536 -7) – to avoid more than one transaction causing detection to start and then more than one being aborted – not time to study these now • 38
Summary of concurrency control for distributed transactions each server is responsible for the serializability of transactions that access its own objects. additional protocols are required to ensure that transactions are serializable globally. – timestamp ordering requires a globally agreed timestamp ordering – optimistic concurrency control requires global validation or a means of forcing a global ordering on transactions. – two-phase locking can lead to distributed deadlocks. w distributed deadlock detection looks for cycles in the global wait-for graph. w edge chasing is a non-centralized approach to the detection of distributed deadlocks w. • 41
13. 6 Transaction recovery What is meant by failure durability? atomicity? Atomicity property of transactions – durability and failure atomicity – durability requires that objects are saved in permanent storage and will be available indefinitely – failure atomicity requires that effects of transactions are atomic even when the server crashes Recovery is concerned with – ensuring that a server’s objects are durable and – that the service provides failure atomicity. – for simplicity we assume that when a server is running, all of its objects are in volatile memory – and all of its committed objects are in a recovery file in permanent storage – recovery consists of restoring the server with the latest committed versions of all of its objects from its recovery file 42 •
Recovery manager The task of the Recovery Manager (RM) is: – to save objects in permanent storage (in a recovery file) for committed transactions; – to restore the server’s objects after a crash; – to reorganize the recovery file to improve the performance of recovery; – to reclaim storage space (in the recovery file). media failures – i. e. disk failures affecting the recovery file – need another copy of the recovery file on an independent disk. e. g. implemented as stable storage or using mirrored disks we deal with recovery of 2 PC separately (at the end) – we study logging (13. 6. 1) but not shadow versions (13. 6. 2) 43 •
Recovery - intentions lists Each server records an intentions list for each of its currently active transactions – an intentions list contains a list of the object references and the values of all the objects that are altered by a transaction – when a transaction commits, the intentions list is used to identify the objects affected w the committed version of each object is replaced by the tentative one w the new value is written to the server’s recovery file – in 2 PC, when a participant says it is ready to commit, its RM must record its intentions list and its objects in the recovery file w it will be able to commit later on even if it crashes w when a client has been told a transaction has committed, the recovery files of all participating servers must show that the transaction is committed, • even if they crash between prepare to commit and commit 44 •
Types of entry in a recovery file Why is that a good idea? Type of entry Description of contents of entry Object state flattened to bytes Object A value of an object. Transaction status Transaction identifier, transaction status ( prepared, committed aborted) and other status values used for the two-phase commit protocol. first entry says prepared Intentions list Transaction identifier and a sequence of intentions, each of which consists of <identifier of object>, <position in recovery Figure 13. 18 file of value of object>. For distributed transactions we need information relating to the 2 PC as well as object values, that is: – transaction status (committed, prepared or aborted) – intentions list Note that the objects need not be next to one another in the recovery file 45 •
Logging - a technique for the recovery file represents a log of the history of all the transactions at a server – – it includes objects, intentions lists and transaction status in the order that transactions prepared, committed and aborted a recent snapshot + a history of transactions after the snapshot during normal operation the RM is called whenever a transaction prepares, commits or aborts w prepare - RM appends to recovery file all the objects in the intentions list followed by status (prepared) and the intentions list w commit/abort - RM appends to recovery file the corresponding status w assume append operation is atomic, if server fails only the last write will be incomplete w to make efficient use of disk, buffer writes. Note: sequential writes are more efficient than those to random locations w committed status is forced to the log - in case server crashes 46 •
committed status Log for banking service P 0 P 1 P 2 P 3 P 4 P 5 P 6 Object: A Object: B Object: C Object: A Object: B Trans: T Object: C Object: B 100 200 300 80 220 prepared committed 278 242 <A, P 1> <B, P 2> P 0 P 3 Figure 13. 19. Checkpoint P 7 Trans: U prepared <C, P 5> <B, P 6> P 4 End of log prepared status and intentions list Logging mechanism for Fig 12. 7 (there would really be other objects in log file) – initial balances of A, B and C $100, $200, $300 – T sets A and B to $80 and $220. U sets B and C to $242 and $278 – entries to left of line represent a snapshot (checkpoint) of values of A, B and C before T started. T has committed, but U is prepared. – the RM gives each object a unique identifier (A, B, C in diagram) – each status entry contains a pointer to the previous status entry, then the checkpoint can follow transactions backwards through the file 47 •
Recovery of objects - with logging When a server is replaced after a crash – it first sets default initial values for its objects – and then hands over to its recovery manager. The RM restores the server’s objects to include – all the effects of all the committed transactions in the correct order and – none of the effects of incomplete or aborted transactions – it ‘reads the recovery file backwards’ (by following the pointers) w restores values of objects with values from committed transactions w continuing until all of the objects have been restored – if it started at the beginning, there would generally be more work to do – to recover the effects of a transaction use the intentions list to find the value of the objects w e. g. look at previous slide (assuming the server crashed before T committed) – the recovery procedure must be idempotent 48 •
Logging - reorganising the recovery file RM is responsible for reorganizing its recovery file – so as to make the process of recovery faster and – to reduce its use of space checkpointing – the process of writing the following to a new recovery file w the current committed values of a server’s objects, w transaction status entries and intentions lists of transactions that have not yet been fully resolved w including information related to the two-phase commit protocol (see later) – checkpointing makes recovery faster and saves disk space w w done after recovery and from time to time can use old recovery file until new one is ready, add a ‘mark’ to old file do as above and then copy items after the mark to new recovery file replace old recovery file by new recovery file 49 •
Recovery of the two-phase commit protocol The above recovery scheme is extended to deal with transactions doing the 2 PC protocol when a server fails – it uses new transaction status values done, uncertain (see Fig 13. 6) w the coordinator uses committed when result is Yes; w done when 2 PC complete ( if a transaction is done its information may be removed when reorganising the recovery file) w the participant uses uncertain when it has voted Yes; committed when told the result (uncertain entries must not be removed from recovery file) – It also requires two additional types of entry: Type of entry Description of contents of entry Coordinator Transaction identifier, list of participants added by RM when coordinator prepared Transaction identifier, coordinator added by RM when participant votes yes Participant 51 •
Butif. Start or We ifthe have at server end, T committed crashed for has U crashed findearlier itand is before committed coordinator we have the U last and prepared entry a participant we and have participant U uncertain and participant Log with entries relating to two-phase commit protocol Trans: T Coord’r: T Trans: T prepared part’pant list: . . . committed prepared intentions list Trans: U intentions list coordinator entry Part’pant: U Trans: U Coord’r: . . uncertain committed Figure 13. 21 participant entry entries in log for – T where server is coordinator (prepared comes first, followed by the coordinator entry, then committed – done is not shown) – and U where server is participant (prepared comes first followed by the participant entry, then uncertain and finally committed) – these entries will be interspersed with values of objects recovery must deal with 2 PC entries as well as restoring objects – where server was coordinator find coordinator entry and status entries. – where server was participant find participant entry and status entries 52 •
Recovery of the two-phase commit protocol Role Status Coordinator prepared Action of recovery manager No decision had been reached before the server failed. It sends abort. Transaction to all the servers in the participant list and adds the transaction status aborted in its recovery file. Same action for state Figure 13. 22 aborted. If there is no participant list, the participants will eventually timeout and abort the transaction. Coordinator committed A decision to commit had been reached before the server failed. It sends a do. Commit to all the participants in its participant list (in case it had not done so before) and resumes the two-phase protocol at step 4 (Fig 13. 5). Participant committed The participant sends a have. Committed message to the coordinator (in case this was not done before it failed). This will allow the coordinator to discard information about this transaction at the next checkpoint. Participant Theinparticipant failed before it knew the outcome of the transaction. the most uncertain recent entry the recovery file determines the status of the It cannot transaction at the time of determine failure the status of the transaction until the coordinator informs it of the decision. It will send a get. Decision to the coordinator to determine the status of the transaction. When it receives the reply it the RM action for each transaction depends on whether server will commit or abort accordingly. was coordinator participant the Participant prepared or. The participant and has not yetstatus voted and can abort the transaction. Coordinator done No action is required. 53 •
Summary of transaction recovery Transaction-based applications have strong requirements for the long life and integrity of the information stored. Transactions are made durable by performing checkpoints and logging in a recovery file, which is used for recovery when a server is replaced after a crash. Users of a transaction service would experience some delay during recovery. It is assumed that the servers of distributed transactions exhibit crash failures and run in an asynchronous system, – but they can reach consensus about the outcome of transactions because crashed servers are replaced with new processes that can acquire all the relevant information from permanent storage or from other servers 55 •
- Slides: 51