HP NonStop RDF, Руководство по управлению

Страница: 52 / 478

when the updater for RDF Subsystem 2 on \A applies this record to Primary DB 1, it thereby
backs out the 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
52 Introducing RDF