We currently support (and test) zero downtime sequential upgrades from one minor version to the next minor version. For
example, if you’re on version
1.0.0 then you can safely upgrade to
1.1.X without any downtime.
To upgrade, deploy the helm chart with the updated version. The exact steps vary depending on how you use helm—directly, with helmfile, or through a specific CI.
If you want to upgrade more than one minor version (e.g.
1.2.0) and you care about avoiding downtime then
you need to apply minor version upgrades one at a time (e.g. deploy
1.1.0, verify deploy successful, deploy
verify deploy successful, etc.).
If you are ok with downtime and prefer to minimize the number of steps required to upgrade across multiple versions, you can use the following process (note that this only saves you time if you are upgrading 3 or more minor versions at once):
- Using the currently deployed version of the helm chart, enable maintenance mode in
the helm values, and apply it (e.g. deploy
- Verify that the deploy has completed.
- Take a snapshot of the Postgres database, to guard against data loss in case a rollback is necessary.
- Apply the latest version of the helm chart with maintenance mode disabled in the
helm values (e.g. deploy
maintenance: falseor omitted).
It is safe to downgrade to any previous patch version of the same major and minor version with no downtime or dataloss
(e.g. downgrade from
1.1.0). All you need to do is deploy the previous patch version that you want to roll
It is also safe to downgrade one minor version with no downtime. For example, if an instance is on version
you can downgrade back to
1.1.0 using the following process:
- Deploy the version you want to roll back to (e.g.
1.1.0). This is safe to do as a rolling deployment, so that you don't incur downtime.
- Ensure that the rollback has completed and there are no more instances of the newer version (e.g.
- Look up the schema version for the version you have rolled back to in the BSR Release Notes (e.g.
the database schema version for
- Manually run
bufd migrate down-to $VERSIONusing the bufd binary you are rolling back from and the schema version you looked up in the release notes (e.g. with
bufd migrate down-to 222to downgrade to the
⚠ To the extent that new features are released in the BSR in every release, rolling back to a previous version can result in permanent data loss of data changes in the newer release. These could be:
- net-new types of data collected in the release that you are rolling back from
- data removed because of dropped tables or columns in the release you are rolling back to
To minimize potential data loss problems, we recommend never rolling back further than one minor release from the newest
version ever deployed to an instance (e.g. if you have an instance that started at
1.0.0 and you have upgraded it over
1.3.0, we caution against rolling back earlier than