Skip to content

Files

Latest commit

 

History

History
163 lines (131 loc) · 7.38 KB

upgrading-postgresql.adoc

File metadata and controls

163 lines (131 loc) · 7.38 KB

Updating {productname} and the {productname} and Clair PostgreSQL databases on {ocp}

Important

If your {productname} deployment is upgrading from one y-stream to the next, for example, from 3.8.10 → 3.8.11, you must not switch the upgrade channel from stable-3.8 to stable-3.9. Changing the upgrade channel in the middle of a y-stream upgrade will disallow {productname} from upgrading to 3.9. This is a known issue and will be fixed in a future version of {productname}.

When updating {productname} 3.8 → 3.9, the Operator automatically upgrades the existing PostgreSQL databases for Clair and {productname} from version 10 to version 13.

Important

  • Users with a managed database are required to upgrade their PostgreSQL database from 10 → 13.

  • If your {productname} and Clair databases are managed by the Operator, the database upgrades for each component must succeed for the 3.9.0 upgrade to be successful. If either of the database upgrades fail, the entire {productname} version upgrade fails. This behavior is expected.

You can update {productname} and the {productname} and Clair PostgreSQL databases on {ocp} by using the Web Console UI, or by using the CLI.

Updating {productname} and the {productname} and Clair PostgreSQL databases using the {ocp} web console

Use the following procedure to update {productname} and the {productname} and Clair PostgreSQL databases using the {ocp} web console.

Important

  • This upgrade is irreversible. It is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the PostgreSQL Versioning Policy.

  • If your {productname} and Clair databases are managed by the Operator, the database upgrades for each component must succeed for the 3.9.0 upgrade to be successful. If either of the database upgrades fail, the entire {productname} version upgrade fails. This behavior is expected.

  • By default, {productname} is configured to save old persistent volume claims (PVCs) from PostgreSQL 10. To disable this setting and remove old PVCs, you must set POSTGRES_UPGRADE_DELETE_BACKUP to True in your quay-operator Subscription object.
Prerequisites

  • You have installed {productname} 3.6, 3.7, or 3.8 on {ocp}.

  • 100 GB of free, additional storage.

    During the upgrade process, additional persistent volume claims (PVCs) are provisioned to store the migrated data. This helps prevent a destructive operation on user data. The upgrade process rolls out PVCs for 50 GB for both the {productname} database upgrade, and the Clair database upgrade.

Procedure

  1. Optional. Back up your old PVCs from PostgreSQL 10 by setting POSTGRES_UPGRADE_DELETE_BACKUP to false your quay-operator Subscription object. For example:

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: quay-operator
  namespace: quay-enterprise
spec:
  channel: stable-3.8
  name: quay-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: POSTGRES_UPGRADE_DELETE_BACKUP (1)
      value: "false"

    1. When set to true, removes old PVCs after upgrading.

  2. In the {ocp} Web Console, navigate to Operators → Installed Operators.

  3. Click on the {productname} Operator.

  4. Navigate to the Subscription tab.

  5. Under Subscription details click Update channel.

  6. Select stable-3.9 and save the changes.

  7. Check the progress of the new installation under Upgrade status. Wait until the upgrade status changes to 1 installed before proceeding.

  8. In your {ocp} cluster, navigate to Workloads → Pods. Existing pods should be terminated, or in the process of being terminated.

  9. Wait for the following pods, which are responsible for upgrading the database and alembic migration of existing data, to spin up: clair-postgres-upgrade, quay-postgres-upgrade, and quay-app-upgrade.

  10. After the clair-postgres-upgrade, quay-postgres-upgrade, and quay-app-upgrade pods are marked as Completed, the remaining pods for your {productname} deployment spin up. This takes approximately ten minutes.

  11. Verify that the quay-database uses the postgresql-13 image and clair-postgres pods now use the postgresql-15 image.

  12. After the quay-app pod is marked as Running, you can reach your {productname} registry.

Updating {productname} and the {productname} and Clair PostgreSQL databases using the CLI

Use the following procedure to update {productname} and the {productname} and Clair PostgreSQL databases using the command-line interface (CLI).

Important

  • This upgrade is irreversible. It is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the PostgreSQL Versioning Policy.

  • By default, {productname} is configured to save old persistent volume claims (PVCs) from PostgreSQL 10. To disable this setting and remove old PVCs, you must set POSTGRES_UPGRADE_DELETE_BACKUP to True in your quay-operator Subscription object.
Prerequisites

  • You have installed {productname} 3.6, 3.7, or 3.8 on {ocp}.

  • 100 GB of free, additional storage.

    During the upgrade process, additional persistent volume claims (PVCs) are provisioned to store the migrated data. This helps prevent a destructive operation on user data. The upgrade process rolls out PVCs for 50 GB for both the {productname} database upgrade, and the Clair database upgrade.

Procedure

  1. Retrieve your quay-operator configuration file by entering the following oc get command:

    $ oc get subscription quay-operator -n quay-enterprise -o yaml > quay-operator.yaml

  2. Retrieve the latest version of the {productname} Operator and its channel by entering the following command:

    oc get packagemanifests quay-operator \
  -o jsonpath='{range .status.channels[*]}{@.currentCSV} {@.name}{"\n"}{end}' \
  | awk '{print "STARTING_CSV=" $1 " CHANNEL=" $2 }' \
  | sort -nr \
  | head -1
    Example output
    STARTING_CSV=quay-operator.v3.9.0 CHANNEL=stable-3.9

  3. Using the output from the previous command, update your Subscription custom resource for the {productname} Operator and save it as quay-operator.yaml. For example:

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: quay-operator
  namespace: quay-enterprise
spec:
  channel: stable-3.9 (1)
  name: quay-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: POSTGRES_UPGRADE_DELETE_BACKUP (2)
      value: "false"

    1. Specify the value you obtained in the previous step for the spec.channel parameter.

    2. Optional. Back up your old PVCs from PostgreSQL 10 by setting POSTGRES_UPGRADE_DELETE_BACKUP to false your quay-operator Subscription object.

  4. Enter the following command to apply the configuration:

    $ oc apply -f quay-operator.yaml
    Example output
    subscription.operators.coreos.com/quay-operator created