Failback returns the replication relationship between the source and target pod to the original direction (production to disaster recovery). Before failing back, ensure that the MongoDB instances on hosts connected to the disaster recovery site are quiesced and demote the disaster recovery site pod (original target pod) with --quiesce option to ensure that all data is replicated to the original production site before the pod is marked demoted -- making the volumes within the pod read-only. Once the demote process is complete and the pod on the disaster recovery site shows a ‘demoted’ status, the pod on the original source site (production site) can be promoted.
To failback after failover:
-
Production site (original): Restore FlashArray
-
Disaster recovery site (currently running disaster recovery applications: quiesce disaster recovery applications (stop MongoDB), umount target (disaster recovery) pod volumes
-
Disaster recovery site (was running disaster recovery applications): demote the pod using --quiesce option
From the command line:
purepod demote --quiesce <pod_name>
From FlashArray GU (see Figure 8):
Storage ➤ Pods ➤ <pod> ➤ '⋮' (vertical ellipsis) ➤ Demote ➤ Quiesce ➤ Demote
Figure 8.
4. Disaster recovery site (had been running disaster recovery applications): Monitor replica-link status; replica-link quiesced state indicates all data writes from disaster recovery site have been completed to the original production site. To determine the replica-link from the command line execute:
purepod replica-link list
From FlashArray GUI select Protection ➤ ActiveDR (see Figure 9)
Figure 9.
5. Original Production Site (Desired Replication Source Site): Promote the original source pod (see Figure 3)
6. Connect hosts (if not already connected) and mount volumes
7. Start production MongoDB instances and applications