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 Upgrading Group Replication. This section focuses on the additional considerations for upgrading InnoDB Cluster. Before starting an upgrade, you can use the MySQL Shell Section 11.1, “Upgrade Checker Utility” to verify instances are ready for the upgrade.
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) and it discovers the metadata version is 0.0.0 (upgrade in progress), MySQL Router does not proceed with refreshing the metadata that 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 the metadata of version 1.x.x and 2.x.x. The version can change between TTL refreshes. This change ensures routing continues while you upgrade the cluster.
Although it is possible to have instances in a cluster that 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 different versions, 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 is not suitable for long term use.