Upgrade the Cluster

This document describes the upgrade methods for SynxDB and how to choose one based on the changes between versions. For the changes in each version, see the release notes of that version.

Compatibility

  • Minor versions (for example, 4.x): Maintains on-disk data and server-side application binary interface (ABI) compatibility.

  • Major versions (for example, 4.x to 5.0): A major version introduces breaking changes and requires a full redeployment and data migration.

Upgrade methods

  • Binary replacement upgrade (for example, 4.x to 4.y): For non-breaking updates (no storage, catalog, or ABI changes). Install the new binaries and perform rolling restarts where supported. Rollback is available.

  • Redeployment and data migration (for example, 4.x to 5.0): For breaking changes affecting storage, catalog, ABI, or runtime. Provision a new cluster, migrate data (through export/import or logical replication), validate it, and then switch your applications to it.

Quick guide

  • Security, bug fix, performance, or feature updates without format/ABI change: Use a binary replacement upgrade.

  • Catalog version change only: Use gpupgrade.

  • Storage, ABI, or runtime baseline changes: Use redeployment and data migration.

Validate before the upgrade

Before you upgrade a production cluster, complete the following validation:

  • Back up the data: Take a full backup before the upgrade, and confirm that you can restore from it.

  • Rehearse in a test environment: In a test environment with the same topology as the production cluster, run the complete upgrade with data similar to the production data. Record the duration of each stage to plan the downtime window.

  • Validate application functions: On the rehearsed cluster, run the main application queries and jobs, and confirm that the results are correct and the performance meets expectations.