Deployment Considerations for Less Than 3 Nodes
When setting up a Couchbase Server deployment, the number of nodes in that deployment impact the features that are available. The number of nodes also heavily impact how the deployment is maintained in production. For these reasons, we do not recommend running a Couchbase Server deployment of less than three nodes in production. Support for specific use cases that require a one-node or two-node clusters may be granted by Couchbase after an evaluation of the use case. This section highlights some of the feature differences and considerations that need to be taken into account when setting up and running a small deployment.
The following limitations apply to deployments with two nodes:
No auto-failover functionality
When a deployment of Couchbase Server has less than 2 nodes, auto-failover is disabled. This is because with less than 3 nodes in the deployment it is not easy to determine which node is having an issue and thus avoid a split-brain configuration.
Maximum number of replicas is 1
A Couchbase Server deployment can have multiple replicas. However, when a deployment has only two nodes, you can have a maximum of one replica as the Active and Replica of a vBucket cannot exist on the same server.
Run the cluster at < 50% load capacity
When running a Couchbase deployment with two nodes, we recommend running the cluster at 50% capacity. In the event of a failure, running the cluster at this level ensures that the remaining node is not overloaded.
Many features of Couchbase Server do not work in a single node deployment. All the limitations that apply to deployments with two nodes also hold true for single node deployments, including no auto-failover functionality.
Node failure means recreating the cluster and restoring data
In a single node deployment, any failure of the node implies down time and possible recovery from a backup.
Failure creates a high likelihood of irrecoverable data loss (no in-memory replicas)
When a node fails or restarts, there is 100% downtime until it is recovered. In a single node cluster, there is no replica that can take over the traffic when the node is not responding.
Constant warning in the UI reminding that you have no replicas
The user interface will tell you that your data is not replicated and that you are running in an unsafe configuration. This is how the cluster manager alerts the administrator if there are not enough replicas to protect your data.
No failover (in addition to no auto-failover)
When running a single node cluster, a node cannot failover if there are issues.
No ability to add services dynamically
In 4.x with multidimensional scaling, each node in a deployment can have multiple roles. However, to be able to change these roles, the node must be removed from the deployment first. With a single node deployment, the only option is to take the deployment offline, add the service, and restore the deployment.
No rolling upgrade; only offline
To upgrade a single node deployment, the node must be offline as an upgrade using a rebalance is not an option with a single server.
No rolling restart; only offline
Any restart of the single node for maintenance reasons would result in 100% downtime as there are no other nodes to take over this work.
Host name or IP address must be set explicitly
When creating a single node deployment, set the host name and IP address at the time of creation.