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)
Identifying the most up-to-date Secondary
Use the vxrlink updates command to identify the most up-to-date Secondary in a Volume Replicator configuration. The vxrlink updates command can be issued only on a Secondary.
Syntax for vxrlink updates command
vxrlink [-g <diskgroup>] [-T] updates <rlink>
For multiple Secondaries, the vxrlink updates command enables you to determine the Secondary that contains the most up-to-date data and hence the most suitable replacement for the Primary in the case of a take over.
For a single Secondary, the vxrlink updates command can be used to determine the extent to which the Secondary is behind the Primary. You can decide whether or not to take over the Primary role by looking at the update ID of the Secondary and the number of updates by which the Primary is ahead of the Secondary.
If the Secondary is paused and is behind the Primary, the vxrlink updates command may show inaccurate values as long as the Replicator Log is being written to, because the status is the same as it was before the pause. However, if the Replicator Log overflows and the DCM is activated then the vxrlink updates command output displays the correct value by which the Secondary is behind. When the Primary switches to the DCM mode, it reconnects the Secondary RLINK and also sends updated information. This information also includes the last update sequence number on the Primary and the time that is associated with this update. Hence, the latest values are displayed.
To display the output only in terms of an update ID, use the vxrlink updates command without the -T option. The output displays the update ID as a sequence number. A sequence number is a 64-bit value that increases incrementally and hence is unique for each new update and is assigned for every new update that arrives at the Primary. The output of the vxrlink updates command displays the 64-bit number as two 32-bit sequence numbers that are separated by a dot. For example,
high_seq_num.low_seq_num
To display the exact time on the Primary at which the Secondary is up-to-date use the vxrlink updates command with the -T option. The -T option displays the exact time in hours by which the Secondary is behind.
The output of the vxrlink -T updates command is displayed in a three-column structure with two rows; ID and Time. The ID row displays the update IDs.
If the local time of the Primary node has been adjusted to accommodate the daylight savings or for any other reason, then the updates in the Replicator Log may still have the time stamp based on the earlier clock settings. This may appear incorrect. However, the new updates are time stamped based on the changed time settings.
The following table describes the values of the most up-to-date Secondary.
Table: Most up-to-date secondary status
Values | Last update on Primary | Secondary up-to-date as of | Secondary behind by |
---|---|---|---|
ID | 62010.0 | 62010.0 | 0 |
Time | 12/24/2005 2:31:44 P.M. | 2/24/2005 2:31:44 P.M. | 0 hours 0 mins 0 secs |
The time stamp in the Time row indicates the time at which the update was written on the Primary. The first column displays the last update ID and the time at which it was written on the Primary.
The second column displays the last update ID that has been received on the Secondary and the time when it was written on the Primary. If the Secondary is up-to-date then the ID and the time in this column is the same as that in the first column. However, if the Secondary is behind, then the ID and the time is different from that in the first column.
The third column indicates the exact number of updates by which the Secondary is behind. This value is obtained as a difference between the second and first column.
Note:
If the system time is reset to a value different from that of the current system time, then, the output of the vxrlink -T updates command appropriately shows a negative or an inaccurate value, until the updates that were done before resetting the system time get replicated.