Couchbase Cluster Hibernation
The Operator allows a Couchbase cluster to be hibernated. This documents what hibernation means and the hibernation life-cycle.
Hibernation is the process of deactivating a Couchbase cluster.
By hibernating a Couchbase cluster:
Compute resources required by the cluster are released
This leads to cost savings when the cluster is not being used.
This leads to Kubernetes resources becoming available to be reused by other workloads.
When a cluster is hibernated, any persistent volumes associated with the cluster are retained. This allows the cluster to be recovered at the point of hibernation with existing data still intact.
At present there is only one hibernation strategy:
- Immediate hibernation
This immediately terminates any pods associated with the cluster. Any writes to the database that reside in a store queue, but not persisted to disk, will be lost. Any writes that must be persisted to disk should use durable writes that guarantee to the client the data has been persisted and potentially replicated.
A cluster that is hibernating can be awoken. The cluster will be recovered in exactly the same way as it would from a total loss of all pods.
Ephemeral clusters—with no persistent volumes—will be recreated. Be aware that for ephemeral clusters, the cluster UUID will change, and will require XDCR clients to be reconfigured.
Persistent volume backed clusters will be recovered. The persistent metadata on the volumes will ensure the cluster is restored exactly as it was before hibernation.
Supportable clusters, with both volume backed and ephemeral server classes, will be first recovered from persistent volumes, then the ephemeral pods will be failed over and reprovisioned.
When using this cluster topology, it is possible that Couchbase server will refuse to fail over ephemeral nodes.
Automatic recovery can be enabled, in this situation, by setting the
spec.recoveryPolicy attribute to
This will allow the Operator to force failover of the affected pods, and then recover.
The Operator updates the cluster conditions during the life cycle of a hibernation. This allows 3rd party observers to know when a cluster has hibernated fully. When completely hibernated all I/O to persistent volumes will have terminated and be in a stable state.