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.
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!
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
configuration file using the
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.
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
Lastly the entire Operator documentation was redesigned and rewritten to better describe the current features of the Operator.
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.
January 24, 2019 •More by this author