InnoDB Cluster uses Group Replication and therefore your server instances must meet the same requirements. See Group Replication Requirements. AdminAPI provides the dba.checkInstanceConfiguration() method to verify that an instance meets the Group Replication requirements, and the dba.configureInstance() method to configure an instance to meet the requirements.

Data for use with Group Replication, and therefore also data for use with InnoDB Cluster, must be stored in the InnoDB transactional storage engine. The use of other storage engines, including the temporary MEMORY storage engine, might cause errors in Group Replication. Convert any tables in other storage engines to use InnoDB before using the instance with Group Replication and InnoDB Cluster. You can prevent the use of other storage engines by setting the disabled_storage_engines system variable on server instances, for example:

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

There must be no inbound replication channels on any server instance when you set up the cluster. The channels created automatically by Group Replication (group_replication_applier and group_replication_recovery) are allowed on a replication group that is being adopted. InnoDB Cluster does not support manually configured asynchronous replication channels outside of those that are managed using AdminAPI. If you are migrating an existing replication topology to an InnoDB Cluster deployment and need to skip this validation temporarily during the setup process, you can use the force option when you create the cluster to bypass it.

group_replication_tls_source must not be set to mysql_admin.

The Performance Schema must be enabled on any instance which you want to use with InnoDB Cluster.

The provisioning scripts that MySQL Shell uses to configure servers for use in InnoDB Cluster require access to Python. On Windows MySQL Shell includes Python and no user configuration is required. On Unix Python must be found as part of the shell environment. To check that your system has Python configured correctly issue:

$ /usr/bin/env python

If a Python interpreter starts, no further action is required. If the previous command fails, create a soft link between /usr/bin/python and your chosen Python binary. For more information, see Supported Languages.

From version 8.0.17, instances must use a unique server_id within an InnoDB Cluster. When you use the Cluster.addInstance(instance) operation, if the server_id of instance is already used by an instance in the cluster then the operation fails with an error.

From version 8.0.23, instances should be configured to use the parallel replication applier. See Section 7.5.6, “Configuring the Parallel Replication Applier”.

During the process of configuring an instance for InnoDB Cluster, the majority of the system variables required for using an instance are configured. But AdminAPI does not configure the transaction_isolation system variable, which means that it defaults to REPEATABLE READ. This does not impact a single-primary cluster, but if you are using a multi-primary cluster then unless you rely on REPEATABLE READ semantics in your applications, we recommend using the READ COMMITTED isolation level. See Group Replication Limitations.

The relevant configuration options for the instance, particularly the Group Replication configuration options, must be in a single option file. InnoDB Cluster only supports a single option file for server instances and does not support the use of the --defaults-extra-file option to specify an additional option file. For any AdminAPI operation working with the instance's option file, the main file must be specified. If you want to use multiple option files for configuration options that do not relate to InnoDB Cluster, you must configure the files manually, make sure they are updated correctly considering the precedence rules for the use of multiple option files, and ensure that the settings relating to InnoDB Cluster are not incorrectly overwritten by options in an extra unrecognized option file.