20.5 已知限制

本节描述了 InnoDB 集群的已知限制。由于 InnoDB 集群使用组复制，因此您还应该了解其限制，请参阅第 17.7.2 节“组复制限制”。

• 包含多字节字符的结果格式有时没有正确对齐的列。同样，非标准字符集的结果也被破坏。

• AdminAPI 不支持 Unix 套接字连接。 MySQL Shell 当前不会阻止您尝试使用与群集的套接字连接，而尝试使用与群集的套接字连接会导致意外的结果。

• MySQL Shell 帮助描述了无效的 URI：

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

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

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

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

• 组复制配置不会保留在实例的配置文件中，并且在重新启动后，实例不会重新加入群集。

• 该实例对于群集使用无效。尽管可以使用dba.checkInstanceConfiguration()验证实例，并且 MySQL Shell 进行了必要的配置更改以使实例可用于群集使用，但是这些更改不会保留在配置文件中，因此一旦重新启动就会丢失。

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

如果也发生b，并且您发现实例在重新启动后没有重新加入群集，则在这种情况下，您不能使用推荐的dba.rebootClusterFromCompleteOutage()使群集重新联机。这是因为该实例丢失了 MySQL Shell 所做的任何配置更改，并且由于这些更改未保留，因此在为集群配置之前，该实例将恢复为先前的状态。这将导致组复制停止响应，最终命令超时。

为避免此问题，强烈建议在将实例添加到群集之前使用dba.configureLocalInstance()，以保留配置更改。

• 使用配置了 validate_password 插件和密码策略设置为STRONG的 MySQL 服务器实例会导致 InnoDB 群集createCluster()和 MySQL Router 引导操作失败。这是因为无法验证访问服务器实例所需的内部用户。

• MySQL Router --bootstrap命令行选项不接受 IPv6 地址。

• 商业版 MySQLRouter 的 AppArmor 设置不正确。解决方法是编辑 AppArmor 配置文件配置文件/etc/apparmor.d/usr.sbin.mysqlrouter并修改包含/usr/sbin/mysqld的行以使用 MySQLRouter 的路径，例如/usr/sbin/mysqlrouter。

• 通过dba.createCluster()函数将adoptFromGR选项与dba.createCluster()函数一起使用来创建群集失败，并出现错误，该实例已成为复制组的一部分。这仅在 MySQL Shell 的默认向导模式下发生。一种解决方法是通过使用--no-wizard命令选项启动 mysqlsh 来禁用向导模式。

• InnoDB 群集服务器实例不支持使用--defaults-extra-file选项指定选项文件。 InnoDB 集群仅在实例上支持单个选项文件，不支持其他选项文件。因此，对于使用实例的选项文件进行的任何操作，应指定主要操作。如果要使用多个选项文件，则必须手动配置文件，并考虑到使用多个选项文件的优先规则，并确保它们已正确更新，并确保所需的设置不会被其他无法识别的选项中的选项错误地覆盖。文件。