What's New in Crunchy PostgreSQL Operator 3.5

Crunchy Data is happy to announce the release of the open source PostgreSQL Operator 3.5 for Kubernetes project, which you can find here: https://github.com/CrunchyData/postgres-operator/

This latest release provides further feature enhancements designed to support users intending to deploy large-scale PostgreSQL clusters on Kubernetes, with enterprise high-availability and disaster recovery requirements.

When combined with the Crunchy PostgreSQL Container Suite, the PostgreSQL Operator provides an open source, Kubernetes-native PostgreSQL-as-a-Service capability.

Read on to see what is new in PostgreSQL Operator 3.5.

pgBackRest Architecture Enhancements

In order to reduce disk consumption resulting from backups of large PostgreSQL clusters, the PostgreSQL Operator 3.5 improves on the existing pgBackRest to provide users with a pgBackRest shared repository. This shared pgBackRest repository is used by the primary and each of the replicas of a given PostgreSQL cluster deployed by the Operator. This pgBackRest repository runs within its own Kubernetes Deployment and is dedicated to serving this given single PostgreSQL cluster.

pgBackRest Point-In-Time-Recovery

The PostgreSQL Operator 3.5 provides point-in-time-recovery from this newly introduced pgBackRest shared repository by implementing the pgBackRest restore command.

Users can create a pgBackRest backup using the following pgo CLI command:

pgo backup mycluster --backup-type=pgbackrest

Users can view pgBackRest backups using the following command:

pgo show backup mycluster --backup-type=pgbackrest

Users can perform a point-in-time restore of a given cluster with pgBackRest using the following command:

pgo restore mycluster --backup-opts="--type=time" --pitr-target="2019-01-14 00:02:14.921404+00"

Note: When you restore a cluster, you are putting your PostgreSQL database into a different state (or timeline) and therefore you should exercise caution before doing so!

Fast Failover

A key component of high-availability is ensuring that you are able to quickly fail over from a primary to a replica database in order to limit your downtime. This new release of the PostgreSQL Operator ensures that failovers are fast: a replica can now be promoted to a primary in only a matter of milliseconds!

Archive Storage Configuration

For PostgreSQL Operator users that require and have enabled archiving, but have elected not to use pgBackRest, this release provides a means to specify storage volume sizes specifically for their archive volumes. In this new release, users can now specify configuration setting for your WAL archives in the pgo.yaml configuration file using the XlogStorageConfig setting.

Auto-failover Toggle

Users can now turn off and back on the auto-failover feature for a given cluster. This is helpful for when you need to do maintenance for a PostgreSQL cluster (or perhaps you just want to avoid auto-failover from kicking in).

This is performed using the command line:

pgo update mycluster --label=autofail=false

Preferred Failover Node Label

In PostgreSQL Operator 3.5, we have added a Kubernetes label selector setting within the pgo.yaml configuration file. If set, this selector will be used to determine a list of preferred Kubernetes nodes on which a target would be selected as part of a failover, whether manual or automated. This feature supports a more precise failover target selection and will be expanded in future versions.

pgo-scheduler

In PostgreSQL Operator 3.5, we wrote a dedicated and highly integrated cron scheduler which now runs within the Operator pod. This scheduler is tightly integrated into the Operator and offers users a means to schedule pg_basebackup, pgBackRest, and policy scheduled jobs (or in other words, jobs where you want to run your own SQL). Users interact with the scheduler using the following commands:

pgo create schedule
pgo delete schedule
pgo show schedule

Documentation

Lastly the entire Operator documentation was redesigned and rewritten to better describe the current features of the Operator.

Final Thoughts

Crunchy Data views the PostgreSQL Operator as an enabling component for enterprises interested in deploying Kubernetes native PostgreSQL-as-a-Service. In this 3.5 release, we have targeted specific new functionality that will better enable enterprises to deploy increasingly sophisticated containerized PostgreSQL infrastructure in a highly integrated Kubernetes environment.

While this release represents a major milestone, the rapid innovation demonstrated by the Kubernetes community and the potential for the Operator pattern provides an opportunity for continued improvements in a variety of directions. You can also find more information about running PostgreSQL on Kubernetes on our website.

Please stay tuned, and we welcome any feedback or questions as you get started.