Rolling Updates

The operator allows changing the PostgreSQL version used in a cluster whileapplications are running against it.

Important

Only upgrades for PostgreSQL minor releases are supported.

Rolling upgrades are started when:

  • the user changes the imageName attribute of the cluster specification;

  • a change on the Cluster .spec.resources values

  • a change in size of the persistent volume claim on AKS

The operator starts upgrading all the replicas, one Pod at a time, and beginsfrom the one with the highest serial.

The primary is the last node to be upgraded.

Rolling updates are configurable and can be either entirely automated( unsupervised ) or requiring human intervention ( supervised ).

The upgrade keeps the CloudNativePG identity, without re-cloning thedata. Pods will be deleted and created again with the same PVCs and a newimage, if required.

During the rolling update procedure, each service endpoints move to reflect thecluster’s status, so that applications can ignore the node that is beingupdated.

Automated updates ( unsupervised )

When primaryUpdateStrategy is set to unsupervised , the rolling updateprocess is managed by Kubernetes and is entirely automated. Once the replicashave been upgraded, the selected primaryUpdateMethod operation will initiateon the primary. This is the default behavior.

The primaryUpdateMethod option accepts one of the following values:

There’s no one-size-fits-all configuration for the update method, as thatdepends on several factors like the actual workload of your database, therequirements in terms of RPO and RTO, whether your PostgreSQL architecture isshared or shared nothing, and so on.

Indeed, being PostgreSQL a primary/standby architecture database managementsystem, the update process inevitably generates a downtime for yourapplications. One important aspect to consider for your context is the time ittakes for your pod to download the new PostgreSQL container image, as thatdepends on your Kubernetes cluster settings and specifications. The switchover method makes sure that the promoted instance already runs thetarget image version of the container. The restart method instead might requireto download the image from the origin registry after the primary pod has beenshut down. It is up to you to determine whether, for your database, it is bestto use restart or switchover as part of the rolling update procedure.

Manual updates ( supervised )

When primaryUpdateStrategy is set to supervised , the rolling update processis suspended immediately after all replicas have been upgraded.

This phase can only be completed with either a manual switchover or an in-placerestart.

You can trigger a switchover with:

kubectl cnpg promote [cluster] [new_primary]

You can trigger a restart with:

kubectl cnpg restart [cluster] [current_primary]

You can find more information in the cnpg .