参考官方文档：

https://dev.mysql.com/doc/refman/5.7/en/mysql-innodb-cluster-limitations.html

本节介绍InnoDB集群的已知限制。 由于InnoDB集群使用组复制，您还应该了解组复制的局限性，请参见第17.7.2节“组复制限制”。

• 包含多字节字符的结果格式有时没有正确对齐的列。 同样，非标准字符集在结果中也会被破坏。
• AdminAPI不支持Unix套接字连接。 MySQL Shell目前不会阻止您尝试使用套接字连接到群集，尝试使用套接字连接到群集可能会导致意外结果。
• MySQL Shell帮助描述了无效的URI：
  

USER[:PASS]@::SOCKET[/DB].

这是无效的，因为如果没有提供用户信息，则@符号不能出现。

• 如果在创建全局会话时未指定会话类型，则MySQL Shell会提供自动协议检测，尝试首先创建NodeSession，如果失败则尝试创建ClassicSession。 如果InnoDB集群由三个服务器实例组成，其中有一个读写端口和两个只读端口，这可能导致MySQL Shell仅连接到其中一个只读实例。 因此，建议在创建全局会话时始终指定会话类型。

• 将非sandbox服务器实例（您已手动配置而非使用dba.deploySandboxInstance（）的实例）添加到群集时，MySQL Shell无法在实例的配置文件中保留任何配置更改。 这导致以下一种或两种情况：

• 组复制配置不会保留在实例的配置文件中，重新启动后实例不会重新加入群集。
• 该实例对群集无效。 尽管可以使用dba.checkInstanceConfiguration（）验证实例，并且MySQL Shell进行必要的配置更改以使实例为群集使用做好准备，但这些更改不会在配置文件中保留，因此一旦重新启动就会丢失。
  

如果只 发生a，则重新启动后实例不会重新加入群集。

如果b也发生了，并且您发现实例在重新启动后没有重新加入群集，在这种情况下，您无法使用推荐的dba.rebootClusterFromCompleteOutage（）来使群集重新在线。 这是因为实例丢失了MySQL Shell所做的任何配置更改，并且由于它们没有持久化，因此在为群集配置之前，实例将恢复为先前的状态。 这会导致组复制停止响应，并最终命令超时。

为避免此问题，强烈建议在将实例添加到群集之前使用dba.configureLocalInstance（）以保证配置更改持久化。

• 使用将validate_password插件和密码策略设置为STRONG配置的MySQL服务器实例会导致InnoDB集群createCluster（）和MySQL路由器引导操作失败。 这是因为无法验证访问服务器实例所需的内部用户。
• MySQL路由--bootstrap命令行选项不接受IPv6地址。
• MySQL路由的商业版本没有AppArmor的正确设置。 解决方法是编辑AppArmor配置文件配置文件/etc/apparmor.d/usr.sbin.mysqlrouter并修改包含/usr/sbin/mysqld的行以使用MySQL路由器的路径，例如/usr/sbin/mysqlrouter。
• 使用adoptFromGR选项和dba.createCluster（）函数来创建基于现有部署的组复制的集群失败，并显示实例已经是复制组的一部分的错误。 这只发生在MySQL Shell的默认向导模式中。 解决方法是通过使用--no-wizard命令选项启动mysqlsh来禁用向导模式。
• InnoDB集群服务器实例不支持使用--defaults-extra-file选项指定选项文件。