Follow

Miscellaneous Replication Questions

Subject:

Detailed information on several replication related questions.

 

Replication questions:


> Q: When deciding to failover to the replica, one has to temporarily suspend the replication schedule and then clear the active checkpoint flag on the replica. 


Via the CLI, one can first perform a "qs replication-schedule-disable" operation for the first step. It is possible to carry out the second step via the GUI but can it be done using the CLI.

Conversely is it possible set the active checkpoint flag?


> A: The 'Active Checkpoint flag' is used to indicate to the replication schedule that a `_chkpnt` is in use by a host and that the `_chkpnt` should NOT be overwritten by the schedule while it is in active use by a client.

When you assign host access to the `_chkpnt `volume and the client connects to the lun, it will automatically enable the active checkpoint flag.

If the Active checkpoint flag is enabled on a `_chkpnt` and replication has been occurring, then the `_chkpnt` DOES NOT have the most recent GMT snapshot applied to it.

If you are not actively using a `_chkpnt` for host access, then you should remove the "active checkpoint flag" from that `_chkpnt` to allow it to correctly be overwritten or managed by the replication schedule.


However, to clear the flag requires user intervention as it is only the user who is sure that the access to the LUN should no longer be blocked and or the changes on the `_chkpnt` should be retained or discarded..


To disable the Active Checkpoint flag via the CLI, you can do so with the `qs volume-modive --volume {VOLUME} --is-active-checkpoint false` command.Please note that if there is active host access this will cause the replication schedule to overwrite volume


> Q: I can see the "qs replica-assoc-delete" operation however this physically deletes the replication link which then prevents one from performing a rollback at a later stage. 
We'd like to to be able to perform a rollback.


> A: You do not want to remove the replica association unless you are permanently switching to the DR site with no intention of reverting to the Primary site.


With DR, After you have restored access to your Primary site and you are ready to restore service at the Primary site, you can stop access to the `_chkpnt` and reverse the replication to copy the current state of the replica `_chkpnt` using the 'Rollback from Replica' WebUI option or the 'replica-assoc-rollback --replica-assoc {REPLICA ASSOCIATION}' command:


>>>
replica-assoc-rollback --replica-assoc {REPLICA ASSOCIATION} --force

replica-assoc-rollback [rep-assoc-rollback]
:: Reverses the replication to send the changes on the target back to the source volume/share.
Requires the --force flag.
<--replica-assoc> :: Name or ID of a replica association between a source/target volume or share
>>>

 

> Q: I have noticed that a number of replicas do not have their active checkpoint flag switch on despite the fact that there are active replication schedules against them - is that valid?


> A: Yes, because there are no hosts assigned and no hosts connected, the active checkpoint flag will correctly be set to false (because it is not an active checkpoint).


If you have active checkpoint flags enabled on replica `_chkpnt(s)` that you are NOT actively using, you should remove host assignment and any active sessions and set the active checkpoint flag to false so that the replication link can correctly overwrite the `_chkpnt` with the most recently transferred GMT snapshot data and/or manage the retention of snapshots.

 

Additional detail can be found at this link:

QuantaStor_Administrators_Guide#Volume_Share_Remote-Replication_Disaster_Recovery_DR_Setup

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk