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.
Due to an error in a metadata query, MySQL Shell 8.0.27 cannot be used to manage anInnoDB Cluster running MySQL Server 8.0.25. To work around this issue, upgrade MySQL Server to the 8.0.26 or 8.0.27 release on the InnoDB Cluster member instances before using MySQL Shell 8.0.27 with the cluster. The issue will be fixed in MySQL Shell 8.0.28.
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
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 use.