Couchbase Cluster Operations and Administration
The Cluster Operations and Administration domain tests how Couchbase Server is structured and operated: services, vBuckets, replication, rebalance, failover, backup, security, and monitoring. Questions often ask what happens during a topology change or which administrative control prevents a specific failure mode.
Architecture and vBuckets
Every bucket is divided into 1024 vBuckets. Each vBucket has one active copy and zero or more replica copies; replica count is a bucket setting, commonly 1 to 3. The data, index, query, search, analytics, and eventing services can run on separate nodes. Rebalance redistributes vBuckets and rebuilds replicas after nodes are added or removed.
Failover and rebalance
Graceful failover lets a node hand off its work; hard failover does not. After failover, replicas for the failed node's vBuckets are promoted to active, but the cluster is under-replicated until a rebalance restores replica count. Auto-failover triggers after a configured timeout and must be sized so transient network blips do not remove healthy nodes. Always rebalance after failover to restore redundancy.
Memory, storage, and backup
Bucket memory quotas and cluster watermarks control eviction. The high watermark triggers eviction; the low watermark stops it. Eviction policies include value-only, full, and no-eviction. Disk queues absorb write bursts, and compaction reclaims disk space. cbbackupmgr provides backup and restore; XDCR replicates to another cluster for disaster recovery, not as a substitute for backup.
Security and monitoring
Role-based access control grants roles at cluster, bucket, scope, or collection level. Use TLS for client and inter-node traffic, and x.509 certificates for strong authentication. Monitor latency, ops/sec, RAM usage, disk write queues, vBucket states, and rebalance progress. Audit logs capture administrative and data access events.
Worked example
A three-node cluster has one replica per bucket. One data node fails and auto-failover promotes its replica vBuckets on the surviving nodes. The bucket now has active copies everywhere but missing replicas. The administrator adds a replacement node and runs rebalance; vBuckets move onto the new node and replica copies are rebuilt. Skipping the rebalance leaves the cluster unable to survive another node loss.
Traps
Failing over without rebalancing leaves under-replicated vBuckets. Setting auto-failover too aggressively causes unnecessary failovers. Assuming index replicas exist when they were never configured leads to query outages. Treating XDCR as backup does not protect against accidental deletes that replicate. Deleting a bucket destroys its data and cannot be undone by rebalance.