Distributed Transactions - Transaction Processing - page 311

is performed at s 0 , firing the trigger, after which the trigger is removed. Assuming
that there is at s i an index to r on the key attribute X ,foralli D 1;:::;k, the update
is far more efficient than with the symmetric propagation in Example 13.6 . t

With read-one-write-all replication, transactions block in the event of a failure at
one of the servers that hold a replica of a data item to be updated. A relaxed protocol,
called read-one-write-all-available ,or ROWAA , allows a transaction to proceed if all
available replicas are updated; separate transactions are run to update the unavailable
replicas when the replica sites are working again. Obviously, with this protocol,
strong mutual consistency of the replicas is lost.
Some relaxed protocols, such as ROWAA , maintain weak mutual consistency ,also
called eventual consistency , among the replicas: the updates on a data item are
guaranteed to be propagated to all the replicas eventually.

13.8 Remote Backup Databases

For protecting a database from natural disasters such as fires, floods, and earth-
quakes, a remote backup database is often maintained. Such a database resides at a
site that is at a “safe” distance from the site of the corresponding primary database .
The remote backup database system propagates in a continuous fashion all updates
performed on the primary database, trying to keep the backup database up to date,
that is, identical or nearly identical to the primary database, so that in the event of
a disaster, the backup database system can assume the role of the primary database
system with as little delay as possible.
A primary database server and its remote backup database server thus together
form a kind of a fully replicated database system, with the difference however that
transactions are only run on the primary database. We assume that each backup-
database server propagates updates from a single database server only, so that
in the case of a distributed database system there is one backup server for each
primary server. We also assume that the primary database server and its backup
database server run exactly the same database management system software and
that both database structures are configured identically, having the same page sizes
and formats, etc.
The work done for maintaining the remote backup database should be minimized,
because it is all pure overhead if no disaster occurs. A most cost-effective solution is
based on log-record shipping and physical redoing : updates on the primary database
are propagated to the backup database system by shipping log records and redoing
the updates on each page in the original LSN order, as in the redo pass of ARIES
recovery. Thus, the state of each page in the physical backup database will be kept
identical to a recent state of the same page in the physical primary database.
The log records coming from the primary server are stored on the log of the
backup server in their original LSN order, and the usual write-ahead logging and
steal-and-no-force policies are applied in the redo process. However, buffering-