RDF/IMP, IMPX, and ZLT System Management Manual

Introducing RDF
HP NonStop RDF/IMP, IMPX, and ZLT System Management Manual—524388-002
1-4
Unplanned Outages
The master receiver writes transaction status information to the master image trail.
Note that in this example each receiver process writes all audit information to a single
secondary image trail. As will be discussed later, however, either could write to multiple
sorted image trails.
Updater processes $UP1 through $UP10 read audit information from the secondary
image trail and apply it to volumes $D1 through $D10, respectively, on the backup
system. For example, updater process $UP1 only looks for audit information for tables
and files associated with volume $D1 on the primary system (ignoring any for volumes
$D2 through $D10), and applies that information to the corresponding tables and files
on $D1 on the backup system.
Updater processes $UP11 through $UP15 read audit information from the AUX01
secondary image trail and apply it to volumes $D11 through $D15, respectively, on the
backup system.
As mentioned earlier, the RDFCOM process on the primary system provides the user
interface for issuing RDF commands. The RDF monitor process executes most user
commands, and monitors all other RDF processes.
Unplanned Outages
An unplanned outage typically occurs as the result of a sudden disaster that prevents
the database on the primary system from being used. The classic purpose of RDF is to
make rapid recovery from an unplanned outage possible by maintaining a replicated
database on a backup system. When the primary system is unexpectedly affected by a
disaster, you can shift operations to the replicated database on the backup system
after having the RDF updaters bring the backup database to a consistent state. You do
that by starting RDFCOM on the backup system and initiating an RDF takeover
operation.
An RDF takeover operation ensures that all audit information associated with
committed transactions is applied to the backup database. If the status of a transaction
is unknown on the backup system because the commit or abort record was not sent by
the time the disaster brought the primary system down, the transaction is considered to
be aborted, and any audit information associated with that transaction is backed out of
the backup database.
If the primary system is unexpectedly brought down because of a disaster, the
outcome of some transactions might never be known, as illustrated in Table 1-1.