4.3.0 Beta 3

Crunchy Data is pleased to announce the release of PostgreSQL Operator 4.3.0 Beta 3. We encourage you to download it and try it out.

Changes Since Beta 2:

Breaking Changes

• pgo-installer is renamed to pgo-deployer
• The examples files that pgo-deployer have been renamed, i.e. deploy.yml
• The names of the scheduled backups are shortened to use the pattern <clusterName>-<backupType>-sch-backup
• The --cpu flags on pgo create cluster, pgo update cluster, pgo create pgbouncer, pgo update pgbouncer, as well as the --pgbackrest-cpu and --pgbouncer-cpu flags on the pgo create cluster and pgo update cluster commands now set both the Resource Request and Limit for CPU

Features

Automatic PostgreSQL Operator Upgrade Process

One of the biggest challenges to using a newer version of the PostgreSQL
Operator was upgrading from an older version.

This release introduces the ability to upgrade from an older version of the
Operator (as early as 4.1.0) to the newest version (4.3.0) using the
pgo upgrade command.

External WAL Volume

An optimization used for improving PostgreSQL performance related to file system
usage is to have the PostgreSQL write-ahead logs (WAL) written to a different
mounted volume than other parts of the PostgreSQL system, such as the data
directory.

To support this, the PostgreSQL Operator nows supports the ability to specify an
external volume for writing the PostgreSQL write-head log (WAL) during cluster
creation, which carries through to replicas and clones. When not specified, the
WAL resides within the PGDATA directory and volume, which is the present
behavior.

To create a PostgreSQL cluster to use an external volume, one can use the
--wal-storage-config flag at cluster creation time to select the storage
configuration to use, e.g.

pgo create cluster --wal-storage-config=nfsstorage hippo

Additionally, it is also possible to specify the size of the WAL storage on all
newly created clusters. When in use, the size of the volume can be overridden
per-cluster. This is specified with the --wal-storage-size flag, i.e.

pgo create cluster --wal-storage-config=nfsstorage --wal-storage-size=10Gi hippo

This implementation does not define the WAL volume in any deployment templates
because the volume name and mount path are constant.

Improved Custom Configuration for PostgreSQL Clusters

The ability to customize the configuration for a PostgreSQL cluster with the
PostgreSQL Operator can now be easily modified by making changes directlry to
the ConfigMap that is created with each PostgreSQL cluster. The ConfigMap, which
follows the pattern <clusterName>-pgha-config (e.g. hippo-pgha-config for
pgo create cluster hippo), manages the user-facing configuration settings
available for a PostgreSQL cluster, and when modified, it will automatically
synchronize the settings across all primaries and replicas in a PostgreSQL
cluster.

Presently, the ConfigMap can be edited using the kubectl edit cm command, and
future iterations will add functionality to the PostgreSQL Operator to make this
process easier.

Other Features

• A script called client-setup.sh is now included to set up the client libraries after the install process from pgo-deployer is run
• The pgo-deployer now deploys the metrics stack (Prometheus, Grafana)
• One can specify the "image prefix" (e.g. crunchydata) for the containers that are deployed by the PostgreSQL Operator. This adds two fields to the pgcluster CRD: CCPImagePrefix and PGOImagePrefix. These are also available on pgo create cluster with the --ccp-image-prefix and --pgo-image-prefix flags respectively
• The pgBouncer deployment can be scaled. This can be done from the pgo create cluster --pgbouncer-replicas, pgo create pgbouncer --replicas, and pgo update pgbouncer --replicas flags. The default number of replicas is "1", which deploys one pgBouncer Pod. This and the other pgBouncer CRD attributes can also be set declaratively in a pgcluster CR.

Fixes

• The default PostgreSQL memory request was lowered to 128Mi to avoid crashes, particularly in test environments. This is actually set in the installers so it's easily configurable, and the "default of last resort" is still 512Mi to be consistent with the PostgreSQL defaults.
• pgo-deployer can now work with external container registries as well as image pull secrets
• The ConfigMap and ClusterRoleBinding for the pgo-deployer container are now cleaned up
• The stanza-create Job now waits for both the PostgreSQL cluster and the pgBackRest repository to be ready before executing
• The Grafana and Prometheus Pods no longer crash on GKE
• pgo clone --metrics now enables the metrics on the cloned cluster. This fixes a regression with the feature
• Ensure commands that execute SQL directly on a container (e.g. pgo show user) work if PostgreSQL is deployed to a nonstandard port