Volume Replicator 7.4.2 Administrator's Guide - Windows
- Understanding Volume Replicator
- About Volume Replicator
- Basic Volume Replicator terms
- Building blocks of Volume Replicator
- Understanding replication in the Volume Replicator environment
- Modes of replication
- Understanding data flow in Volume Replicator asynchronous mode
- Managing data during failure and recovery
- Replication concepts
- About using Volume Replicator as a disaster recovery tool
- Understanding how Volume Replicator logs writes to the Replicator Log
- Understanding replication settings for a Secondary
- Measures to protect log overflow and replication latency
- Pausing the replication
- Synchronizing the Secondary
- Understanding Volume Replicator support for FlashSnap
- About Synchronized Snapshots
- Understanding Bunker replication
- Understanding Volume Replicator Support for TCP Multi-Connection
- About Volume Replicator memory monitoring and control support
- About Volume Replicator Graphs
- Setting up replication
- Security considerations for Volume Replicator
- Setting up replication using the Setup Replicated Data Set wizard
- Setting up the Bunker RVG for replication
- Using the VEA Console for Volume Replication Operations
- Monitoring replication
- Interpreting the information in the Volume Replicator views
- Monitoring replication using the VEA console
- Checking replication performance using vxrlink stats
- Administering Volume Replicator
- Adding volumes
- Administering the RVG
- Administering replication
- Managing checkpoints
- Pausing replication using Volume Replicator
- Creating snapshots for the data volumes
- Creating synchronized snapshots using the VSS Snapshot wizard
- Administering Bunker replication
- Performing disaster recovery operation
- Deleting Volume Replicator objects
- Accessing data on Secondary host
- Performing automated system recovery (ASR)
- Alternative methods to synchronize the Secondary faster
- Obtaining statistical information through Volume Replicator Graphs
- Using the command line interface
- Administering the RDS using the vxrds command
- Resizing the data volumes
- Displaying the network statistics for the RLINK
- Administering the RVGs using the vxrvg command
- Displaying information using the vxprint command
- Creating snapshots using the vxsnap command
- Administering replicated volumes using the vxvol command
- Displaying and changing replication ports using the vrport command
- Administering the RVG using the vxedit
- Administering the RVG using the vxassist command
- Tuning Volume Replicator
- Examples: Using the command line
- Example 1: Setting up replication using the command line interface
- Example 3: Using Bunker node for disaster recovery
- Example 4: Using synchronized snapshots to restore data
- Configuring Volume Replicator in a VCS environment
- Components of a VCS cluster
- Illustrating a highly available Volume Replicator setup
- How the agents work
- Configuring the agents
- Working with existing replication service groups
- Configuring Volume Replicator with Hyper-V
- Advanced settings in Volume Replicator
- Troubleshooting Volume Replicator
- Recommendations and checks
- Recovering from problems in a firewall or NAT setup
- Recovering from problems during replication
- Error when configuring the VxSAS Service
- Operation time-out errors
- Problems when configuring Volume Replicator in a VCS environment
- Problems when setting performance counters
- Appendix A. Services and ports
- Appendix B. Using the vxrsync utility
- Appendix C. VR Advisor (VRAdvisor)
General notes on take over operation
For the takeover operation to be successful, you need to take the following into consideration.
Some considerations are as follows:
If the original Primary has multiple Secondary hosts, and the RLINKs between every pair of Secondaries have not been created, then, after migrating the Primary role to one of the Secondaries or performing takeover on one of the Secondaries, all the remaining Secondaries in the RDS become orphaned. You must manually delete these Secondaries and then again add them as Secondaries to the new Primary.
However, if you have created RLINKs between each pair of Secondaries in the RDS, then after a migrate or takeover operation, use the following steps to add the orphaned Secondaries back in the RDS:
On each orphaned Secondary host, detach the RLINK on this orphan Secondary pointing to the original Primary (the Primary host before migrate or takeover).
The orphan Secondaries join the RDS of the new Primary. Now, start replication with Automatic Synchronization on each of these orphans.
After the original Primary host becomes available again, you may want to failback to this host. To do this, first synchronize the original Primary with the new Primary, and then migrate the Primary role back to the original Primary. If you had not deleted the Secondary RVGs of the original Primary hosts, then after a migrate operation you need not perform an Add Secondary operation to add the Secondaries back to the original Primary. However, as the replication to these Secondaries is stopped or is inactive, you must start replication to these Secondaries and synchronize them with the Primary.
After performing a takeover with fast-failback, Veritas recommends that you do not detach the RLINKs on the original Primary using the vxrlink det command or convert the original Primary to a Secondary using the Make Secondary option. However, if you do perform these operations, you must perform a complete synchronization of the original Primary with the new Primary.