RDF System Management Manual
Table Of Contents
- RDF System Management Manual
- What’s New in This Manual
- About This Manual
- 1 Introducing RDF
- RDF Subsystem Overview
- RDF Processes
- RDF Operations
- Reciprocal and Chain Replication
- Available Types of Replication to Multiple Backup Systems
- Triple Contingency
- Loopback Configuration (Single System)
- Online Product Initialization
- Online Database Synchronization
- Online Dumps
- Subvolume- and File-Level Replication
- Shared Access DDL Operations
- EMS Support
- SMF Support
- RTD Warning Thresholds
- Process-Lockstep Operation
- Support for Network Transactions
- RDF and NonStop SQL/MX
- Zero Lost Transactions (ZLT)
- Monitoring RDF Entities With ASAP
- 2 Preparing the RDF Environment
- 3 Installing and Configuring RDF
- 4 Operating and Monitoring RDF
- 5 Managing RDF
- Recovering From File System Errors
- Handling Disk Space Problems
- Responding to Operational Failures
- Stopping RDF
- Restarting RDF
- Carrying Out a Planned Switchover
- Takeover Operations
- Reading the Backup Database
- Access to Backup Databases in a Consistent State
- RDF and NonStop SQL/MP DDL Operations
- RDF and NonStop SQL/MX Operations
- Backing Up Image Trail Files
- Making Online Dumps With Updaters Running
- Doing FUP RELOAD Operations With Updaters Running
- Exception File Optimization
- Switching Disks on Updater UPDATEVOLUMES
- 6 Maintaining the Databases
- 7 Online Database Synchronization
- 8 Entering RDFCOM Commands
- 9 Entering RDFSCAN Commands
- 10 Triple Contingency
- 11 Subvolume- and File-Level Replication
- 12 Auxiliary Audit Trails
- 13 Network Transactions
- Configuration Changes
- RDF Network Control Files
- Normal RDF Processing Within a Network Environment
- RDF Takeovers Within a Network Environment
- Takeover Phase 1 – Local Undo
- Takeover Phase 2 – File Undo
- Takeover Phase 3 – Network Undo
- Takeover Phase 3 Performance
- Communication Failures During Phase 3 Takeover Processing
- Takeover Delays and Purger Restarts
- Takeover Restartability
- Takeover and File Recovery
- The Effects of Undoing Network Transactions
- Takeover and the RETAINCOUNT Value
- Network Configurations and Shared Access NonStop SQL/MP DDL Operations
- Network Validation and Considerations
- RDF Re-Initialization in a Network Environment
- RDF Networks and ABORT or STOP RDF Operations
- RDF Networks and Stop-Update-to-Time Operations
- Sample Configurations
- RDFCOM STATUS Display
- 14 Process-Lockstep Operation
- Starting a Lockstep Operation
- The DoLockstep Procedure
- The Lockstep Transaction
- RDF Lockstep File
- Multiple Concurrent Lockstep Operations
- The Lockstep Gateway Process
- Disabling Lockstep
- Reenabling Lockstep
- Lockstep Performance Ramifications
- Lockstep and Auxiliary Audit Trails
- Lockstep and Network Transactions
- Lockstep Operation Event Messages
- 15 NonStop SQL/MX and RDF
- Including and Excluding SQL/MX Objects
- Obtaining ANSI Object Names From Updater Event Messages
- Creating NonStop SQL/MX Primary and Backup Databases from Scratch
- Creating a NonStop SQL/MX Backup Database From an Existing Primary Database
- Online Database Synchronization With NonStop SQL/MX Objects
- Offline Synchronization for a Single Partition
- Online Synchronization for a Single Partition
- Correcting Incorrect NonStop SQL/MX Name Mapping
- Consideration for Creating Backup Tables
- Restoring to a Specific Location
- Comparing NonStop SQL/MX Tables
- 16 Zero Lost Transactions (ZLT)
- A RDF Command Summary
- B Additional Reference Information
- C Messages
- D Operational Limits
- E Using ASAP
- Index
Triple Contingency
HP NonStop RDF System Management Manual—524388-003
10-8
Using ZLT to Achieve the Same Protection
then continue application processing from system \B to system \C or from system \C to
system \B within minutes of losing system \A.
Using ZLT to Achieve the Same Protection
To achieve the same result using the RDF/ZLT product you configure system \B as the
ZLT standby node for both RDF subsystems #1 and #2. Upon losing system \A, you
connect the remote mirrors to system \B and issue TAKEOVER commands on both
systems \B and \C. Since, as part of the ZLT takeover, each subsystem fetches the
final audit data from the remote mirrors connected to system \B, both backup
databases receive the same data. When the takeover operations are complete, the
databases on systems \B and \C are logically identical to one another, and you have
achieved that without executing a COPYAUDIT command (and you also have not lost
any committed data).
Summary
To be able to use the triple contingency feature, you must:
1. Establish two RDF configurations with the same primary system and separate
backup systems.
2. Ensure that the hardware configurations of the two backup systems are identical
with regard to data volumes and image trail volumes.
3. Ensure that the data volumes and image trails of the two RDF configurations are
configured identically with respect to the two backup systems (with the few minor
exceptions noted earlier in this section).
4. Set an adequate purger RETAINCOUNT parameter on the backup systems (it
must be the same on both).
Upon loss of the primary system, you must do as follows:
1. Issue a TAKEOVER command on both backup systems.
2. When the takeovers have completed successfully, examine the EMS event log on
both backup systems for a 735 message to determine which system is missing
audit information.
3. On the system with the least amount of audit information, issue a COPYAUDIT
command specifying the name of the other backup system and its RDF control
subvolume.
4. When the COPYAUDIT command has completed successfully, issue a second
TAKEOVER command on that same system.
5. Initialize, configure, and start RDF on whichever system you want
to be the primary in the new configuration.
6. Start application processing on the new primary system.