Distributed Transactions - Transaction Processing - page 314

For efficient handling of failures of the backup database system, the backup
server takes periodically its own checkpoints. These checkpoints include, besides
copies of the modified-page and active-transaction tables, a copy of the primary-to-
backup- LSN mapping table and, for each work queue, a value W ORK -Q UEUE -R EC -LSN
that is the backup-server LSN of the last processed log record for that work queue.
The W ORK -Q UEUE -R EC -LSN values are needed during restart recovery to repopulate
the work queues with log records that remained unprocessed due to the failure.
Restart recovery from a failure of the backup database system only includes an
analysis pass that starts with reading the tables copied at the most recent completely
taken checkpoint. The modified-page and active-transaction tables are initialized as
in the normal ARIES analysis pass (Sect. 4.7 ). Also the primary-to-backup- LSN table
is initialized from a copy taken at the checkpoint.
For repopulating the work queues, the forward log scan must be started at the log
record with an LSN value B ACKUP -R EDO -LSN , which is the greatest among the LSN
values that are less than or equal to W ORK -Q UEUE -R EC -LSN . w / C 1 for every work
queue w and less than or equal to R EC -LSN .p/ for every page p in the modified-
page table. The log scan is performed as in the normal ARIES analysis pass, with
the addition that log records for updates are distributed into the work queues as in
Algorithm 13.8 and that the primary-to-backup- LSN mapping table is reconstructed
from the log records (that, we recall, store both the primary and backup LSN s).
In the event of a primary-server failure, the backup server takes over the role of
the primary server as follows. First, all the remaining log records that have arrived
are distributed into the work queues and processed, that is, Algorithm 13.8 and,
for every work queue, Algorithm 13.9 , are run into completion. Then the undo
pass of ARIES (Sect. 4.9 ) is performed, aborting and rolling back all forward-rolling
transactions and completing the rollback of all backward-rolling transactions. The
backup database is now in a transaction-consistent state and ready to process new
transactions.

13.9 Transactions on Key-Value Stores

A key-value store (or a datastore ) as a logical database is just a single, though
usually very big, relation r.X;V/, where the tuples are versioned. The data in a
typical key-value store for Internet applications resides in a big datacenter where
it is partitioned among hundreds or thousands of servers. For high data availability
and protection against natural disasters, the data is replicated on a small number of
datacenters located in geographically distant locations.
A typical key-value store management system offers no transactions, but only
single-tuple actions of the following forms that can be executed atomically:

1. Read actions of the form RŒx; ; v that read the tuple .x; v / current as of time ,
that is, the latest version of the tuple with key x created at time or before. If no
timestamp is specified, the action returns the most recent version.