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
Along with the great new features added in Operator 4.2.0,
we want to make sure we have documented steps to make it as
easy and streamlined as possible for users to upgrade to this
new version.
This commit updates and adds documenation as needed so that users
currently using Operator versions 3.5 and all subversions of 4.0 and
4.1 are able to upgrade to 4.2.0. This includes procedures to upgrade
to a 4.2.0 Bash installation for all versions, as well as upgrade
procedures for those already using an Ansible installation for their
Postgres Operator 4.X deployment.
Also, links on the main upgrade page are updated accordingly.
## Upgrading a Cluster from Version 3.5.x to PGO 4.1
8
+
## Upgrading a Cluster from Version 3.5.x to PGO 4.2.0
9
9
10
-
This section will outline the procedure to upgrade a given cluster created using Postgres Operator 3.5.x to PGO version 4.1
10
+
This section will outline the procedure to upgrade a given cluster created using Postgres Operator 3.5.x to PGO version 4.2.0. This version of the Postgres Operator has several fundamental changes to the existing PGCluster structure and deployment model. Most notably, all PGClusters use the new Crunchy Postgres HA container in place of the previous Crunchy Postgres containers. The use of this new container is a breaking change from previous versions of the Operator.
11
11
12
+
#### Crunchy Postgres High Availability Containers
13
+
14
+
Using the PostgreSQL Operator 4.2.0 requires replacing your `crunchy-postgres` and `crunchy-postgres-gis` containers with the `crunchy-postgres-ha` and `crunchy-postgres-gis-ha` containers respectively. The underlying PostgreSQL installations in the container remain the same but are now optimized for Kubernetes environments to provide the new high-availability functionality.
15
+
16
+
A major change to this container is that the PostgreSQL process is now managed by Patroni. This allows a PostgreSQL cluster that is deployed by the PostgreSQL Operator to manage its own uptime and availability, to elect a new leader in the event of a downtime scenario, and to automatically heal after a failover event.
17
+
18
+
When creating your new clusters using version 4.2.0 of the Postgres Operator, the `pgo create cluster` command will automatically use the new `crunchy-postgres-ha` image if the image is unspecified. If you are creating a PostGIS enabled cluster, please be sure to use the updated image name, as with the command:
As with any upgrade, please ensure you have taken recent backups of all relevant data!
@@ -18,11 +28,11 @@ As with any upgrade, please ensure you have taken recent backups of all relevant
18
28
##### Prerequisites.
19
29
You will need the following items to complete the upgrade:
20
30
21
-
* The latest PGO 4.1 code for the Postgres Operator available
22
-
* The latest PGO 4.1 client binary
31
+
* The latest PGO 4.2.0 code for the Postgres Operator available
32
+
* The latest PGO 4.2.0 client binary
23
33
24
34
##### Step 0
25
-
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.1.
35
+
Create a new Linux 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.2.0.
26
36
27
37
##### Step 1
28
38
For the cluster(s) you wish to upgrade, scale down any replicas, if necessary, then delete the cluster
@@ -42,34 +52,39 @@ Delete the 3.5.x version of the operator by executing:
42
52
$COROOT/deploy/remove-crd.sh
43
53
44
54
##### Step 3
45
-
Log in as your new Linux user and install the 4.1 Postgres Operator.
55
+
Log in as your new Linux user and install the 4.2.0 Postgres Operator.
Be sure to add the existing namespace to the Operator's list of watched namespaces (see the [Namespace] ( {{< relref "architecture/namespace.md" >}}) section of this document for more information) and make sure to avoid overwriting any existing data storage.
48
60
49
61
50
62
##### Step 4
51
-
Once the Operator is installed and functional, create a new 4.1 cluster with the same name as was used previously. This will allow the new cluster to utilize the existing PVCs.
63
+
Once the Operator is installed and functional, create a new 4.2.0 cluster with the same name and using the same major PostgreSQL version as was used previously. This will allow the new cluster to utilize the existing PVCs.
52
64
53
65
pgo create cluster <clustername> -n <namespace>
54
66
55
67
##### Step 5
56
-
Manually update the old leftover Secrets to use the new label as defined in 4.1:
68
+
Manually update the old leftover Secrets to use the new label as defined in 4.2.0:
psql -p 5432 -h 10.104.74.189 -U postgres postgres is Working
68
-
psql -p 5432 -h 10.104.74.189 -U postgres userdb is Working
69
-
psql -p 5432 -h 10.104.74.189 -U primaryuser postgres is Working
70
-
psql -p 5432 -h 10.104.74.189 -U primaryuser userdb is Working
71
-
psql -p 5432 -h 10.104.74.189 -U testuser postgres is Working
72
-
psql -p 5432 -h 10.104.74.189 -U testuser userdb is Working
81
+
cluster : mycluster
82
+
Services
83
+
primary (10.106.70.238:5432): UP
84
+
Instances
85
+
primary (mycluster-7d49d98665-7zxzd): UP
73
86
```
74
87
##### Step 7
75
88
Scale up to the required number of replicas, as needed.
89
+
90
+
It is also recommended to take full backups of each pgcluster once the upgrade is completed due to version differences between the old and new clusters.
## Postgres Operator Ansible Upgrade Procedure from 4.X to 4.2.0
9
+
10
+
This procedure will give instructions on how to upgrade to version 4.2.0 of the Crunchy Postgres Operator using the Ansible installation method. This version of the Postgres Operator has several fundamental changes to the existing PGCluster structure and deployment model. Most notably, all PGClusters use the new Crunchy Postgres HA container in place of the previous Crunchy Postgres containers. The use of this new container is a breaking change from previous versions of the Operator.
11
+
12
+
#### Crunchy Postgres High Availability Containers
13
+
14
+
Using the PostgreSQL Operator 4.2.0 requires replacing your `crunchy-postgres` and `crunchy-postgres-gis` containers with the `crunchy-postgres-ha` and `crunchy-postgres-gis-ha` containers respectively. The underlying PostgreSQL installations in the container remain the same but are now optimized for Kubernetes environments to provide the new high-availability functionality.
15
+
16
+
A major change to this container is that the PostgreSQL process is now managed by Patroni. This allows a PostgreSQL cluster that is deployed by the PostgreSQL Operator to manage its own uptime and availability, to elect a new leader in the event of a downtime scenario, and to automatically heal after a failover event.
17
+
18
+
When creating your new clusters using version 4.2.0 of the Postgres Operator, the `pgo create cluster` command will automatically use the new `crunchy-postgres-ha` image if the image is unspecified. If you are creating a PostGIS enabled cluster, please be sure to use the updated image name, as with the command:
As with any upgrade, please ensure you have taken recent backups of all relevant data!
25
+
26
+
{{% / notice %}}
27
+
28
+
##### Prerequisites.
29
+
You will need the following items to complete the upgrade:
30
+
31
+
* The latest 4.2.0 code for the Postgres Operator available
32
+
33
+
These instructions assume you are executing in a terminal window and that your user has admin privileges in your Kubernetes or Openshift environment.
34
+
35
+
36
+
##### Step 0
37
+
For the cluster(s) you wish to upgrade, scale down any replicas, if necessary (see `pgo scaledown --help` for more information on command usage) page for more information), then delete the cluster
38
+
39
+
pgo delete cluster <clustername>
40
+
41
+
{{% notice warning %}}
42
+
43
+
Please note the name of each cluster, the namespace used, and be sure not to delete the associated PVCs or CRDs!
44
+
45
+
{{% /notice %}}
46
+
47
+
48
+
##### Step 1
49
+
50
+
Save a copy of your current inventory file with a new name (such as `inventory.backup)` and checkout the latest 4.2.0 tag of the Postgres Operator.
51
+
52
+
53
+
##### Step 2
54
+
Update the new inventory file with the appropriate values for your new Operator installation, as described in the [Ansible Install Prerequisites] ( {{< relref "installation/install-with-ansible/prerequisites.md" >}}) and the [Compatibility Requirements Guide] ( {{< relref "configuration/compatibility.md" >}}).
55
+
56
+
57
+
##### Step 3
58
+
59
+
Now you can upgrade your Operator installation and configure your connection settings as described in the [Ansible Update Page] ( {{< relref "installation/install-with-ansible/updating-operator.md" >}}).
60
+
61
+
62
+
##### Step 4
63
+
Verify the Operator is running:
64
+
65
+
kubectl get pod -n <operator namespace>
66
+
67
+
And that it is upgraded to the appropriate version
68
+
69
+
pgo version
70
+
71
+
##### Step 5
72
+
Once the Operator is installed and functional, create a new 4.2.0 cluster with the same name and using the same major PostgreSQL version as was used previously. This will allow the new clusters to utilize the existing PVCs.
73
+
74
+
pgo create cluster <clustername> -n <namespace>
75
+
76
+
##### Step 6
77
+
To verify cluster status, run
78
+
79
+
pgo test <clustername> -n <namespace>
80
+
81
+
Output should be similar to:
82
+
```
83
+
cluster : mycluster
84
+
Services
85
+
primary (10.106.70.238:5432): UP
86
+
Instances
87
+
primary (mycluster-7d49d98665-7zxzd): UP
88
+
```
89
+
##### Step 7
90
+
Scale up to the required number of replicas, as needed.
91
+
92
+
It is also recommended to take full backups of each pgcluster once the upgrade is completed due to version differences between the old and new clusters.
0 commit comments