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)
IBC messaging commands
Use the vxibc command to perform IBC messaging operations in the Volume Replicator environment. It allows applications to insert user-defined control messages into a Replicated Volume Group's (RVG) update stream. An IBC message is delivered on the Secondary node in the same order that it was sent from the Primary. Before delivery of the message on the Secondary node, any previous update activity is flushed. You have the option to allow subsequent updates to be applied immediately to the Secondary data volumes or freeze replication until released by the application.
Each application must be registered under an identical application name before beginning with the IBC messaging operations.
Note:
If the Secondary host crashes, the registration is not applicable anymore, whereas IBC messages once sent are still available for sending even after the host crashes as they are logged in the Replicator Log. Veritas therefore recommends that you start and register the application on the Secondary host as a part of system startup.
The first operand to the vxibc command is a keyword that determines the specific operation to perform. The vxibc command has various keywords to perform the different IBC messaging functions. Each operation can be applied to only one dynamic disk group at a time. You must specify the name of the dynamic disk group using the -g option.
The following table describes the keywords that can be specified for vxibc command.
Table: vxibc command options
Option | Description |
---|---|
-D <deliver_timeout> | The deliver_timeout argument to the -D option specifies the time-out value in seconds for delivery of an IBC message after it has arrived at the Secondary RVG. When the time-out expires, the Secondary RVG discards the IBC message and continues replication. Default value for deliver_timeout is 10 minutes. A deliver_timeout value of 0 means infinite time-out. The deliver_timeout value should be specified only on the Primary. |
-F <freeze_timeout> | The freeze_timeout argument to the -F option specifies the time-out value in seconds between delivery of an IBC message on the Secondary node and execution of an unfreeze operation on the Secondary RVG. When the time-out expires, replication continues at the Secondary RVG. Default value for freeze_timeout is 10 minutes. A freeze_timeout value of 0 means infinite time-out. |
-N | This option is used with a send or a regsend operation and specifies that replication is not to be frozen when the IBC message arrives on the Secondary RVG. |
-R <receive_timeout> | The receive_timeout argument with the -R option specifies the time-out value in seconds to block the waiting for an IBC message if the receive or the regrecv operation is run in blocking mode, that is, without the -n option. Default value for receive_timeout is 10 minutes. A receive_timeout value of 0 means infinite time-out. |
-f <filename> | Used with the send or the regsend operation, to read the message from the specified file name. When this option is used with the receive or the regrecv operation, the received message is saved to a file with the specified file name. The maximum size of the message file can be 128KB. If the message data is more that 128 KB the rest is ignored. |
-g <diskgroup> | Specifies the name of disk group containing the RVG on which the IBC operation is to be performed. This option must be used with every vxibc command keyword. |
-l <buf_length> | The buf_length argument to the -l option specifies the maximum length in bytes of the IBC message the user is willing to receive. If the length of the received message is greater than the value that buf_length specifies, then the message is truncated to buf_length bytes. |
-m <message> | The message argument with the -m option is a user supplied string that is sent with the IBC message from the Primary node and received by the application performing the receive or the regrecv operation on the Secondary RVG. If the send or the regsend operation is executed without this option, a blank message is sent to the Secondary RVG. If a message consists of more than one word, it must be enclosed within double quotes. The format of the message is user-defined and may be used by the application performing IBC operations to exchange values or coordinate what tasks are to be performed. To send a large message that cannot be accommodated on the command line, use the -f option. |
-n | This option is used with the receive or the regrecv operations and indicates that the operation is non-blocking. Default is to block for receiving the IBC message. |