7.10 Upgrade InnoDB Cluster

7.10.1 InnoDB Cluster Upgrade

7.10.2 Troubleshooting InnoDB Cluster Upgrades

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.

Important

Due to an error in a metadata query, MySQL Shell 8.0.27 cannot be used to manage an InnoDB 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) and it discovers the metadata version is 0.0.0 (upgrade in progress), then 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.