This section explains how to upgrade your cluster. Much of the process of upgrading an InnoDB Cluster consists of upgrading the instances in the same way as documented at Section 18.7, “Upgrading Group Replication”. This section focuses on the additional considerations for upgrading InnoDB Cluster. Before starting an upgrade, you can use the MySQL Shell Upgrade Checker Utility to verify instances are ready for the upgrade.
From version 8.0.19, if you try to bootstrap MySQL Router against a cluster and it discovers that the metadata version is 0.0.0, this indicates that a metadata upgrade is in progress, and the bootstrap fails. Wait for the metadata upgrade to complete before you try to bootstrap again. When MySQL Router is operating normally (not bootstrapping), if it discovers the metadata version is 0.0.0 (upgrade in progress) it does not proceed with the metadata refresh it was about to begin. Instead, MySQL Router continues using the last metadata it has cached. All the existing user connections are maintained, and any new connections are routed according to the cached metadata. The Metadata refresh restarts when the Metadata version is no longer 0.0.0. In the regular (not bootstrapping) mode, MySQL Router works with both version 1.x.x and 2.x.x. metadata, and the version can change between TTL refreshes. This ensures routing continues while the cluster is upgraded.
Although it is possible to have instances in a cluster which run
multiple MySQL versions, for example version 5.7 and 8.0, such a
mix is not recommended for prolonged use. For example, in a
cluster using a mix of versions, if an instance running version
5.7 leaves the cluster and then MySQL Clone is used for a
recovery operation, the instance running the lower version can
no longer join the cluster because the
BACKUP_ADMIN privilege becomes a
requirement. Running a cluster with multiple versions is
intended as a temporary situation to aid in migration from one
version to another, and should not be relied on for long term