Recovery in Distributed Systems : Transaction Recovery (see Coulouris et al.)

Recovery inDistributed Systems: Transaction Recovery (see Coulouris et al.)

Transaction Recovery-1 • Atomic Property of Transactions means that the effect of performing a transaction on behalf of one client is free from interference from concurrent transactions being performed on behalf of other clients • It requires the effects of all committed transactions reflected in data items, but none of the effects of incomplete/aborted transactions are reflected in the data items

Transaction Recovery-2 • Two Aspects to consider • Durability - requires that data items are saved in permanent storage and will be available indefinitely, at the servers, or the sites of storage. • Failure Atomicity - requires that the effects of the transaction are atomic even when the server fails • These two aspects are not completely independent and they can be handled by a so called recovery manager, which is based on a two-phase commit protocol.

Recovery Manager (RM)-1 • Restores the server’s database from Recovery File (RF) after a crash, which needs to be resilient to media failure - stable storage • Reorganizes the RF to improve the performance of recovery • Reclaims storage space in the RF, through the execution of the application

Recovery Manager (RM)-2 • Recovery File (as a log) is used to deal with recovery of a server involved in a distributed transaction. • The RF contains: • Trans Id and the status of the transaction - prepared, committed, aborted • Data items that are part of the transaction and their values • Intentions List for the transaction

Recovery Manager (RM)-3 • RF represents a log containing the history of all the transactions performed • Contains a Checkpoint • Order of entries reflects the order in which transactions have prepared, committed and aborted

Intentions List • Contains a list of data item names and the position in the RF were the values of the data items that are altered by that transaction reside • When a server is prepared to commit a transaction, the RM must save the intentions list in the RF, this ensures the server is able to carry out the commitment later, even if it crashes in the interim • When a transaction is aborted the RM uses the intentions list to delete all the tentative versions of data items made by that transaction

Example-1 • Recovery File (as Log) - fig 15.1 on a Banking Service transactions T and U, Refer fig 12. 6 • In fig 15.1, left of double line is the Checkpoint starting at P0, which represents a snapshot of values A, B, C before transactions T and U started • Server crashes after RM records that U has indicated it is prepared to commit and written the intentions list • In this case, the values of A, B and C must be restored

Example-2 • RM is responsible for restoring the data items so that they include the effects of all the committed transactions and none of the effects of incomplete or aborted transactions • RM starts recovery from End of Log at entry P7 • Concludes that U has not committed and its effects can be ignored • Moves to P4 and concludes T has committed • To recover data items affected by T it moves to entry P3 and finds the intentions list for T • It restores data items A and B from values at P1 and P2 • To restore C it moves to P0 and uses the checkpoint value

Example-3 • Recovery Manager for each transaction with status prepared, adds aborted and completes a new Checkpoint and creates a new RF

Check pointing • The process of writing the current committed values of a server’s data items to a new RF, together with transaction status entries and intentions lists of transactions that have not yet been fully resolved • Its purpose is to reduce number of transactions to be dealt with during recovery and reclaim file space • The failed checkpoint itself must be able to recovered too…

Recovery of Two- Phase Commit Protocol-1 • In a Distributed Transaction, each server (worker or coordinator) keeps its own RF • Recovery Management must be extended to deal with distributed transactions performed using the Two- Phase Commit protocol at a time when a server fails • The RM at coordinator records a coordinator entry - (Trans Id, list of workers) in coordinator’s RF

Recovery of Two- Phase Commit Protocol-2 • RMs use two new transaction status values done and uncertain which can be written to the RF. Both done and uncertain are used when the RF is re-organized • RM of coordinator uses done to indicate two- phase commit is complete • RM of worker uses uncertain to indicate the worker has voted Yes but does not know the outcome • The RM at coordinator records a coordinator entry - (Trans Id, list of workers) in coordinator’s RF • The RM at worker records a worker entry - (Trans Id, coordinator) in worker’s RF

Recovery of Two- Phase Commit Protocol-3 • During Phase 1 - Voting • When coordinator is prepared to commit, its RM writes prepared and a coordinator entry to RF • If worker votes Yes, its RM writes prepared, a worker entry and uncertain to the RF • If worker votes No, its RM writes aborted to the RF

Recovery of Two- Phase Commit Protocol-4 • During Phase 2 - Completion • RM of Coordinator writes either committed or aborted to the RF according to the decision made • RMs of Workers write committed or aborted to their RFs depending on message received from coordinator • RM of Coordinator writes done to RF when coordinator has received a have committed message from all its workers

Recovery of Two- Phase Commit Protocol-5 • Recovery of Two- Phase Commit Protocol • Refer to fig 15. 2, which shows entries in a RF for transaction: T where server is coordinator U where server is worker • Action of the RM after a server restarts after a crash is shown in fig 15.3 • Reorganization of RF When performing Checkpoint: • coordinator entries of transactions without status done are not removed • worker entries with status uncertain are not removed

Recovery in Distributed Systems : Transaction Recovery (see Coulouris et al.)