EDB Postgres® AI for CloudNativePG Certified

In case of detected failure on the primary, the operator will change the status of the cluster by setting the most aligned replica as the new target primary. As a consequence, the instance manager in each alive pod will initiate the required procedures to align itself with the requested status of the cluster, by either becoming the new primary or by following it. In case the former primary comes back up, the same mechanism will avoid a split-brain by preventing applications from reaching it, running `pg_rewind` on the server and restarting it as a standby. Self-healing is enhanced by the automated recreation of a standby: in case the pod hosting a standby is removed, the operator initiates the procedure to recreate a standby server.

The operator supports rolling update of a minor release of PostgreSQL. In the presence of standby servers, the operator performs rolling updates starting from the replicas, by replacing the Postgres image and reusing the underlying storage.

The operator has been designed to provide application-level backups using PostgreSQL’s native continuous backup technology based on physical base backups and continuous WAL archiving. Specifically, the operator currently supports only object stores compatible with AWS S3, Google Cloud Storage, and Azure Blob Containers. EDB Postgres® AI for CloudNativePG internally relies on `barman-cloud-wal-archive` and `barman-cloud-backup`, both already distributed in the application container image under GNU GPL 3 terms.

In the case of full recovery, the operator enables users to bootstrap a new cluster (with its settings) starting from an existing and accessible backup taken using `barman-cloud-backup`. Once the bootstrap process is completed, the operator initiates the instance in recovery mode and replays all available WAL files from the specified archive, exiting recovery and starting as a primary. Subsequently, the operator will clone the requested number of standby instances from the primary. Alternative, users can create a new PostgreSQL cluster by recovering an existing backup to a specific point-in-time, defined with a timestamp, a label or a transaction ID. This capability is built on top of the full restore one and supports all the options available in PostgreSQL for PITR. EDB Postgres® AI for CloudNativePG internally relies on `barman-cloud-wal-restore` and `barman-cloud-restore`, both already distributed in the application container image under GNU GPL 3 terms.

Achieve Zero Data Loss (RPO=0) in your local High Availability EDB Postgres® AI for CloudNativePG cluster through quorum based synchronous replication support. The operator provides two configuration options that control the minimum and maximum number of expected synchronous standby replicas available at any time.

Reuse of Persistent Volumes storage in Pods. Support for Local Persistent Volumes with PVC templates and storage classes.