Persistent Volumes

      Persistent volumes are essential to running the Couchbase Cloud-Native Database, as they allow for the persistence of database data and logs (or in the case of ephemeral clusters, simply logs).


      Persistent storage is a fundamental part of cloud-native deployments since most applications require some form of persistent data. Even stateless microservices have some dependency on persistent data stores where the data persists beyond the container, pod, or host.

      Kubernetes provides a convenient persistent storage mechanism called persistent volumes. Kubernetes allows you to mount a persistent volume, such as a file system folder or a cloud storage bucket, to one or more Kubernetes nodes, and also use it to share data between the nodes. Due to the ephemeral nature of Kubernetes, persistent storage is critical to avoid data-loss, and ensure application continuity in case of a pod failure.

      At the very basic level, persistent volumes allow for the collection of logs in the case of node or cluster failures. Without persistent volumes, these logs would be gone forever in the event of a pod terminally crashing. For this reason alone, it is highly recommended that all production deployments be run with persistent volumes.

      pv Basic
      Figure 1. A basic storage topology showing the couchbaseclusters.spec.servers.volumeMounts.default volume mount. The volume has two sub volumes, one for configuration data that must be retained for Couchbase recovery, and one for data and logs.

      Using persistent storage also allows the Couchbase cluster to be tailored to the workload. For example, flash storage can be explicitly selected for high performance.

      pv Advanced
      Figure 2. And advanced storage topology allowing for high performance disk I/O for data and index services, while allowing configuration and logs to reside on cheaper storage media.

      Persistent storage also makes the Couchbase cluster far more resilient. In a total disaster, an ephemeral cluster cannot be recovered, and the data is lost forever. With persistent storage, the Couchbase Autonomous Operator can recover the cluster. Recovery is also faster with persistent storage, as there is a high probably that a large percentage of the persisted data is still valid and can be reused. The Couchbase Autonomous Operator makes use of Couchbase Server’s delta-node recovery to dramatically reduce rebalance times for adding the failed node back to the cluster.

      Get Started

      The Couchbase Autonomous Operator fully supports Couchbase clusters running with persistent volumes backed by the following provisioners:

      Refer to the links below for more information about using persistent volumes.