Availability Guide for Application Design

Data Protection and Recovery
Availability Guide for Application Design—525637-004
4-14
Remote Duplicate Transactions
time needed for the backup site to take over, and the time needed to switch back again
to the primary site once the primary site is restored.
The time required for the backup system to take over depends on the application but is
usually several minutes. Upon failure at the primary site, RDF processes at the backup
site must finish updating the database with the received image records. When the
update is finished, the following operational tasks must be done at the backup site
before transaction processing can resume:
•
Enable all backup databases for auditing.
•
Start the application.
•
Switch communication access.
Using NonStop RDF/MP or NonStop RDF/MPX For Triple-
Contingency Configurations
If you have the option of using two identical systems for backup, you can use either
NonStop RDF/MP or NonStop RDF/MX to provide a triple-contingency database
configuration. A triple-contingency configuration consists of a primary site and two
backup sites, each running identically configured copies of NonStop RDF or
NonStop RDF/MPX. For example, imagine that the configuration shown in Figure 4-3
on page 4-13 also included a site in Los Angeles that was identical to the Chicago site.
Upon failure of the primary site, operations performs a takeover at both backup sites
and resynchronizes the audit records. Operations can then choose one of the
remaining sites to be the new primary site, enable auditing on that system, start the
application, switch communication access, and resume fault-tolerant processing with a
single backup site long before the original primary site is restored.
Remote Duplicate Transactions
An alternative to the RDF audit-record approach is to perform transactions against two
identical databases. Two such schemes are described here: one in which the
transaction logic executes in a switching system rather than in the server, and one in
which the transaction logic executes in the server.
When Transaction Logic Executes in a Switching System
Figure 4-4 on page 4-16 shows one such scheme in which a switching system—a
system or application that routes messages and data between points on a network— is
used to direct the same information to a local node and a remote node. In this case,
the transaction logic is executed in the switching system and not in the server process.
Transaction logic in the switching system and TMF keep the databases synchronized.
On receiving a request for a transaction from a user somewhere on the network, the
switching system sends a request to server processes running on each system.
Because the switching system encloses both requests within transaction begin and
end statements, either both requests are done or neither is done.