Skip to content

Commit 0c34e69

Browse files
authored
Update update docs (CrunchyData#3202)
Revise update docs (a) add note about potential automatic rollout of clusters when upgrading (b) spin off separate upgrade section, with v4-v5 subsection (c) tweak a little Issue [sc-14467]
1 parent 4951fb0 commit 0c34e69

File tree

11 files changed

+493
-445
lines changed

11 files changed

+493
-445
lines changed

docs/content/guides/v4tov5.md

Lines changed: 0 additions & 399 deletions
This file was deleted.

docs/content/installation/helm.md

Lines changed: 1 addition & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -90,36 +90,7 @@ PGO will check for updates upon startup and once every 24 hours. Any errors in c
9090

9191
For more information about collected data, see the Crunchy Data [collection notice](https://www.crunchydata.com/developers/data-collection-notice).
9292

93-
## Upgrade and Uninstall
94-
95-
Once PGO has been installed, it can then be upgraded using the `helm upgrade` command.
96-
However, before running the `upgrade` command, any CustomResourceDefinitions (CRDs) must first be
97-
manually updated (this is specifically due to a [design decision in Helm v3][helm-crd-limits],
98-
in which any CRDs in the Helm chart are only applied when using the `helm install` command).
99-
100-
[helm-crd-limits]: https://helm.sh/docs/topics/charts/#limitations-on-crds
101-
102-
If you would like, before upgrading the CRDs, you can review the changes with
103-
`kubectl diff`. They can be verbose, so a pager like `less` may be useful:
104-
105-
```shell
106-
kubectl diff -f helm/install/crds | less
107-
```
108-
109-
Use the following command to update the CRDs using
110-
[server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/)
111-
_before_ running `helm upgrade`. The `--force-conflicts` flag tells Kubernetes that you recognize
112-
Helm created the CRDs during `helm install`.
113-
114-
```shell
115-
kubectl apply --server-side --force-conflicts -f helm/install/crds
116-
```
117-
118-
Then, perform the upgrade using Helm:
119-
120-
```shell
121-
helm upgrade <name> -n <namespace> helm/install
122-
```
93+
## Uninstall
12394

12495
To uninstall PGO, remove all your PostgresCluster objects, then use the `helm uninstall` command:
12596

docs/content/releases/5.0.1.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ Read more about how you can [get started]({{< relref "quickstart/_index.md" >}})
2727
- Refreshed the PostgresCluster CRD documentation using the latest version of `crdoc` (`v0.3.0`).
2828
- The PGO test suite now includes a test to validate image pull secrets.
2929
- Related Image functionality has been implemented for the OLM installer as required to support offline deployments.
30-
- The name of the PGO Deployment and ServiceAccount has been changed to `pgo` for all installers, allowing both PGO v4.x and PGO v5.x to be run in the same namespace. If you are using Kustomize to install PGO and are upgrading from PGO 5.0.0, please see the [Upgrade Guide]({{< relref "../installation/upgrade.md" >}}) for addtional steps that must be completed as a result of this change in order to ensure a successful upgrade.
30+
- The name of the PGO Deployment and ServiceAccount has been changed to `pgo` for all installers, allowing both PGO v4.x and PGO v5.x to be run in the same namespace. If you are using Kustomize to install PGO and are upgrading from PGO 5.0.0, please see the [Upgrade Guide]({{< relref "../upgrade/_index.md" >}}) for addtional steps that must be completed as a result of this change in order to ensure a successful upgrade.
3131
- PGO now automatically detects whether or not it is running in an OpenShift environment.
3232
- Postgres users and databases can be specified in `PostgresCluster.spec.users`. The credentials stored in the `{cluster}-pguser` Secret are still valid, but they are no longer reconciled. References to that Secret should be replaced with `{cluster}-pguser-{cluster}`. Once all references are updated, the old `{cluster}-pguser` Secret can be deleted.
3333
- The built-in `postgres` superuser can now be managed the same way as other users. Specifying it in `PostgresCluster.spec.users` will give it a password, allowing it to connect over the network.

docs/content/releases/5.0.3.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ Read more about how you can [get started]({{< relref "quickstart/_index.md" >}})
3737
- A [Pod Priority Class](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) is configurable for the Pods created for a `PostgresCluster`.
3838
- An `imagePullPolicy` can now be configured for Pods created for a `PostgresCluster`.
3939
- Existing `PGDATA`, Write-Ahead Log (WAL) and pgBackRest repository volumes can now be migrated from PGO v4 to PGO v5 by specifying a `volumes` data source when creating a `PostgresCluster`.
40-
- There is now a [migration guide available for moving Postgres clusters between PGO v4 to PGO v5]({{< relref "guides/v4tov5.md" >}}).
40+
- There is now a [migration guide available for moving Postgres clusters between PGO v4 to PGO v5]({{< relref "upgrade/v4tov5/_index.md" >}}).
4141
- The pgAudit extension is now enabled by default in all clusters.
4242
- There is now additional validation for PVC definitions within the `PostgresCluster` spec to ensure successful PVC reconciliation.
4343
- Postgres server certificates are now automatically reloaded when they change.

docs/content/upgrade/_index.md

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
---
2+
title: "Upgrade"
3+
date:
4+
draft: false
5+
weight: 33
6+
---
7+
8+
# Overview
9+
10+
Upgrading to a new version of PGO is typically as simple as following the various installation
11+
guides defined within the PGO documentation:
12+
13+
- [PGO Kustomize Install]({{< relref "./kustomize.md" >}})
14+
- [PGO Helm Install]({{< relref "./helm.md" >}})
15+
16+
However, when upgrading to or from certain versions of PGO, extra steps may be required in order
17+
to ensure a clean and successful upgrade.
18+
19+
This section provides detailed instructions for upgrading PGO 5.x using Kustomize or Helm, along with information for upgrading from PGO v4 to PGO v5.
20+
21+
{{% notice info %}}
22+
Depending on version updates, upgrading PGO may automatically rollout changes to managed Postgres clusters. This could result in downtime--we cannot guarantee no interruption of service, though PGO attempts graceful incremental rollouts of affected pods, with the goal of zero downtime.
23+
{{% /notice %}}
24+
25+
## Upgrading PGO 5.x
26+
27+
- [PGO Kustomize Upgrade]({{< relref "./kustomize.md" >}})
28+
- [PGO Helm Upgrade]({{< relref "./helm.md" >}})
29+
30+
## Upgrading from PGO v4 to PGO v5
31+
32+
- [V4 to V5 Upgrade Methods]({{< relref "./v4tov5" >}})

docs/content/upgrade/helm.md

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
---
2+
title: "Upgrading PGO v5 Using Helm"
3+
date:
4+
draft: false
5+
weight: 70
6+
---
7+
8+
Once PGO v5.0.x has been installed with Helm, it can then be upgraded using the `helm upgrade` command.
9+
However, before running the `upgrade` command, any CustomResourceDefinitions (CRDs) must first be
10+
manually updated (this is specifically due to a [design decision in Helm v3][helm-crd-limits],
11+
in which any CRDs in the Helm chart are only applied when using the `helm install` command).
12+
13+
[helm-crd-limits]: https://helm.sh/docs/topics/charts/#limitations-on-crds
14+
15+
If you would like, before upgrading the CRDs, you can review the changes with
16+
`kubectl diff`. They can be verbose, so a pager like `less` may be useful:
17+
18+
```shell
19+
kubectl diff -f helm/install/crds | less
20+
```
21+
22+
Use the following command to update the CRDs using
23+
[server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/)
24+
_before_ running `helm upgrade`. The `--force-conflicts` flag tells Kubernetes that you recognize
25+
Helm created the CRDs during `helm install`.
26+
27+
```shell
28+
kubectl apply --server-side --force-conflicts -f helm/install/crds
29+
```
30+
31+
Then, perform the upgrade using Helm:
32+
33+
```shell
34+
helm upgrade <name> -n <namespace> helm/install
35+
```

docs/content/installation/upgrade.md renamed to docs/content/upgrade/kustomize.md

Lines changed: 2 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,22 +1,10 @@
11
---
2-
title: "Upgrade"
2+
title: "Upgrading PGO v5 Using Kustomize"
33
date:
44
draft: false
55
weight: 50
66
---
77

8-
# Overview
9-
10-
Upgrading to a new version of PGO is typically as simple as following the various installation
11-
guides defined within the PGO documentation:
12-
13-
- [PGO Kustomize Install]({{< relref "./kustomize.md" >}})
14-
- [PGO Helm Install]({{< relref "./helm.md" >}})
15-
16-
However, when upgrading to or from certain versions of PGO, extra steps may be required in order
17-
to ensure a clean and successful upgrade. This page will therefore document any additional
18-
steps that must be completed when upgrading PGO.
19-
208
## Upgrading from PGO v5.0.0 Using Kustomize
219

2210
Starting with PGO v5.0.1, both the Deployment and ServiceAccount created when installing PGO via
@@ -63,7 +51,7 @@ Additionally, please be sure to update and apply all PostgresCluster custom reso
6351
with any applicable spec changes described in the
6452
[PGO v5.0.3 release notes]({{< relref "../releases/5.0.3.md" >}}).
6553

66-
## Upgrading from PGO v5.0 to v5.1
54+
## Upgrading from PGO v5.0.x to v5.1.x
6755

6856
Starting in PGO v5.1, new pgBackRest features available in version 2.38 are used
6957
that impact both the `crunchy-postgres` and `crunchy-pgbackrest` images. For any

docs/content/upgrade/v4tov5/_index.md

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
---
2+
title: "PGO v4 to PGO v5"
3+
date:
4+
draft: false
5+
weight: 100
6+
---
7+
8+
You can upgrade from PGO v4 to PGO v5 through a variety of methods by following this guide. There are several methods that can be used to upgrade: we present these methods based upon a variety of factors, including but not limited to:
9+
10+
- Redundancy / ability to roll back
11+
- Available resources
12+
- Downtime preferences
13+
14+
These methods include:
15+
16+
- [*Migrating Using Data Volumes*]({{< relref "./upgrade-method-1-data-volumes.md" >}}). This allows you to migrate from v4 to v5 using the existing data volumes that you created in v4. This is the simplest method for upgrade and is the most resource efficient, but you will have a greater potential for downtime using this method.
17+
- [*Migrate From Backups*]({{< relref "./upgrade-method-2-backups.md" >}}). This allows you to create a Postgres cluster with v5 from the backups taken with v4. This provides a way for you to create a preview of your Postgres cluster through v5, but you would need to take your applications offline to ensure all the data is migrated.
18+
- [*Migrate Using a Standby Cluster*]({{< relref "./upgrade-method-3-standby-cluster.md" >}}). This allows you to run a v4 and a v5 Postgres cluster in parallel, with data replicating from the v4 cluster to the v5 cluster. This method minimizes downtime and lets you preview your v5 environment, but is the most resource intensive.
19+
20+
You should choose the method that makes the most sense for your environment.
21+
22+
## Prerequisites
23+
24+
There are several prerequisites for using any of these upgrade methods.
25+
26+
- PGO v4 is currently installed within the Kubernetes cluster, and is actively managing any existing v4 PostgreSQL clusters.
27+
- Any PGO v4 clusters being upgraded have been properly initialized using PGO v4, which means the v4 `pgcluster` custom resource should be in a `pgcluster Initialized` status:
28+
29+
```
30+
$ kubectl get pgcluster hippo -o jsonpath='{ .status }'
31+
{"message":"Cluster has been initialized","state":"pgcluster Initialized"}
32+
```
33+
34+
- The PGO v4 `pgo` client is properly configured and available for use.
35+
- PGO v5 is currently [installed]({{< relref "installation/_index.md" >}}) within the Kubernetes cluster.
36+
37+
For these examples, we will use a Postgres cluster named `hippo`.
38+
39+
## Additional Considerations
40+
41+
Upgrading to PGO v5 may result in a base image upgrade from EL-7 (UBI / CentOS) to EL-8
42+
(UBI). Based on the contents of your Postgres database, you may need to perform
43+
additional steps.
44+
45+
Due to changes in the GNU C library `glibc` in EL-8, you may need to reindex certain indexes in
46+
your Postgres cluster. For more information, please read the
47+
[PostgreSQL Wiki on Locale Data Changes](https://wiki.postgresql.org/wiki/Locale_data_changes), how
48+
you can determine if your indexes are affected, and how to fix them.
Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
---
2+
title: "Upgrade Method #1: Data Volumes"
3+
date:
4+
draft: false
5+
weight: 10
6+
---
7+
8+
{{% notice info %}}
9+
Before attempting to upgrade from v4.x to v5, please familiarize yourself with the [prerequisites]({{< relref "upgrade/v4tov5/_index.md" >}}) applicable for all v4.x to v5 upgrade methods.
10+
{{% /notice %}}
11+
12+
This upgrade method allows you to migrate from PGO v4 to PGO v5 using the existing data volumes that were created in PGO v4. Note that this is an "in place" migration method: this will immediately move your Postgres clusters from being managed by PGO v4 and PGO v5. If you wish to have some failsafes in place, please use one of the other migration methods. Please also note that you will need to perform the cluster upgrade in the same namespace as the original cluster in order for your v5 cluster to access the existing PVCs.
13+
14+
### Step 1: Prepare the PGO v4 Cluster for Migration
15+
16+
You will need to set up your PGO v4 Postgres cluster so that it can be migrated to a PGO v5 cluster. The following describes how to set up a PGO v4 cluster for using this migration method.
17+
18+
1. Scale down any existing replicas within the cluster. This will ensure that the primary PVC does not change again prior to the upgrade.
19+
20+
You can get a list of replicas using the `pgo scaledown --query` command, e.g.:
21+
```
22+
pgo scaledown hippo --query
23+
```
24+
25+
If there are any replicas, you will see something similar to:
26+
27+
```
28+
Cluster: hippo
29+
REPLICA STATUS NODE ...
30+
hippo running node01 ...
31+
```
32+
33+
Scaledown any replicas that are running in this cluser, e.g.:
34+
35+
```
36+
pgo scaledown hippo --target=hippo
37+
```
38+
39+
2\. Once all replicas are removed and only the primary remains, proceed with deleting the cluster while retaining the data and backups. You can do this `--keep-data` and `--keep-backups` flags:
40+
41+
**You MUST run this command with the `--keep-data` and `--keep-backups` flag otherwise you risk deleting ALL of your data.**
42+
43+
```
44+
pgo delete cluster hippo --keep-data --keep-backups
45+
```
46+
47+
3\. The PVC for the primary Postgres instance and the pgBackRest repository should still remain. You can verify this with the command below:
48+
49+
```
50+
kubectl get pvc --selector=pg-cluster=hippo
51+
```
52+
53+
This should yield something similar to:
54+
55+
```
56+
NAME STATUS VOLUME ...
57+
hippo-jgut Bound pvc-a0b89bdb- ...
58+
hippo-pgbr-repo Bound pvc-25501671- …
59+
```
60+
61+
A third PVC used to store write-ahead logs (WAL) may also be present if external WAL volumes were enabled for the cluster.
62+
63+
### Step 2: Migrate to PGO v5
64+
65+
With the PGO v4 cluster's volumes prepared for the move to PGO v5, you can now create a [`PostgresCluster`]({{< relref "references/crd.md" >}}) custom resource using these volumes. This migration method does not carry over any specific configurations or customizations from PGO v4: you will need to create the specific `PostgresCluster` configuration that you need.
66+
67+
{{% notice warning %}}
68+
69+
Additional steps are required to set proper file permissions when using certain storage options,
70+
such as NFS and HostPath storage, due to a known issue with how fsGroups are applied. When
71+
migrating from PGO v4, this will require the user to manually set the group value of the pgBackRest
72+
repo directory, and all subdirectories, to `26` to match the `postgres` group used in PGO v5.
73+
Please see [here](https://github.com/kubernetes/examples/issues/260) for more information.
74+
75+
{{% /notice %}}
76+
77+
To complete the upgrade process, your `PostgresCluster` custom resource **MUST** include the following:
78+
79+
1\. A `volumes` data source that points to the PostgreSQL data, PostgreSQL WAL (if applicable) and pgBackRest repository PVCs identified in the `spec.dataSource.volumes` section.
80+
81+
For example, using the `hippo` cluster:
82+
83+
```
84+
spec:
85+
dataSource:
86+
volumes:
87+
pgDataVolume:
88+
pvcName: hippo-jgut
89+
directory: "hippo-jgut"
90+
pgBackRestVolume:
91+
pvcName: hippo-pgbr-repo
92+
directory: "hippo-backrest-shared-repo"
93+
# Only specify external WAL PVC if enabled in PGO v4 cluster. If enabled
94+
# in v4, a WAL volume must be defined for the v5 cluster as well.
95+
# pgWALVolume:
96+
# pvcName: hippo-jgut-wal
97+
```
98+
99+
Please see the [Data Migration]({{< relref "guides/data-migration.md" >}}) section of the [tutorial]({{< relref "tutorial/_index.md" >}}) for more details on how to properly populate this section of the spec when migrating from a PGO v4 cluster.
100+
101+
2\. If you customized Postgres parameters, you will need to ensure they match in the PGO v5 cluster. For more information, please review the tutorial on [customizing a Postgres cluster]({{< relref "tutorial/customize-cluster.md" >}}).
102+
103+
3\. Once the `PostgresCluster` spec is populated according to these guidelines, you can create the `PostgresCluster` custom resource. For example, if the `PostgresCluster` you're creating is a modified version of the [`postgres` example](https://github.com/CrunchyData/postgres-operator-examples/tree/main/kustomize/postgres) in the [PGO examples repo](https://github.com/CrunchyData/postgres-operator-examples), you can run the following command:
104+
105+
```
106+
kubectl apply -k examples/postgrescluster
107+
```
108+
109+
Your upgrade is now complete! You should now remove the `spec.dataSource.volumes` section from your `PostgresCluster`. For more information on how to use PGO v5, we recommend reading through the [PGO v5 tutorial]({{< relref "tutorial/_index.md" >}}).

0 commit comments

Comments
 (0)