6.2.1 Using Instances Running MySQL 5.7

This documentation assumes you are using MySQL instances running the latest version of MySQL 8, and MySQL Shell 8. AdminAPI also supports using instances running MySQL 5.7, but many of the features described require instances running MySQL 8. The following differences exist for instances running MySQL 5.7:

Instances running MySQL 5.7 do not support SET PERSIST, so they cannot be configured remotely, or automatically, unlike instances running MySQL 8. Instead, when configuring MySQL 5.7 instances, each time you must connect to the instance and use the dba.configureLocalInstance() operation. This operation persists the settings to the instances option file when it is available locally. See Section 6.2.4, “Persisting Settings”.
Instances running MySQL 5.7 do not support automatic node provisioning, so before joining them to the cluster, you must manually synchronize them with the other cluster instances. This means either relying on Group Replication's distributed recovery, which requires binary logs with GTIDs enabled and potentially a long wait when there is a large number of transactions to recover, or using a tool such as MySQL Enterprise Backup to manually copy the data.
With the addition of the MySQL Clone plugin in version 8.0, instances can be provisioned by AdminAPI automatically. When you add a version 8.0 instance supporting MySQL Clone, AdminAPI automatically chooses the best way to bring the joining instance into synchrony with the existing instances. For example, if the cluster contains a large number of transactions, MySQL Clone is used to recover the data directly, and any transactions processed by the cluster during the clone operation are then synchronized using distributed recovery. You can monitor the progress of the operation directly from MySQL Shell, no other tools are required. This makes tasks such as adding instances to expand the InnoDB Cluster and improve the chances of high availability effortless. For more information, see Section 7.4.6, “Using MySQL Clone with InnoDB Cluster”.
Instances running MySQL 5.7 are not compatible with InnoDB ReplicaSet.
Instances running MySQL 5.7 are not compatible with InnoDB ClusterSet.
The InnoDB Cluster topology (whether it is running in single-primary or multi-primary mode) cannot be dynamically changed when using MySQL 5.7 Servers. For more information, see Changing a Cluster's Topology.
Instances running MySQL 5.7 are not compatible with the parallel replication applier. For more information see Section 7.5.6, “Configuring the Parallel Replication Applier”.
Instances running MySQL 5.7 do not support the autoRejoinTries and exitStateAction options, which configure how many times instances try to rejoin a cluster and what happens when an instance leaves. For more information, see Section 7.5.5, “Configuring Automatic Rejoin of Instances”.
Instances running MySQL 5.7 do not support the consistency option. For more information, see Section 7.5.4, “Configuring Failover Consistency”.
Instances running MySQL 5.7 do not support the expelTimeout option, which configures how long the cluster waits before expelling an instance which has lost contact with the other instances.

To use these features, please upgrade your instances to MySQL 8.

With instances running MySQL 5.7, ensure that you use dba.configureInstance() before adding the instances to a cluster to persist the configuration changes. For non-sandbox server instances on MySQL 5.7 (instances which you have configured manually rather than using dba.deploySandboxInstance()), if you do not use the dba.configureInstance() operation, MySQL Shell can not persist anyInnoDB ClusterSet configuration changes in the instance's configuration file. This leads to one or both of the following scenarios:

The Group Replication configuration is not persistent in the instance's configuration file, and upon restart, the instance does not rejoin the cluster.
The instance is not valid for cluster usage. Although the instance can be verified with dba.checkInstanceConfiguration(), and MySQL Shell makes the required configuration changes in order to make the instance ready for cluster usage, those changes are not persisted in the configuration file and so are lost once a restart happens.

If both situations happen, you cannot use the dba.rebootClusterFromCompleteOutage() operation to get the cluster back online. This is because without the dba.configureInstance() operation, the instance loses any configuration changes made by MySQL Shell, and because they were not persisted, the instance reverts to the previous state before being configured for the cluster. This causes Group Replication to stop responding, and eventually the command times out.