Cluster upgrade from 3.5 to 4.0
@@ -32,3 +32,48 @@ removes the ingest related API endpoints.
* The pgo.yaml file now includes a setting, AutofailReplaceReplica, which will enable or disable whether a new replica is created as part of a fail-over. This is turned off by default.
See the GitHub Release notes for the features and other notes about a specific release.
+
+### Upgrading a Cluster from Version 3.5.x to 4.0
+
+This section will outline the procedure to upgrade a given cluster created using Postgres Operator 3.5.x to 4.0.
+
+1) Create a new Centos/Redhat user with the same permissions are the existing user used to install the Crunchy Postgres Operator. This is necessary to avoid any issues with environment variable differences between 3.5 and 4.0.
+
+2) For the cluster(s) you wish to upgrade, scale down any replicas, if necessary, then delete the cluster
+
+ pgo delete cluster <clustername>
+
+IMPORTANT NOTES:
+Please note the name of each cluster,
+the namespace used,
+and be sure not to delete the associated PVCs or CRDs!
+
+3) Delete the 3.5.x version of the operator by executing:
+
+ $COROOT/deploy/cleanup.sh
+ $COROOT/deploy/remove-crd.sh
+
+4) Log in as your new Linux user and install the 4.0 Postgres Operator. Be sure to add the existing namespace to the list of watched namespaces (see the 'Getting Started->Design->Namespace' section of this document for more information) and make sure to avoid overwriting any existing data storage.
+
+5) Once the Operator is installed and functional, create a new 4.0 cluster with the same name as was used previously. This will allow the new cluster to utilize the existing PVCs.
+
+ pgo create cluster <clustername> -n <namespace>
+
+6) Manually update the old leftover Secrets to use the new label as defined in 4.0:
+
+ kubectl label secret/<clustername>-postgres-secret pg-cluster=<clustername> -n <namespace>
+ kubectl label secret/<clustername>-primaryuser-secret pg-cluster=<clustername> -n <namespace>
+ kubectl label secret/<clustername>-testuser-secret pg-cluster=<clustername> -n <namespace>
+
+7) To verify cluster status, run
+ pgo test <clustername> -n <namespace>
+Output should be similar to:
+```
+psql -p 5432 -h 10.104.74.189 -U postgres postgres is Working
+psql -p 5432 -h 10.104.74.189 -U postgres userdb is Working
+psql -p 5432 -h 10.104.74.189 -U primaryuser postgres is Working
+psql -p 5432 -h 10.104.74.189 -U primaryuser userdb is Working
+psql -p 5432 -h 10.104.74.189 -U testuser postgres is Working
+psql -p 5432 -h 10.104.74.189 -U testuser userdb is Working
+```
+8) Scale up to the required number of replicas, as needed.
