{"id":12699,"date":"2022-01-24T09:25:41","date_gmt":"2022-01-24T17:25:41","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=12699"},"modified":"2025-06-13T20:45:52","modified_gmt":"2025-06-14T03:45:52","slug":"deploying-couchbase-for-high-availability-in-google-cloud-platform-part-2-xdcr","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/deploying-couchbase-for-high-availability-in-google-cloud-platform-part-2-xdcr\/","title":{"rendered":"Deploying Couchbase for High-Availability in Google Cloud Platform – Part 2 – XDCR"},"content":{"rendered":"

This is Part 2 in a series focused on leveraging the high-availability architectural capabilities and features of Couchbase Server on the Google Cloud Platform (GCP). The Couchbase concepts discussed here can be universally applied to any cloud environment where you deploy your cluster but the steps and commands are specific to GCP.<\/span><\/p>\n

Part 1<\/a> covered how to achieve Couchbase node and service (Query, Index, Data, Search, Eventing, Analytics, Backup) resiliency. We showed how to do this by allocating services to specific nodes spread across specific GCP availability zones within a Region.<\/span> You can read that blog <\/span>here<\/span><\/a>.<\/span><\/p>\n

In this blog post, we enable <\/span>Cross Data Center Replication <\/a><\/b>(XDCR) between two Couchbase clusters running in GCP across two different regions. This implements database High Availability (HA)<\/a>, disaster recovery or geo-locality data enforcement. XDCR is not new to Couchbase and is available out of the box with every installed Couchbase cluster. XDCR can be used between any two versions of Couchbase Server (since version 2.5).<\/span><\/p>\n

The five scenarios of data loss prevention<\/span><\/h4>\n

Couchbase Server architecture provides data resiliency (e.g., data loss prevention) on several different levels \u2013 from the single data mutation level all the way up to the cluster level. These are five of those levels in more detail:<\/span><\/p>\n

Write Failure & Durability Levels<\/b><\/p>\n

Data <\/span>Write <\/span><\/i>operations to Couchbase buckets can be assigned durability requirements. For example, Couchbase can be instructed to update the specified document on multiple nodes (in memory and\/or disk locations across the cluster) before considering the write to be committed. The greater the number of memory\/disk locations specified in the requirements, the greater the level of durability achieved. You can read more about setting these different levels in <\/span>this product documentation page<\/span><\/a>.<\/span><\/p>\n

Node Failure & Failover<\/b><\/p>\n

The Couchbase <\/span>Data<\/span><\/i>, <\/span>Index <\/span><\/i>and <\/span>Full Text Search<\/span><\/i> services allow replicas to be created at the document and index levels so that when a node running one of these services fails another replicate can be used. For example, the existing replicas that live on the still running nodes for those services become available so that your applications can still fully function. You can read in detail on how Couchbase’s underlying architecture supports this ability in this blog, <\/span>Distributed Databases: An Overview<\/span><\/a>.<\/span><\/p>\n

Cloud Availability & Rack Zone Failures<\/b><\/p>\n

Leveraging <\/span>Multi-Dimensional Scaling <\/span><\/i>(MDS) and <\/span>Server Group Awareness <\/span><\/i>protects your applications from losing data access due to a physical <\/span>rack <\/span><\/i>or cloud <\/span>availability zone <\/span><\/i>failure. Part 1 of this blog series covered how to separate Couchbase services across independent nodes within a cluster that is running across different physical racks in a datacenter or across cloud provider availability zones.<\/span><\/p>\n

Cloud Region & Datacenter Failures<\/b><\/p>\n

Replication is the key to providing high availability and fault tolerance at the cluster level. XDCR is a highly performant, memory-to-memory, replication technology used to replicate data between two Couchbase clusters. This is complementary to the intra-cluster replication behind our data auto sharding that is built into Couchbase’s architecture. XDCR provides asynchronous replication and maintains data consistency across sites via eventual consistency. We will walk through how to implement this capability between two separate Couchbase clusters in different GCP regions in this blog.<\/span><\/p>\n

\u201cYour World\u201d Failure<\/b><\/p>\n

Cluster Backups! Customers sometimes ask, \u201cWhy do I need to backup if I already have 100% availability?\u201d The best answer to this question is another question, \u201cWhat would you do if corrupt data is introduced into your cluster from an upstream system or application?\u201d This is one of the few downsides of memory-to-memory replication: corrupt data will likely infest other clusters quickly, so you will need to restore an uncorrupted point-in-time backup. This scenario is very rare and we hope it is never encountered by our customers, but you should evaluate your current Couchbase backup practices and schedules just in case. In Couchbase 7 we introduced the <\/span>Backup Service <\/span><\/i>to further facilitate the automation of your backup and restore strategy. You can read about that <\/span>here<\/span><\/a>.<\/span><\/p>\n

Five steps to implement cross datacenter replication (XDCR) with Couchbase on GCP<\/span><\/h4>\n

These are the high-level steps covered in this blog to implement XDCR between Regional GCP Couchbase clusters:<\/span><\/p>\n

    \n
  1. Setup 2 separate Couchbase clusters in different regions of GCE<\/span><\/li>\n
  2. Enable the <\/span>travel-sample <\/span><\/i>dataset on Cluster 1 that will be the source data for a unidirectional replication<\/span><\/li>\n
  3. Create an empty bucket on Cluster 2\u00a0<\/span><\/li>\n
  4. Create an XDCR stream from Cluster 1 to Cluster 2 for an active\/passive HA scenario<\/span><\/li>\n
  5. Create an XDCR stream from Cluster 2 to Cluster 1 for an active\/active HA scenario or to enforce geo-locality of data<\/span><\/li>\n<\/ol>\n

    Step 1<\/b><\/p>\n

    Follow the instructions in<\/span> Part 1<\/span><\/a> to spin up two separate Couchbase clusters in different GCP Regions, such as <\/span>us-east1 <\/span><\/i>and <\/span>us-central1<\/span><\/i>. This is similar to deploying Couchbase in two different data centers in different geographic locations to protect your environments from geographical network infrastructure failure.<\/span><\/p>\n

    Step 2<\/b><\/p>\n

    In the Couchbase UI for the <\/span>GCP-WEST <\/span><\/i>cluster, go to the <\/span>Settings <\/span><\/i>section and click on the <\/span>Sample Buckets<\/span><\/i> link in the top right corner of the screen:<\/span><\/p>\n

    \"\"<\/p>\n

    Then check the box next to <\/span>travel-sample<\/span><\/i> and click on <\/span>Load Sample Data:<\/span><\/i><\/p>\n

    \"\"<\/p>\n

    Give this a couple of minutes to load the dataset, then click over to the <\/span>Buckets <\/span><\/i>area in the UI to see the new bucket called <\/span>travel-sample<\/span><\/i>. All of the data is loaded once you see the item count shown below (version 7.x):<\/span><\/p>\n

    \"\"<\/p>\n

    This will be the <\/span>source <\/span><\/i>bucket for our XDCR stream between the <\/span>GCP East<\/span><\/i> and <\/span>West <\/span><\/i>regional clusters. Before we can define and enable a stream to replicate this data we need to create a target empty bucket on the destination cluster to receive the data.<\/span><\/p>\n

    Step 3<\/b><\/p>\n

    On the second cluster, <\/span>GCP-EAST,<\/span><\/i> in the Admin UI, go to the <\/span>Buckets<\/span><\/i> area and click on <\/span>ADD BUCKET<\/span><\/i> in the upper right hand corner:<\/span><\/p>\n

    \"\"<\/p>\n

    You will then see this window and can fill in the required values to create an empty target bucket.<\/span><\/p>\n

    \"\"<\/p>\n

    Once you click <\/span>Add Bucket<\/span><\/i> you should see it listed immediately. I have named the bucket differently from the source bucket to assist in knowing which cluster the screenshots are from. In real life, you would likely want to name them the same so that your application’s string values will not have to change in the event that you are switching from one cluster to the other.<\/span><\/p>\n

    \"\"<\/p>\n

    Step 4<\/b><\/p>\n

    To implement an active\/passive cluster strategy we set up a unidirectional XDCR stream from our <\/span>GCP-WEST<\/span><\/i> cluster <\/span>travel-sample <\/span><\/i>bucket to our <\/span>GCP-EAST<\/span><\/i> cluster <\/span>east-travel-sample<\/span><\/i> bucket. In the Admin UI for the <\/span>GCP-WEST <\/span><\/i>cluster in the <\/span>XDCR <\/span><\/i>section, click on <\/span>ADD REMOTE<\/span><\/i> in the upper right corner. This will open another pop-up window.<\/span><\/p>\n

    \"\" \"\"<\/p>\n

    Click <\/span>Save<\/span><\/i>.<\/span><\/p>\n

    \"\"<\/p>\n

    Now click on <\/span>ADD REPLICATION<\/span><\/i> to get to the screen where we can create a unidirectional stream from <\/span>GCP-WEST<\/span><\/i> to <\/span>GCP-EAST<\/span><\/i>.\u00a0\u00a0<\/span><\/p>\n

    \"\"<\/p>\n

    Once you enter in all of your stream customizations, click <\/span>Save Replication<\/span><\/i> and the stream will start immediately moving data to the <\/span>GCP-EAST <\/span><\/i>cluster and will continue as mutations occur in the <\/span>travel-sample <\/span><\/i>bucket.<\/span><\/p>\n

    \"\"<\/p>\n

    I chose to only replicate the <\/span>default <\/span><\/i>scope in this stream so that you can see the different options now available in version 7 to split or combine scopes and collections as part of a replication stream. You can read in more detail about these options in this post: <\/span>Introducing XDCR Support for Scopes and Collections in Couchbase 7.0<\/span><\/a>.<\/span><\/p>\n

    \"\"<\/p>\n

    Step 5<\/b><\/p>\n

    If you want to setup an active-active HA strategy for two or more Couchbase clusters you will need to create one unilateral XDCR stream going from Cluster 1 to Cluster 2 and then a parallel reverse stream from Cluster 2 to Cluster 1 for the same data set. For example as shown below, we have set up a unilateral stream on each cluster so that any mutations that hit one cluster are replicated to the other.\u00a0<\/span><\/p>\n

    \"\"<\/p>\n

    \"\"<\/p>\n

    If you want to apply filtering rules to support data locality policies you can read about how to implement these capabilities <\/span>here<\/span><\/a> in this documentation page.\u00a0<\/span><\/p>\n

    Conclusion<\/b><\/p>\n

    You\u2019ve just seen how you can use XDCR to implement a key piece of your Couchbase Cluster HA strategy by protecting the applications using Couchbase from a Data Center or cloud network regional failure.<\/span><\/p>\n

    You can learn more about XDCR from these sources:<\/span><\/p>\n