RDF System Management Manual for H-Series RVUs (RDF 1.8)

In the preceding examples, each RDF configuration operates entirely independently of the other
RDF configuration primaried on the same node; that is, each RDF configuration has its own
extractor and monitor process. In this way, line failures affecting one configuration might not
necessarily affect the others (depending on the configuration).
RDF Control Subvolume
The INITIALIZE RDF command includes a control subvolume suffix parameter (SUFFIX char
), where char is an alphanumeric character. If you include this parameter, the RDF control
subvolume on $SYSTEM will be the local (primary) system name without the backslash and with
the specified character appended to it. If you omit this parameter, the RDF control subvolume
on $SYSTEM will merely be the local system name without the backslash.
If you want to have several RDF configurations with the same primary system, each configuration
must have its own control subvolume and you must use the SUFFIX char parameter. Thus, if
the name of your primary system is \BOSTON and you assign the suffix “1”, the control
subvolume will be named BOSTON1. If you have two RDF configurations primaried on
\BOSTON, you could initialize one RDF configuration with the suffix “1” and the other with
the suffix “2” so that their control subvolumes would be named, respectively, “BOSTON1” and
“BOSTON2”.
For a description of the files in the control subvolumes on the primary backup systems, see RDF
System Files in Appendix B of this manual.
Other RDF Features
Triple Contingency
If you are replicating your database to multiple backup systems, you can perform an RDF takeover
to any of the backup systems upon loss of the primary system and continue application processing
on the new system within minutes. To proceed with full RDF protection, however, you must:
1. Initiate a takeover on two of the backup systems.
2. Synchronize the two databases.
3. Configure the two systems as a primary-backup pair.
4. Initialize and start RDF on the system that you want to be the new primary system.
Depending upon the size of your database, the second step listed, database synchronization,
could take days to accomplish without the RDF triple contingency feature. Triple contingency,
however, streamlines this step, enabling you to achieve rapid database synchronization after a
takeover operation. Triple contingency allows your applications to resume, with full RDF
protection, within minutes after the loss of your primary system, provided that the two systems
are not too far behind.
The following discussion assumes you do not have ZLT functionality. For triple contingency
with ZLT, see Chapter 10 (page 255).
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:
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 might 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
58 Introducing RDF