{"id":13422,"date":"2022-06-22T13:32:18","date_gmt":"2022-06-22T20:32:18","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=13422"},"modified":"2025-06-13T18:21:55","modified_gmt":"2025-06-14T01:21:55","slug":"couchbase-analytics-high-availability-replicas","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/couchbase-analytics-high-availability-replicas\/","title":{"rendered":"Always-Available Real-Time Data With High Availability In Couchbase Analytics"},"content":{"rendered":"

As part of the Couchbase Server 7.1 release, <\/span>Couchbase Analytics Service<\/span><\/a> is very excited to announce the support of High Availability<\/a> capability availability to ensure users can access data within Analytics Service collections\/datasets when one or more Analytics nodes is not available.\u00a0<\/span><\/p>\n

Customer pain point<\/span><\/h2>\n

The primary challenge that users would encounter when one or more Analytics would be failed over or down for scheduled maintenance, security patches, and\/or node upgrades, the data residing in Analytics Service nodes would not be fully available for querying or reporting which lead to business users unable to meet service level agreements (SLA\u2019s). Additionally, when the failed node got back online, it would have to rebuild the collections\/datasets again from underlying Data Services including indexes. This would result in operational inefficiencies and impact the time to insights.<\/span><\/p>\n

How does the High Availability work?<\/span><\/h2>\n

Each node running the Analytics Service has one or more data partitions. Data ingested by the Analytics Service is hash-partitioned across all data partitions. When data is ingested in each partition, it is initially stored in an in-memory b-tree. Once a certain memory threshold is reached, the b-tree is persisted to disk and is scheduled to be asynchronously replicated to one or more Analytics nodes (based on the number of replicas configured). When a node running the Analytics Service is failed over, one of its replicas is promoted to serve the partitions that were served by the failed over node. This will allow the Analytics service to continue to work after the failover. The portion of data that will have to be re-ingested from the Data Service will be determined by the state of the replica at the promotion time as follows:<\/span><\/p>\n\n\n\n\n\n\n
Replica State<\/b><\/td>\nData to re-ingest<\/b><\/td>\n<\/tr>\n
All LSM components replicated and the failed over node had no in-memory data.<\/span><\/td>\nNone<\/span><\/td>\n<\/tr>\n
All LSM components replicated and the failed over node had in-memory data.<\/span><\/td>\nOnly the in-memory data (similar to a node restart)<\/span><\/td>\n<\/tr>\n
Some LSM components were not replicated<\/span><\/td>\nStart from last replicated LSM component\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The Analytics service will continue to work in an unbalanced state until one of the following is performed:<\/span><\/p>\n

    \n
  1. \n
      \n
    1. Node Recovery: The failed over node will be resynced from the promoted replica then it will be the master for its storage partitions again.<\/span><\/li>\n
    2. Node Removal: If the failed over node is removed, Analytics will redistribute the data among the remaining nodes in the cluster.<\/span><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

      For HA to work, enter at least 1 or more replicas to be created.\u00a0<\/span><\/p>\n

      This can be configured in the server workbench under Settings (see snap image below). This configuration can also be achieved by calling <\/span>this API<\/span><\/a>. A Rebalance is required to be run for the change to take effect. See this new feature in action in the following video<\/a>:<\/span><\/p>\n