![]() |
![]() |
![]() |
![]() |
![]() |
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:
#
vxprint -g
diskgroup
-l
rlink_name
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:
vxrlink
-w pause
command
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:
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.
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.