Volume Replicator 7.4.1 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)
Understanding checkpoints
Volume Replicator checkpoints are user-defined markers in the Primary Replicator Log. The RVG and RLINK (Secondary) checkpoints are two types of checkpoints. The RVG checkpoint has a start (checkstart) and an end (checkend) and can be used for initial synchronization. The RLINK (Secondary) checkpoint is used to restore Secondary volumes in case of failure.
Checkpoints are used to perform the tasks which are as follows:
Synchronizing the Secondary while the Primary application is active
Restoring the Secondary data volumes
The Secondary data volumes must be synchronized with the Primary data volumes before replication can start, that is, after you add a Secondary to the RDS, after a Secondary data volume error, or after Replicator Log overflow. Volume Replicator enables you to synchronize the Secondary data volumes while the application is active on the Primary. If you use the Automatic Synchronization feature of Volume Replicator to synchronize the Secondary data volumes over the network, Volume Replicator ensures that the Secondary data volumes are consistent and up-to-date when the synchronization process completes.
If you use the backup and checkpoint method for synchronizing the Secondary and if the Primary application is active during the backup process, then, after you restore the backup on the Secondary, the Secondary data volumes are inconsistent and not up-to-date.
To make the Secondary consistent and up-to-date, Volume Replicator must transfer all the blocks that changed during the backup process, in the order that they changed. In a Volume Replicator environment, all writes to the Primary data volumes are logged to the Replicator Log; therefore, Volume Replicator can transfer the writes that occurred during the backup to the Secondary. To do this, Volume Replicator must know the start and end of the backup process. RVG checkpoints are used to indicate this start position (checkstart) and end position (checkend) in the Replicator Log.
Because the checkpoint information is stored in the Replicator Log, checkpoints become invalid when the Replicator Log wraps around. The same checkpoint and tape backups can be used to synchronize the data volumes on multiple Secondary hosts if the checkpoint remains valid.
Note:
If a checkpoint becomes invalid, performing the synchronize operation using that checkpoint fails.
A backup utility may copy previous contents of the blocks corresponding to Write 3 (event 5) but copy updated contents of the blocks corresponding to Write 4 (event 7).
However, Volume Replicator logs all the writes to the Replicator Log (events 4 and 6). Note that a checkstart was performed (event 1) before the backup was started (event 2) and a checkend was performed (event 9) after the backup was completed (event 8). When you start replication with this checkpoint after the backup is restored on Secondary, Volume Replicator can transfer all the writes between checkstart and checkend and make the Secondary data volumes up-to-date and consistent.