RDF System Management Manual

Introducing RDF
HP NonStop RDF System Management Manual—524388-003
1-30
Triple Contingency
The following discussion assumes you do not have ZLT functionality. For triple
contingency with ZLT, see Section 10, Triple Contingency.
The triple contingency feature builds upon the ability to replicate to multiple backup
systems. To use this feature, you establish two essentially identical RDF
configurations, as follows:
RDF Configuration #1
\A ---------> \B
RDF Configuration #2
\A ---------> \C
With both RDF configurations in operation, the exact same data is replicated to the two
backup systems (\B and \C). Because the two configurations operate independently of
one another, if the primary system fails, it is unlikely that the databases on the two
backup systems will be logically identical to each other after RDF takeover operations.
The extractor in one RDF configuration may have just read and sent new audit to its
backup system, but the primary system might have failed before the other extractor
could send the same audit to its backup system. To bring the two backup databases
into rapid synchronization, you must perform the following steps:
1. Check the EMS event log on both remote systems after the takeover operations
have finished, and exam each 735 event. This event lists the MAT position of the
last record received by the receiver from its extractor. By comparing this message
in each EMS event log, you can easily identify which backup system received the
most audit.
2. On the backup system that received the least audit, use RDFCOM to execute the
COPYAUDIT command. This command copies all the missing audit from the
system that received the most audit to your present local system—the one that
received the least audit.
3. Still on your same local backup system, use RDFCOM to execute a TAKEOVER
command. When this command completes execution, the databases on both
backup systems will be fully synchronized and logically identical to each other.
Now, you can configure a new RDF environment between the two backup systems, so
that one operates as the primary and the other as the backup system. Then, you can
start your applications on the new primary and have full RDF protection on the backup.
For situations where the backup systems are very far apart when the primary fails, for
example when an Expand line between systems is down for several hours, you must
take steps to ensure that the audit missing from the system with the least audit is still
on disk at the backup system with the most audit. Normally, an RDF purger process
purges image files as soon as it determines that they are no longer needed. For triple
contingency, however, the purger on the system with the most image audit must retain
all files that might be needed for this feature, even if those files are no longer needed in
that purger’s own RDF configuration. To support this need, RDF provides the PURGER
RETAINCOUNT configuration parameter, which lets you specify the number of image
files that should still remain on disk when they are no longer needed. You set
RETAINCOUNT to a value that reflects how far apart you believe your two backup