©2015 - 2022 Chad’s Technoworks. Disclaimer and Terms of Use

Chad’s TechnoWorks My Journal On Technology

Information Technology

Prev< 1 2 3 4 5

HOW TO INSTALL AND CONFIGURE COUCHBASE SERVER - page 5

BUILDING A SECOND CLUSTER FOR REPLICATION


What we have built so far is the DC1-Cluster-A Couchbase cluster.

We plan to create another cluster which we would make it our failover site using Couchbase Replication XDCR.


For this second cluster, we'll assign the nodes lxnode5, lxnode6, lxnode7 as the members.


To build,


1. Install the Couchbase binaries. Follow the same instructions as discussed in the section Multiple Instance Install (non-root).


2. Configure Couchbase for Multi-Instance.

   Assign the following instance name for each of the node you setup.

   cb4inst1_n1 is for lxnode5

   cb4inst1_n2 is for lxnode6

   cb4inst1_n3 is for lxnode7


   We will not be changing the ports but just the instance name.

   

3. Setup Firewall to open critical ports for Couchbase.

   

4. Setup Couchbase as new cluster.

   Follow the instructions as discussed in the section - Setup Couchbase Instance - but do not create any sample buckets. This cluster we're building will simply just be empty.

   Make sure that the VIP (lxnode?cb-vip) assigned to the node is configured and running. Run ifconfig -a to check.

   Name the cluster as DC2-Cluster-A.


5. Add nodes to the cluster.

   As for the remaining nodes - lxnode6, lxnode7 - proceed to install Couchbase and configure to join the cluster DC2-Cluster-A.



XDCR REPLICATION SETUP

For Cross Data Center Replication (XDCR) you need an existing cluster in your failover site.

If you haven't have a cluster for your replicated data, you need to read the details of building one as discussed in the section - Building A Second Cluster For Replication.


Once you got a working cluster in your failover site, proceed to next step on building buckets in your failover cluster.  

For the sake of this exercise, I had built a failover cluster called DC2-Cluster-A which has nothing but just a default bucket.


CREATE A BUCKET AS A RECIPIENT OF REPLICATED DATA


At the failover cluster DC2-Cluster-A, create a bucket that matches the properties of the source bucket that need to be replicated.

Although we could name the new bucket the same as the source, for distinction purposes, I would name it slightly different enough to distinguish a failover bucket.

Since during the install we had pre-loaded sample buckets in our source cluster DC1-Cluster-A, we'll use the travel-sample our source of replication.



1. Access the Web Console of the primary site DC1-Cluster-A: http://lxnode1:8091


2. Select Data Buckets tab and click the triangle to expand the travel-sample bucket.


3. Click Edit button to view the details and take note of its properties as we will use this to create a new bucket in the failover site cluster DC2-Cluster-A.

   The basic information you would need at this point is - Bucket Type, memory Size, Access Control.

4. Access the Web Console of DC2-Cluster-A: http://lxnode5:8091


5. Select Data Buckets tab and click the Create New Data Bucket button.

6. Provide the bucket info and save.

     Bucket Settings,

       Bucket Name: travel-sample-2

       Bucket Type: Couchbase

     Memory Size,

       RAM Quota: 100 MB

       Cache Metadata: Value Ejection

     Access Control,

       Standard Port 11211

     Replicas,

       Enable, 1 replica

     Disk I/O Optimization, low (default)

SETUP REPLICATION


1. At the source cluster DC1-cluster-A, go to the XCDR tab.

2. Click Create Cluster Reference.


Cluster Name: DC2-Cluster-A

IP/hostname: 172.16.33.88 (lxnode5cb-vip.vlabs.net)

Admin Username: Administrator

Password:

3. Click Create Replication


Replicate Changes from:

  Cluster: this cluster

  Bucket: travel-sample

  

To:

  Cluster: DC2-Cluster-A

  Bucket: travel-sample-2  


Advance Settings (Optional)

Parameters and their default values.

XDCR Protocol  = Version 2 , Use Version 2 (XMEM) for all implementation except Elasticsearch integration.

XDCR Source Nozzles per node = 2 , value 1 to 100; Must be less than or equal to the number of XDCR Target Nozzles per Node.

XDCR Target Nozzles per node = 2 , value 1 to 100; This can be set higher if the target nodes have high processing power.

      Number of concurrent workers writing to the target cluster  = XDCR Target Nozzles per Node * <Number of Nodes in Target Cluster>

XDCR Checkpoint Interval = 1800 , value 60 to 14,400 seconds; Interval between checkpoints

XDCR Batch Count = 500 , value 500 to 1,000 doc batching count; increase 2-3x for uni-directional

XDCR Batch Size (kb) = 2048 , value 10 to 100,000 kb doc batching size; increase 2-3x for unidirectional

XDCR Failure Retry Interval = 10 , value 1 to 300 seconds; Lower when expecting network failures

XDCR Optimistic Replication Threshold = 256 , value 0 to 2,097,152 bytes (20mb) compressed; Optimistic lower the size

That's it, the bucket travel-sample is now being replicated to another cluster in bucket travel-sample-2.

You may further look at the replication stats when you click on the travel-sample link in the Data Buckets page and expand Outbound XDCR Operations.

And similarly, you may check the Inbound XDCR Operations at the failover cluster DC2-Cluster-A. But as of the moment, there's not much activity to show since the replication may have already completed.

To verify that the data went into our empty travel-sample-2 bucket, go to the Data Buckets tab and click the Documents button to view if there are contents.