This section describes the known limitations of InnoDB cluster. As InnoDB cluster uses Group Replication, you should also be aware of its limitations - see Section 18.7.2, “Group Replication Limitations”.
The formatting of results which contain multi-byte characters sometimes do not have correctly aligned columns. Similarly, non-standard character sets are being corrupted in results.
AdminAPI does not support Unix socket connections. MySQL Shell currently does not prevent you from attempting to use socket connections to a cluster, and attempting to use a socket connection to a cluster can cause unexpected results.
The MySQL Shell help describes an invalid URI:
This is invalid because the
@symbol can not be present if no user information is provided.
Whenever MySQL Shell is started using a connection command parameter such as
--port, and so on, MySQL Shell attempts to create a connection using default values for parameters that have not been specified. If you use the
--socketcommand parameter MySQL Shell should attempt to create a socket connection using the default values for host and user, but it does not.
If a session type is not specified when creating the global session, MySQL Shell provides automatic protocol detection which attempts to first create a NodeSession and if that fails it tries to create a ClassicSession. With an InnoDB cluster that consists of three server instances, where there is one read-write port and two read-only ports, this can cause MySQL Shell to only connect to one of the read-only instances. Therefore it is recommended to always specify the session type when creating the global session.
When adding non-sandbox server instances (instances which you have configured manually rather than using
dba.deploySandboxInstance()) to a cluster, MySQL Shell is not able to persist any configuration changes in the instance's configuration file. This leads to one or both of the following scenarios:
The Group Replication configuration is not persisted 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.
1happens, the instance does not rejoin the cluster after a restart.
2also happens, and you observe that the instance did not rejoin the cluster after a restart, you cannot use the recommended
dba.rebootClusterFromCompleteOutage()in this situation to get the cluster back online. This is because 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.
To avoid this problem it is strongly recommended to use
dba.configureLocalInstance()before adding instances to a cluster in order to persist the configuration changes.
dba.deploySandboxInstance(), server instances are configured with random 32-bit unsigned integers for the
server-idsystem variable. The value of
server-idis also used as the default for the
auto_increment_offsetsystem variable, which determines the starting point for AUTO_INCREMENT. Group Replication has its own increment mechanism and uses
group_replication_auto_increment_incrementwhich defaults to 7 (the maximum group size). This is used to configure the value of
auto_increment_increment. This can result in server instances configured with values such as:
auto_increment_offset = 214748366 (max 32-bit integer value - 1) auto_increment_increment = 7
When the next record is inserted: 214748366 + 7 this can result in overflow. Similarly a collision can occur between numbers generated by different servers in the same cluster.
Using MySQL server instances configured with the validate_password plugin and password policy set to
STRONGcauses InnoDB cluster
createCluster()and MySQL Router bootstrap operations to fail. This is because the internal user required for access to the server instance can not be validated.
The MySQL Router
--bootstrapcommand line option does not accept IPv6 addresses.
The commercial version of MySQL Router does not have the correct setting for AppArmor. A work around is to edit the AppArmor profile configuration file
/etc/apparmor.d/usr.sbin.mysqlrouterand modify the line containing
/usr/sbin/mysqldto use the path to MySQL Router, for example