Make Secondary fails after taking over from an original Primary without fast failback synchronization
Article ID: 100009840
Updated On:
Description
Error Message
Error received while attempting to "make secondary" on the original primary:
...V-106-58644-363 Cannot perform the operation. RLINK is not up to date.
....state : state=STALE
....flags : write detached consistent disconnected
Cause
There are two factors to be considered:
(1) The RLINK on the new primary where the take over without fast-failback synchronization was initiated will be marked "STALE" and will be detached. This is by design, and it has the purpose of forcing a full sync with the original primary when / if the host is recovered.
(2) When the original primary comes online, it is still a primary with read and write access to the volume, therefore an application or the OS could place I/O on it, thus explaining the RLINK not up to date message, even if this was up to date before the host went down.
Resolution
On the original primary, after it comes online:
(1) Detach the RLINK using the following command line syntax:
vxrlink [-g ] [-r ] det
Note: Dissociating the Replicator Log (SRL) will have the same result, as it will detach the rlink.
The SRL would have to be Re-associated after the make secondary step.
(2) Make secondary, via the VEA GUI or by command line:
vxrvg [-g ] makesecondary
(3) Start the replication with the "Synchronize Automatically" option.
To avoid the above described behavior and manual steps needed for re-establishing replication, it is highly recommended to use the "fast fail-back" sychronization method when initiating a take over on the secondary VVR host.
Issue/Introduction
After a take over without fast fail-back synchronization was initiated on the original secondary VVR host, the subsequent "Make Secondary" on the original primary VVR host may fail with: V-106-58644-363 Cannot perform the operation. RLINK is not up to date.
Additional Information
UMI: V-106-58644-363
