中文
devexamples
← Workflows

阅读中文版本

Database Upgrade and Rollback Workflow

Plan a major version upgrade with a rehearsal, extension and replication checks, a tested rollback, and a defined cutover and revert window.

advanced~240 mindatabasesupgradeoperations

Objective

Upgrade a database major version with a rehearsed, reversible plan instead of an untested leap.

Environment

  • A staging copy of production data
  • A tested backup and restore procedure

Steps

1. Inventory extensions, drivers, and features

Inventory extensions, drivers, and features that may change behavior.

Expected state: Known incompatibilities are surfaced early.

2. Rehearse the upgrade on a production-like

Rehearse the upgrade on a production-like copy and measure downtime.

Expected state: The real cost is known before the event.

3. Verify backups restore and define

Verify backups restore and define the exact rollback steps and deadline.

Expected state: A revert path exists and is tested.

4. Cut over in a window, verify,

Cut over in a window, verify, and revert if the checks fail.

Expected state: The upgrade either succeeds or reverts cleanly.

Decision points

In-place upgrade or logical replication cutover?

  • Logical replication
  • In-place

Logical replication reduces downtime for large databases but adds a cutover step.

How long a revert window?

  • One release cycle
  • Until confident

Keep the old version until at least one full backup cycle and a stable period pass.

Expected outcome

The database runs the new major version with verified behavior, or a tested rollback restores the previous version within the window.

Verification

Confirm application test suites pass against the upgraded database, replication is healthy, and a restore rehearsal completed successfully.

Cleanup

Remove the old version binaries after the revert window closes and update runbooks.

Overview

Upgrade a database major version with a rehearsed, reversible plan instead of an untested leap. Confirm application test suites pass against the upgraded database, replication is healthy, and a restore rehearsal completed successfully.

Steps

  1. Inventory extensions, drivers, and features that may change behavior. Expected state: Known incompatibilities are surfaced early.
  2. Rehearse the upgrade on a production-like copy and measure downtime. Expected state: The real cost is known before the event.
  3. Verify backups restore and define the exact rollback steps and deadline. Expected state: A revert path exists and is tested.
  4. Cut over in a window, verify, and revert if the checks fail. Expected state: The upgrade either succeeds or reverts cleanly.
pg_upgrade --old-datadir /var/lib/pg/15 --new-datadir /var/lib/pg/16 --link
# rehearsal first; keep pg 15 installed for the revert window

Verification

  • The database runs the new major version with verified behavior, or a tested rollback restores the previous version within the window.

Decision points

  • In-place upgrade or logical replication cutover? Options: Logical replication; In-place. Recommended: Logical replication reduces downtime for large databases but adds a cutover step.
  • How long a revert window? Options: One release cycle; Until confident. Recommended: Keep the old version until at least one full backup cycle and a stable period pass.