Documentation Home
MySQL 8.0 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 40.3Mb
PDF (A4) - 40.4Mb
PDF (RPM) - 39.9Mb
HTML Download (TGZ) - 10.6Mb
HTML Download (Zip) - 10.6Mb
HTML Download (RPM) - 9.2Mb
Man Pages (TGZ) - 241.2Kb
Man Pages (Zip) - 346.4Kb
Info (Gzip) - 3.9Mb
Info (Zip) - 3.9Mb
Excerpts from this Manual

MySQL 8.0 Reference Manual  /  ...  /  Upgrading an InnoDB Cluster

21.2.8 Upgrading an InnoDB Cluster

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 use.