RDF System Management Manual

Introducing RDF
HP NonStop RDF System Management Manual—524388-003
1-4
Unplanned Outages With ZLT
information associated with volumes $D11 through $D15 to the RDF auxiliary receiver
process on the backup system.
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.
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 opera-
tion.
An RDF takeover operation ensures that all audit information associated with transac-
tions that are known to have been committed is applied to the backup database
Unplanned Outages With ZLT
Zero Lost Transactions (ZLT), functionality that is available only with the RDF/ZLT
product, ensures that no transactions that commit on the primary system are lost on
the RDF backup system if that primary system is downed by an unplanned outage.
RDF achieves this though the use of remote mirroring for the relevant TMF audit-trail
volume(s). That is, one mirror of an audit-trail volume remains local to the primary
system, but the other mirror is located at a remote standby site.
When a primary system is downed by some unplanned outage or disaster, there may
be some audit data that the extractor on the primary system was unable to send to the
backup system before the outage. With ZLT functionality, RDF fetches all remaining
audit data from the remote mirror, thereby guaranteeing no loss of committed data
during the RDF takeover operation.
For information about the ZLT function, see Section 16, Zero Lost Transactions (ZLT).