Recovery in Distributed 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, a point where the state of database is precisely known. 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 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