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

14 Network Transactions
The RDF/IMPX and RDF/ZLT products are able to guarantee backup database consistency for
transactions that update data residing on more than one RDF primary system. RDF/IMPX and
RDF/ZLT can map the volumes being protected to both the MAT and auxiliary audit trails.
NOTE: Network transaction processing is currently not supported in configurations that use
the triple contingency feature. You must use RDF/IMPX or RDF/ZLT to protect all databases
open to network transactions.
Without planning for network transaction support, the RDF product cannot guarantee database
consistency among the associated backup systems following the failure of one of the primary
systems.
Support for network transactions requires two major external changes.
1. If you have a distributed database spread over several RDF primary systems, you must
configure an RDF network wherein each primary system residing on its own, mutually
exclusive node has its own RDF subsystem that replicates its local data to its own backup
system. This is referred to as an RDF network because each RDF subsystem knows the names
of the systems protected by all other RDF subsystems in the network. One, and only one,
RDF subsystem within the network is configured as the network master.
2. If you lose one or more RDF primary systems in the RDF network, you must execute RDF
takeover operations on all backup systems in the network.
For those primary systems still alive, you must first quiesce all application activity (both
local and remote) so that no further database updates are being performed, and then bring
down the communication lines between the primary and backup systems before initiating
the takeover.
With network transaction support, you must now be more careful when creating Enscribe files
that have alternate key files. Specifically, when you create an Enscribe file with an altkey file you
must ensure that both files reside on the same primary system and that both are protected by
the same RDF subsystem. If you do not do so, then the updater responsible for creating the file
on the backup system will not create the file; rather, it will report an error 740 when it determines
that the altkey file is not protected by its RDF subsystem.
For RDF/ZLT configurations, all nodes that participate in a network transaction need to be
configured in the RDF network for RDF/ZLT protection.
Configuration Changes
To support network transactions, several configuration attributes and a configuration record
have been added to the RDF configuration file.
Order of Configuration Steps
Perform the steps in the network configuration procedure in this order:
1. Perform a cleanup operation purging the RDF control subvolumes on the network master
and all non-network master subsystems.
2. Issue an INITIALIZE RDF command on the network master subsystem.
3. Issue an INITIALIZE RDF command on each non-network master subsystem.
4. Configure each non-network master subsystem with all the commands SET/ADD RDF,
MONITOR, UPDATER, NETWORK, and so forth. Do not perform a VALIDATE
CONFIGURATION yet.
Configuration Changes 275