Planning for Disaster Recovery (DR) and Business Continuity (BC) is vital for any modern application, and that applies equally to any application with a mobile or edge computing component.
Service outages or downtime can cause serious impacts to a business and without the correct strategies in place, such an event can be challenging to recover from.
This post will look at one of the ways you can plan for BC and DR for your mobile application in Couchbase using Cross Data Center Replication (XDCR).
Couchbase Mobile Stack
Couchbase Mobile is a cloud-to-edge platform that enables you to deploy offline first mobile and embedded applications, providing fast and efficient synchronization of data.
It is comprised of 3 key components:
-
- Couchbase Server – the highly scalable, highly available, highly performant NoSQL database. This is available as a fully managed and hosted Database-as-a-Service with Couchbase Capella, or can be deployed and hosted on your own as Couchbase Server.
- Sync Gateway – an internet-facing, secure synchronization mechanism designed to provide data synchronization for large-scale interactive web, mobile, and IoT applications. Available fully hosted and managed with Capella App Services, or can be installed and managed yourself with Couchbase Sync Gateway.
- Couchbase Lite – a full-featured, embedded database for your mobile, desktop and IoT apps. It provides CRUD, full-text search, query, and vector search capabilities that run locally on the device.
What is XDCR?
XDCR is a highly performant replication technology that allows for replication of data between two or more Couchbase clusters. It serves a very important role in supporting DR strategies and data migration, including for mobile applications.
XDCR can be established unidirectionally (meaning data flows only from source cluster A to target cluster B) or bidirectionally (meaning data flows from source cluster A to target cluster B, and source cluster B to target cluster A), allowing for a range of different topologies to support different use cases.
Some common use cases for XDCR include hot standby for DR, geolocation of data centers for applications used globally, migration, and more.
How can we use XDCR to ensure BC/DR for a mobile deployment?
It is very important to consider the best approach to the DR strategy for a mobile application. There are multiple ways this can be achieved, namely Inter-Sync Gateway Replication (ISGR) and XDCR. ISGR allows for replication between multiple Sync Gateway or Capella App Services instances; you can learn more about it in another blog post. We will now look at how you can use XDCR as part of a DR strategy for a mobile application with Couchbase.
In this example, we have two Couchbase clusters, both with an associated Sync Gateway cluster. One of these clusters is the primary for a production application, the other is the DR cluster, which is kept in sync with the primary cluster through the use of XDCR.
It is best practice that unidirectional XDCR is used (rather than bidirectional) as this ensures that changes flow from the source to the target and that the target site does not send write-operation updates back to the source. Additionally, Sync Gateway must be on standby (meaning it is not actively receiving data) when it is the target of XDCR replication.
In a usual scenario, this is what that configuration would look like:
In a DR scenario, some steps must be taken to ensure that you can switch over to the secondary cluster:
-
- Remove the unidirectional XDCR replication from the old primary to new primary cluster (previously the DR cluster)
- Set Sync Gateway to standby on the old primary Couchbase cluster
- Turn on replication between the new primary Couchbase cluster and Sync Gateway cluster (previously the DR cluster)
- Set up unidirectional XDCR replication between the new primary cluster and the new DR cluster
- Connect the application to the new primary cluster instead of the old primary cluster
The new configuration would look like this:
It’s crucial to maintain the conditions of having Sync Gateway on standby and unidirectional XDCR, especially when flipping the cluster. If not, you could end up with both Sync Gateway and XDCR targeting the same bucket in write mode, leading to sync issues.
Through this approach, you can ensure that your mobile application is robust and prepared for a DR scenario.
References