VERITAS Volume Replicator Utility States

RVG Utility States

This section lists the RVG states and their descriptions.

• EMPTY---State of a newly created RVG. Issue the vxrvg start command to start the RVG.
• CLEAN---The RVG is stopped. This state is seen after issuing the vxrvg stop command. Issue the vxrvg start command to start the RVG.
• ACTIVE---This determines if I/O can be performed to the data volumes:
• If the KSTATE is ENABLED, I/O can be performed.
• If the KSTATE is RECOVER, I/O cannot be performed (this state usually occurs after a system crash).
• If the KSTATE is DISABLED, I/O cannot be performed.
• FAIL---A data volume error occurred.

RLINK Utility States

This section lists the RLINK states and their descriptions.

• UNASSOC---Not associated to an RVG.
• STALE---Associated to an RVG but needs complete synchronization between the Primary and Secondary.
• ACTIVE---Replicating or ready to replicate.
• PAUSE---Replication is not active because of an administrative action or a configuration error.
• FAIL---Data volume error occurred on the Secondary or the vxrlink -w pause command was issued on the Secondary. For more information, see Inconsistent RLINKs.
• PAUSING---Temporary state while vxrlink pause is executing.
• RESUMING---Temporary state while vxrlink resume is executing.
• RESTORING---Temporary state while vxrlink restore is executing.

Inactive RLINKs

An RLINK is considered inactive whenever the Primary cannot send data to the Secondary for any reason, such as:

• A temporary failure of the network connection between the Primary and the Secondary.
• A failure of the Secondary node.
• The execution of a vxrlink pause command by an administrator.

The data to be sent on an inactive RLINK is buffered in the SRL. If the RLINK remains inactive for an extended period, the SRL may not be able to buffer new writes; even if it can, the Secondary becomes increasingly out-of-date. So it is important that the SRL is large enough to accommodate most of the inactive periods. To help control the behavior of an inactive RLINK, SRL overflow protection may be used. For details, see Setting the SRL Overflow Protection.

STALE RLINK State

An RLINK is STALE when the Secondary data volumes do not contain the Primary's data and cannot be brought up-to-date using the SRL. When an RLINK is first created, its initial state is STALE.

RLINKs can enter the STALE state when they are detached either manually (via vxrlink det) or by the kernel (on the Primary only, if an SRL media error occurs). An RLINK can also become STALE if the log overflows. See Protection Against SRL Overflow---srlprot attribute for a description of cases where the log overflows and what can be done to prevent it.

To change the state of an RLINK from STALE to ACTIVE, see Using the Automatic Synchronization Feature and Example---Synchronizing the Secondary Using Block-level Backup.

FAIL RLINK State

A Primary RLINK enters the FAIL state when the corresponding Secondary RLINK enters the FAIL state for any reason. This happens if there is an unrecoverable I/O error on one of the Secondary data volumes.

There are two ways for a Secondary RLINK to fail. One is if it encounters an I/O error that cannot be corrected. This is less likely to happen if the data volumes have been configured in a redundant fashion.

The second way for a Secondary RLINK to fail is if you enter the vxrlink -w pause command on the Secondary. This command must be used with great care because it enables data volumes on the Secondary to be written. The command must be used if a data volume must be restored from backup.

When the restore operation is complete, execute the following command:

This will return both the Primary and Secondary RLINKs to the ACTIVE state. 

Secondaries can also be restored from a Primary checkpoint if a Secondary checkpoint is not available, but the Primary checkpoint and corresponding backup are available.

If the Secondary RLINK cannot be restored, or if it is no longer needed, then
vxrlink det can be used on either the Primary or the Secondary to detach the Primary RLINK and make it STALE.

Inconsistent RLINKs

When an RLINK is inconsistent, the Secondary cannot be used for a failover because the data volumes do not reflect the data on the Primary node.

Note that inconsistent is not a state. Whether an RLINK is consistent, or not, is shown in the flags field of the RLINK.

To see whether the consistent or inconsistent flag is set, use the following command:

An RLINK that is inconsistent and in the FAIL state must be restored before it can be used again. It can be restored using a Primary or a Secondary checkpoint. An RLINK becomes inconsistent and gets in the FAIL state in situations such as:

• When you enter the vxrlink -w pause command

Used to put an RLINK in the fail state. Not normally used.

• If there is an unrecoverable I/O error on a data volume on the Secondary

If the data volume can be restored from backup, it is possible to recover. Loss of volumes due to I/O errors is usually preventable by mirroring.

If an RLINK is inconsistent, but not in the FAIL state, it could be a temporary situation and the inconsistent flag will clear when the operation completes. This happens in situations, such as:

• During atomic update

An atomic update operation would happen automatically, for example, to catch up after a network outage. If a machine crashed during such an update, the user would see the inconsistent flag set while not in the FAIL state. This is unlikely, however, and as long as the Primary node has not been lost, VVR will automatically make the RLINK consistent again once the Primary-Secondary network connection is reestablished.

• During DCM resynchronization

When you execute the vxrvg resync command after the SRL has overflowed, the RLINK becomes inconsistent during resynchronization until the DCM replay is complete.

When the inconsistent flag is set, a flag is displayed indicating whether the RLINK can be resynchronized. If the RLINK has the cant_sync flag set, it is inconsistent, and this Secondary needs to be resynchronized before it can take part in replication again. If the inconsistent and can_sync flags are set, there is enough information to make it consistent again. This will occur automatically.

Pausing, Resuming, and Restoring RLINK States

PAUSING, RESUMING, and RESTORING are temporary states through which the RLINK transitions when doing a Pause, Resume, or Restore, respectively. If these states persist, it means that the command failed halfway through the execution. Recovery from these states is simple.

If the state is PAUSING, it means that some error prevented the pause operation from completing. The error is displayed during execution of the vxrlink pause command. When the error is corrected, the next vxrlink pause command will succeed.

If the state is RESUMING, it means that some error prevented the resume operation from completing. The error is displayed during execution of the vxrlink resume command. When the error is corrected, the next vxrlink resume command will succeed.

If the state is RESTORING, a vxrlink restore command failed. You must execute either a vxrlink -w pause command to put the RLINK back into the FAIL state, or a vxrlink -c checkpoint restore command to put it into the ACTIVE state.

Two other Volume Replicator commands also use two-phase transactions. If these commands fail after executing partially, they can be safely repeated. The commands are:

• vxrlink recover
• vxrvg recover

If the vxrlink recover or vxrvg recover command fails, the state of the object will still be RECOVER. Volume Replicator commands that do two-phase transactions report an error message and have a nonzero exit code if they fail.