Setting up Disaster Recovery
How to set up a Sync Gateway mobile cluster for Disaster Recovery (DR) using Couchbase Server’s Cross Data Center Replication (XDCR)
Introduction
Couchbase Server Cross Data Center Replication (XDCR) replicates data between two or more autonomous Couchbase Server clusters. It serves an important role in supporting Disaster Recovery (DR) and Data Migration, even where Sync Gateway is the normal replicator of choice for mobile data.
Recommended Deployment Models
Clusters in Same Region
This model caters for situations where the Active and Disaster Recovery clusters are in the same region or data center — see: Figure 1. It includes an optional optimization step, which will ensure that there is no downtime during the activation stage.
To set up and maintain a disaster recovery cluster:
-
[Optional step — for optimization] Connect Sync Gateway to the Disaster Recovery cluster just long enough to create indexes. Having everything reindexed lowers switching costs.
If you skip this test, you will incur latency when Sync Gateway is switched to the Disaster Recovery cluster and Sync Gateway rebuilds its indexes. -
Connect Sync Gateway to your Primary cluster.
-
Initiate the unidirectional XDCR from the Primary cluster to the Disaster Recovery cluster.
When you are ready to switch to Disaster Recovery operations:
-
Stop the replication (XDCR) from the Primary cluster to Disaster Recovery cluster.
-
When XDCR is stopped: Switch the Load Balancer to point to the Sync Gateway on the Disaster Recovery cluster. This maintains the deployment of Sync Gateway at only one end of the XDCR replication.
-
Promote the Disaster Recovery cluster to Primary and the old Primary to Disaster Recovery.
-
Flush all replicated buckets in the Primary cluster; as a precaution against any spurious writes coming into the Primary cluster that had not been replicated when XDCR was stopped.
-
Reverse the XDCR to replicate from the newly promoted Primary to the old Primary to set up a new Backup.
Clusters in Different Regions or Data Centers
This model caters for situations where the Active and Disaster Recovery clusters are in different regions or data centers. Although the model has a separate Sync Gateway cluster attached to the Disaster Recovery cluster, it maintains the deployment of Sync Gateway at only one end of the XDCR replication. The optional optimization step will ensure that there is no downtime during the activation stage.
To set up and maintain a disaster recovery cluster - see: Figure 3:
-
[Optional step — for optimization] Turn on Sync Gateway in the Disaster Recovery cluster just long enough to create indexes. Having everything re-indexed lowers switching costs.
If you skip this test, you will incur latency when Sync Gateway is switched to the Disaster Recovery cluster and Sync Gateway rebuilds its indexes. -
[Critical step] Turn off all the Sync Gateways in the Disaster Recovery cluster.
-
Initiate the unidirectional XDCR from the Primary cluster to the Disaster Recovery cluster.
When you are ready to switch to Disaster Recovery operations — see: Figure 4:
-
Stop Sync Gateway on the Primary cluster
-
Stop the replication (XDCR) from the Primary cluster to the Disaster Recovery cluster.
-
Ensure that any and all Load Balancer(s) are updated to direct all traffic to the new Sync Gateway cluster(s).
-
Turn on the Sync Gateway cluster(s) in the Disaster Recovery cluster.
-
Promote the Disaster Recovery cluster to be the new Primary cluster, and make the old Primary cluster the new Disaster Recovery cluster
-
Flush all replicated buckets in the Primary cluster; as a precaution against any spurious writes coming into the Primary cluster that had not been replicated when XDCR was stopped.
-
Reverse the original XDCR to replicate from the newly promoted Primary to the old Primary, to set up a new Backup.