RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

committed update of your application. Additionally, Primary DB 1 and Backup DB 1 are no longer
in synch. Even though the updater on \B had its transaction aborted, that updater will re-apply the
application update to Backup DB 1. When done, Primary DB no longer has the update, but Backup
DB 2 does.
Although this example describes a reciprocal configuration, the same basic problem can happen
with chain replication. In the chain case, the extractor for RDF Subsystem 2 would be sending a
Backout generated update to \C where the file or table involved in the update does not even exist.
This will cause the updater responsible for $DATA on \C to stall, waiting for you to create the file
or table on \C.
The same effect occurs when you set up reciprocal environments or chain environments, where
you also have the REPLICATEPURGE attribute set. In this case, the updater purges the file through
the file system, and the resulting audit record does not indicate that it was generated by an updater.
If the extractor sends the audit record for the purge to its backup system, the updater might purge
a file you do not want purged, or it might encounter an error 11.
To prevent these problems in a reciprocal configuration or chain configuration, you must ensure
that Backup DB 1 and Primary DB 2 are on mutually exclusive volumes. For example, put Primary
DB 1 and Backup DB 1 is on $DATA1 and put Primary DB 2 and Backup DB 2 on $DATA2. Thus
the extractor can filter out the audit by volume name and not depend on records being marked as
updater generated.
Alternatively, if your two databases must share the same disks, then you must explicitly specify
which files and tables you want replicated by each RDF subsystem. For example, RDF Subsystem
1 would INCLUDE only Primary DB 1, and RDF Subsystem 2 would INCLUDE only Primary DB 2.
Available Types of Replication to Multiple Backup Systems
RDF allows you to replicate database changes from a single primary system to multiple backup
systems. This makes possible simultaneous read-only access to all of the backup systems, a capability
particularly desirable for query-intensive applications where a central database can be distributed
to several remote systems for local query processing.
Replication to multiple backup systems is achieved by establishing multiple RDF configurations,
each protecting the same database on the primary system. As an example, you might want to
replicate the same data to different backup systems:
RDF Configuration #1
\A ---------> \B
RDF Configuration #2
\A ---------> \C
RDF Configuration #3
\A ---------> \D
You can also have two RDF configurations replicating two separate databases (DB1 and DB2)
from the same primary system to two different backup systems:
RDF Configuration #1, protecting database DB1
\A ---------> \B
RDF Configuration #2, protecting database DB2
\A ---------> \C
As a third possibility, you can also have two RDF configurations replicating two separate databases
(DB1 and DB2) from the same primary system to the same backup system:
RDF Configuration #1, protecting database DB1
\A ---------> \B
RDF Configuration #2, protecting database DB2
\A ---------> \B
In the preceding examples, each RDF configuration operates entirely independently of the other
RDF configuration primaried on the same node; that is, each RDF system has its own extractor and
Available Types of Replication to Multiple Backup Systems 47