Previously, tenant upgrades in UA required a user to issue a `SET CLUSTER SETTING version =`
statement to finalize an upgrade. This UX is different from what we have in single-tenant
SH/Dedicated deployments in that we have auto upgrade in the later that starts an attempt
to finalize cluster version after every node startup incase the node was started with a new
binary version that all nodes now support upgrading to.
In UA, we have two differences:
1. What to upgrade?
- In a multi-tenant deployment, the storage and sql layers are upgraded separately.
- The storage layer upgrade finalization is still handled by the existing auto upgrade logic.
- In this change, we ensure that the sql layer is also auto-upgraded when possible.
2. When to upgrade?
- In a single-tenant deployment, all layers share the same binary version and cluster version.
Hence, an upgrade attempt is only needed when a new node starts to ensure that the cluster is
auto-upgraded if the new binary version supports an upgrade.
- In a multi-tenant deployment, in addition to the condition above, the sql server upgrade is
also constrained by the storage cluster version. It is possible for all SQL instances to have
binary versions that support an upgrade but the upgrade will still be blocked by the storage
cluster version if it’s equal to the current tenant cluster version.
This code change does the following:
1. Adds logic to run a SQL server upgrade attempt (mostly adopted from the original auto upgrade code)
within the following ordered constraints (previously we merged cockroachdb#98830 to make getting the binary
versions of instances easier):
- Ensure that the upgrade is not blocked by the secondary tenant's setting of preserve_downgrade_option
or an all-tenant override of that value.
- Exit if tenant cluster version is equal to the minimum instance binary version [upgrade already completed].
- Upgrade to storage cluster version if the binary version of all SQL instances supports that.
- Exit if storage cluster version is less than the minimum instance binary version [upgrade blocked
due to low storage cluster version].
- Upgrade to the minimum instance binary version.
2. Runs the logic above when a SQL server is started.
- This covers the case where a SQL server binary upgrade allows for an upgrade to the
tenant cluster version.
3. Checks for change in storage cluster version every 10 seconds and starts an upgrade attempt if
it was changed.
- This covers the case where the binary versions of all SQL instances allow for an upgrade
but it’s blocked due to the storage cluster version.
Release note: Support for automatic finalization of virtual clusters version
upgrade was added. A new setting `cluster.auto_upgrade.enabled` was added to
enable and disable automatic cluster version upgrade (finalization) and it
will be used with automatic upgrade at both storage-level and virtual cluster
level (each has its own setting value though).
Epic: CRDB-20860