Scribd
Upload
20 views

Lec 15 - Distributed Processing - Transaction Recovery

The document discusses how a recovery manager handles transaction recovery through logging. It covers how the recovery manager saves transaction intentions and object states to a recovery file, and how it uses the log to restore objects after a crash by reading entries backwards from committed transactions. Checkpointing is also described as reorganizing the recovery file to improve performance and reduce space usage.

Uploaded by

Junaid Khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
20 views

Lec 15 - Distributed Processing - Transaction Recovery

The document discusses how a recovery manager handles transaction recovery through logging. It covers how the recovery manager saves transaction intentions and object states to a recovery file, and how it uses the log to restore objects after a crash by reading entries backwards from committed transactions. Checkpointing is also described as reorganizing the recovery file to improve performance and reduce space usage.

Uploaded by

Junaid Khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 8

TRANSACTION Recovering from

RECOVERY faults
RECOVERY MANAGER
RM deals with both durability and failure atomicity

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

May 2018 TRANSACTION RECOVERY 2


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 at each server
When a transaction commits, its intentions list is used to identify the objects
affected
 The committed version of each object is replaced by the tentative one
 The new value is written to the server’s recovery file

In 2PCP, when a participant says it is ready to commit, its RM must record


its intentions list and its objects in the recovery file
 It will be able to commit later on even if it crashes
 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

May 2018 TRANSACTION RECOVERY 3


Why is that a good idea?

TYPES OF ENTRY IN A
RECOVERY FILE
Type of entry Description of contents of entry
Object A value of an object. Object state flattened to bytes
Transaction Transaction identifier, transaction status (prepared, committed
status 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
file of value of object>.

For distributed transactions we need information relating to the


2PCP as well as object values, that is:
 Transaction status (committed, prepared or aborted)
 Intentions list

NoteMaythat
2018
the objects need not be next to one another in the recovery file
TRANSACTION RECOVERY 4
LOGGING - A TECHNIQUE
FOR THE RECOVERY FILE
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
 Prepare - RM appends to recovery file all the objects in the intentions list
followed by status (prepared) and the intentions list
 Commit/Abort - RM appends to recovery file the corresponding status
 Assume append operation is atomic, if server fails only the last write will be
incomplete
 Committed status is forced to the log - in case server crashes

May 2018 TRANSACTION RECOVERY 5


LOG FOR BANKING committed status

SERVICE
P0 P1 P2 P3 P4 P5 P6 P7
Object:A Object:B Object:C Object:A Object:B Trans: T Trans: T Object:C Object:B Trans: U
100 200 300 80 220 prepared committed 278 242 prepared
<A, P 1> <C, P 5>
<B, P 2> <B, P 6>
P0 P3 P4

Checkpoint
End
Previous State of log
T U
prepared status and intentions list
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

May 2018 TRANSACTION RECOVERY 6


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)
 Restores values of objects with values from committed transactions
 Continuing until all of the objects have been restored
 To recover the effects of a transaction use the intentions list to find
the value of the objects

May 2018 TRANSACTION RECOVERY 7


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

CHECK POINTING
 The process of writing the following to a new recovery file
 The current committed values of a server’s objects,
 Transaction status entries and intentions lists of transactions that have not yet
been fully resolved
 Including information related to the two-phase commit protocol
 Check pointing makes recovery faster and saves disk space
 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
May 2018 TRANSACTION RECOVERY 8

You might also like