You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update pattern of handling minor PostgreSQL version upgrades
This modifies how PostgreSQL minor version upgrades are applied across a cluster to help
minimize downtime. The Operator will have each replica in a cluster updated sequentially to the requested minor version before attempting to update the primary.
When `autofail` is enabled, the cluster will promote one of the replicas, which at that point
will already be upgraded to the updated version of PostgreSQL.
Copy file name to clipboardExpand all lines: hugo/content/Upgrade/_index.md
+20Lines changed: 20 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,3 +17,23 @@ This section of the documentation shows specific steps required to upgrade diffe
17
17
[Upgrade Postgres Operator from 3.5 to 4.1] ( {{< relref "upgrade/upgrade35to4.md" >}})
18
18
19
19
[Upgrade Postgres Operator from 4.0.1 to 4.1.0] ( {{< relref "upgrade/upgrade40to41.md" >}})
20
+
21
+
## Upgrading A Postgres Cluster
22
+
23
+
Using the operator, it is possible to upgrade a postgres cluster in place. When a pgo upgrade command is issued, and a --CCPImageTag is specified, the operator will upgrade each replica and the primary to the new CCPImageTag version. It is important to note that the postgres version of the new container should be compatible with the current running version. There is currently no version check done to ensure compatibility.
24
+
25
+
The upgrade is accomplished by updating the CCPImageTag version in the deployment, which causes the old pod to be terminated and a new pod created with the updated deployment specification.
26
+
27
+
When the upgrade starts, each replica is upgraded seqentially, waiting for the previous replica to go ready before updating the next. After the replicas complete, the primary is then upgraded to the new image. The upgrade process respects the _autofail_ and the _AutofailReplaceReplica_ settings as provided in the pgo.yaml or as a command line flag, if applicable.
28
+
29
+
When the cluster is not in _autofail_ mode, the deployments simply create a new pod when updated, terminating the old one. When autofail is enabled and the primary deployment is updated, the cluster behaves as though the primary had failed and begins the failover process. See _Automatic Failover_ in the _Overview_ section for more details on this and replica replacement.
30
+
31
+
At this time, the backrest-repo container is not upgraded during this upgrade as it is part of the postgres operator release and is updated with the operator.
32
+
33
+
## Minor Upgrade Example
34
+
35
+
In this example, we are upgrading a cluster from PostgreSQL 11.4 to 11.5 using the `crunchy-postgres:centos7-11.5-2.4.2` container:
0 commit comments