Home > Veritas Storage Foundation™ Volume Manager Manual Pages
VXIBC (1M) |
Maintenance Commands |
vxibc [-g diskgroup] [-D deliver_timeout] register application_name rvg
vxibc [-g diskgroup] [-R receive_timeout] [-f filename] [-l buf_length] regrecv application_name rvg command [argument ]
vxibc [-g diskgroup] [-D deliver_timeout] [-N | -F freeze_timeout] [-f filename | -m message] regsend application_name rvg [rlink ]
vxibc [-g diskgroup] [-N | -F freeze_timeout] [-f filename | -m message] send application_name rvg [rlink ]
vxibc [-g diskgroup] status rvg
vxibc [-g diskgroup] stoprecv application_name rvg
vxibc [-g diskgroup] unfreeze application_name rvg
vxibc [-g diskgroup] unregister application_name rvg
The vxibc command-line utility performs In-Band Control Messaging (IBC) operations. It allows applications to inject user-defined control messages into the update stream of a Replicated Volume Group (RVG). An IBC message is delivered on the Secondary node in causal order with respect to other activity on the data volumes. Before delivery of the message on the Secondary node, any previous update activity is flushed. You have the option of either allowing subsequent updates to be applied immediately to the Secondary data volumes, or of freezing replication until released by the application.
IBC messages are guaranteed to be delivered at least once and may be delivered multiple times if an error such as network outage or machine crash occurs during the delivery. An application must tolerate multiple delivery of the same IBC message including handling the freeze-unfreeze cycle.
Typically, IBC is used to checkpoint application-level consistency within an RVG over and above the update-level consistency maintained by VVR. An application running on the Primary node can insert a freeze IBC at a point at which the application considers its raw volume contents to be consistent, such as during the database hot-backup mode. A companion application running on the Secondary node is assured that the RLINK is application-level consistent when it receives the IBC message and will remain so until it unfreezes the RLINK. The application on the Secondary node may perform a backup of the data volumes, take a snapshot, or carry out any similar function during this time period.
Each vxibc command keyword specifies an operation that can be performed. Each operation can be applied to only one disk group at a time. The rlink and rvg operands are used to determine a default local disk group according to the standard disk group selection rules described in vxintro(1M). If required, a local disk group can be specified using the -g diskgroup option.
- receive
- Receives the IBC message sent from the Primary RVG on the Secondary node. The application_name must be previously registered for the Secondary RVG, rvg. Secondary replication is frozen at the point in time in the RLINK's update stream at which the IBC message was inserted at the Primary RVG. Secondary replication remains frozen until an unfreeze operation is performed, or until the expiry of the freeze_timeout that was specified when the IBC message was sent. The default behavior for the receive operation is to block until an IBC message is received. The -n option makes the receive operation non-blocking, and returns if there is no message to receive. If the operation succeeds, the received message is displayed. An unsuccessful exit code indicates that messages were dropped and the drop count is displayed to the standard error output.
- register
- Registers the application name, application_name, for the RVG, rvg. Before being able to perform IBC operations on an RVG, you must register an application name for it. The sender and the receivers of the IBC message must register the same application_name. Multiple application names (up to a maximum of 32) can be registered for an RVG. Registration is not persistent across node crashes. Applications on rebooted nodes must be re-registered (see the Veritas Volume Replicator Administrator's Guide).
- regrecv
- As a single step, this operation registers an application, receives an IBC message, runs the command with the provided arguments passed as command-line argument to the regrecv operation, unfreezes the Secondary RVG, rvg, and unregisters the application.
- regsend
- As a single step, this operation registers an application, sends an IBC message, and unregisters the application. regrecv operation must be started on the Secondary node before performing regsend on the Primary node, Otherwise, there is no companion registered application name on the Secondary node, and the IBC message is discarded.
- send
- Sends the IBC message from a Primary RVG, rvg, for which the application name, application_name, has been previously registered. The IBC message is inserted into the update stream of the specified rlinks. If no rlink is specified, the message is sent to all RLINKs currently attached to the Primary RVG. Secondary replication is frozen at the point in time in the rlink's update stream at which the IBC message is inserted at the Primary RVG. Secondary replication remains frozen until an unfreeze operation is performed or the specified freeze_timeout expires.
- status
- Displays the currently registered application names for the RVG, rvg.
- stoprecv
- Terminates a receive or regrecv operation started by another process. Normally a receive or a regrecv operation terminates when the IBC message is received from the Primary node or if no message is received within the receive timeout period. Use the stoprecv operation to prematurely terminate the receive or regrecv operation before the IBC message arrives on the Secondary node.
- unfreeze
- Unfreezes the Secondary rvg. This operation must be performed after receiving the IBC message using the receive operation. The unfreeze operation permits replication to continue by allowing updates that were performed on data volumes after the send operation was executed on the Primary RLINK to be applied to the Secondary RVG, rvg.
- unregister
- Unregisters the application name, application_name, for the RVG, rvg. The application name must have been previously registered for the RVG. No further send operations against the application name are possible after unregistering on the Primary RVG. IBC messages already introduced into the update stream before unregistering are delivered on the Secondary RVG. Unregistering on the Secondary causes the receive and the unfreeze operations for the application name to fail and any IBC messages arriving for the application name to be discarded.
See vxintro(1M) for a list of standard exit codes for Veritas Volume Manager (VxVM). Other IBC-specific errors may be returned with values greater than or equal to 64. These are defined in vxvm/volibc.h:
Veritas Volume Replicator Administrator's Guide
Last updated: 28 Jul 2003
Copyright ©2009 Symantec Corporation
All rights reserved.