Upgrading to a new version of PGO is typically as simple as following the various installation guides defined within the PGO documentation:
However, when upgrading to or from certain versions of PGO, extra steps may be required in order to ensure a clean and successful upgrade. This page will therefore document any additional steps that must be completed when upgrading PGO.
Upgrading from PGO v5.0.0 Using Kustomize
Starting with PGO v5.0.1, both the Deployment and ServiceAccount created when installing PGO via
the installers in the
Postgres Operator examples repository
have been renamed from
pgo. As a result of this change, if using
Kustomize to install PGO and upgrading from PGO v5.0.0, the following step must be completed prior
to upgrading. This will ensure multiple versions of PGO are not installed and running concurrently
within your Kubernetes environment.
Prior to upgrading PGO, first manually delete the PGO v5.0.0
postgres-operator Deployment and
kubectl -n postgres-operator delete deployment,serviceaccount postgres-operator
Then, once both the Deployment and ServiceAccount have been deleted, proceed with upgrading PGO by applying the new version of the Kustomize installer:
kubectl apply --server-side -k kustomize/install/default
Upgrading from PGO v5.0.2 and Below
As a result of changes to pgBackRest dedicated repository host deployments in PGO v5.0.3 (please see the PGO v5.0.3 release notes for more details), reconciliation of a pgBackRest dedicated repository host might become stuck with the following error (as shown in the PGO logs) following an upgrade from PGO versions v5.0.0 through v5.0.2:
StatefulSet.apps \"hippo-repo-host\" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy' and 'minReadySeconds' are forbidden
If this is the case, proceed with deleting the pgBackRest dedicated repository host StatefulSet, and PGO will then proceed with recreating and reconciling the dedicated repository host normally:
kubectl delete sts hippo-repo-host
Additionally, please be sure to update and apply all PostgresCluster custom resources in accordance with any applicable spec changes described in the PGO v5.0.3 release notes.
Upgrading from PGO v5.0 to v5.1
Starting in PGO v5.1, new pgBackRest features available in version 2.38 are used
that impact both the
crunchy-pgbackrest images. For any
existing clusters, you will need to update these image values BEFORE upgrading to
PGO 5.1. These changes will need to be made in one of two places, depending on
your desired configuration.
If you are setting the image values on your
you would update the images value as shown (updating the
image values as
appropriate for your environment):
apiVersion: postgres-operator.crunchydata.com/v1beta1 kind: PostgresCluster metadata: name: hippo spec: image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:ubi8-14.2-1 postgresVersion: 14 ... backups: pgbackrest: image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:ubi8-2.38-0 ...
After updating these values, you will apply these changes to your PostgresCluster custom resources. After these changes are completed and the new images are in place, you may update PGO to 5.1.
Relatedly, if you are instead using the
RELATED_IMAGE environment variables to
set the image values, you would instead check and update these as needed before
For Kustomize installations, these can be found in the
manager directory and
manager.yaml file. Here you will note various key/value pairs, these will need
to be updated before deploying PGO 5.1. Besides updating the
RELATED_IMAGE_PGBACKREST value, you will also need to update the relevant
Postgres image for your environment. For example, if you are using PostgreSQL 14,
you would update the value for
RELATED_IMAGE_POSTGRES_14. If instead you are
using the PostGIS 3.1 enabled PostgreSQL 13 image, you would update the value
For Helm deployments, you would instead need to similarly update your
file, found in the
install directory. There you will note a
section, followed by similar values as mentioned above. Again, be sure to update
pgbackrest as well as the appropriate
postgres value for your clusters.
Once there values have been properly verified, you may deploy PGO 5.1.