Table of Contents
Advertisement
10 Triple Contingency
The triple contingency feature makes it possible for your applications to resume running with
full RDF protection within minutes after loss of your primary system.
NOTE:
Replication of network transactions is not supported in conjunction with the triple
contingency feature, nor is the replication of auxiliary audit trails. You can, however, use the
RDF/ZLT product to achieve triple contingency protection for RDF configurations that include
auxiliary audit trails (that capability is described at the end of this chapter).
Overview
The triple contingency feature is made possible by the ability to replicate to multiple backup
systems. Physically, triple contingency consists of two RDF configurations with the same primary
system but separate backup systems:
RDF Configuration #1
\A ---------> \B
RDF Configuration #2
\A ---------> \C
Both RDF systems are virtually identical to one another, but one replicates data to the backup
system \B and the other to the backup system \C.
Functionally, the triple contingency feature consists of:
•
A purger configuration parameter, RETAINCOUNT, that prevents the purger process from
purging image trail files that might be needed for triple contingency recovery.
•
An RDFCOM command, COPYAUDIT, that quickly synchronizes the two backup databases
after loss of the primary system and successful takeovers on the backup systems.
Requirements
You must be running the same release of RDF on all three systems.
All protected data volumes in both RDF environments must be mapped to the Master Audit
Trail (MAT) of the associated primary system.
It is recommended, but not required, that the two backup systems have the same hardware
configuration. They must, however, have the same data volumes and image trails.
The two RDF configurations must be configured identically (with a few minor exceptions, such
as the suffix characters specified in the INITIALIZE RDF command and the process names for
the extractors and monitors of the two RDF subsystems).
How Triple Contingency Works
In general, the triple contingency feature operates in this manner:
•
The RETAINCOUNT configuration parameter on both backup systems prevents the purger
process from purging image trail files that might be needed for triple contingency recovery.
•
If the primary system fails, you execute two takeovers: one on each backup system. Upon
successful completion of both takeovers (signalled by a 724 message in the EMS event log
of both backup systems), the databases on the two backup systems will almost assuredly
not be identical: one of the extractors will have been ahead of the other in its RDF processing
when the failure occurred.
•
Examine the EMS event log on both backup systems for a 735 message. That message, which
follows the 724 message in the log, specifies the last position in the MAT that was seen by
the receiver process. Compare the MAT positions in the two 735 messages and determine
which of the two systems was further behind in its RDF processing when the failure occurred
Overview
271
- Quick Links:
- Supported Release Version Updates (Rvus)
Hide quick links:
Advertisement
Table of Contents
