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
Previously, the existing cluster upgrade focused on the updating
of a cluster's underlying container images. However, due to the
various changes in the Postgres Operator's operation, including numerous
updates to the relevant CRDs, integration of Patroni for HA and other
significant changes between versions, updates between Postgres Operator
releases required the manual deletion of the existing clusters while
being sure to preserve the underlying PVC storage. After installing the
new version, the clusters could be recreated manually so long as the
name of the new cluster matched the existing PVC's name.
This process has been completely overhauled so that now, when the Postgres
Operator has been updated to a new version, the existing pgclusters will
be left in place. Normal Operator functionality will be restricted until
the clusters are upgraded to match the currently installed version, although
the pods, services, etc will still be in place and accessible via other
methods (e.g. kubectl, service IP, etc).
To upgrade a particular cluster, use
pgo upgrade mycluster
This will follow a similar process to the existing documented manual process,
where the pods, deployments, replicasets, pgtasks and jobs are deleted, the
cluster's replicas are scaled down and replica PVCs deleted, but the primary
PVC and backrest-repo PVC are left in place. Existing services for the primary,
replica and backrest-shared-repo are also kept. Configmaps and secrets are
kept except where deletion is required. For a cluster 'mycluster', the
following configmaps will be deleted (if they exist) and recreated:
mycluster-leader
mycluster-pgha-config
One exception to this is during the upgrade of a standby cluster, where
the 'mycluster-pgha-config' configmap is modified, but not deleted. This is
necessary to ensure the standby cluster is not reinitialized during upgrade.
The secret 'mycluster-backrest-repo-config' will also be deleted and
recreated in this example to ensure the encryption key used matches the current
version requirements.
The pgcluster CRD will then be read, updated automatically and replaced, at which
point the normal cluster creation process will take over. The end result of the
upgrade should be an identical numer of pods, deployments, etc with a new pgbackrest
backup taken, but existing backups still available.
Please note, this upgrade currently supports cluster upgrades from Postgres
Operator version 4.1.0 and later, and can be run multiple times against the
same cluster if needed.
response.Status.Msg=fmt.Sprintf("Could not upgrade cluster: there exists an ongoing upgrade task: [%s]. If you believe this is an error, try deleting this pgtask CR.", task.Spec.Name)
139
+
returnresponse
105
140
}
106
141
107
-
//validate the cluster name and ensure autofail is turned off for each cluster.
142
+
//validate the cluster name and ensure autofail is turned off for each cluster.
log.Debugf("Cannot upgrade from %s to %s. Image must be the same base OS and the upgrade must be within the same major PG version.", cl.Spec.CCPImageTag, apiserver.Pgo.Cluster.CCPImageTag)
123
164
response.Status.Code=msgs.Error
124
-
response.Status.Msg="can not upgrade to the same image tag "+imageToUpgradeTo+" "+cl.Spec.CCPImageTag
165
+
response.Status.Msg=fmt.Sprintf("cannot upgrade from %s to %s, upgrade task failed.", cl.Spec.CCPImageTag, apiserver.Pgo.Cluster.CCPImageTag)
125
166
returnresponse
126
167
}
127
-
log.Debugf("upgrading to image tag %s", imageToUpgradeTo)
128
-
spec.Parameters["CCPImageTag"] =imageToUpgradeTo
168
+
169
+
// given the above check passed, save the CCP image tag value
0 commit comments