本文档假定您使用的是运行最新版本的 MySQL 8 和 MySQL Shell 8 的 MySQL 实例。AdminAPI 还支持使用运行 MySQL 5.7 的实例,但描述的许多功能需要运行 MySQL 8 的实例。运行 MySQL 的实例存在以下差异5.7:
运行 MySQL 5.7 的实例不支持
SET PERSIST
,因此无法远程或自动配置,这与运行 MySQL 8 的实例不同。相反,在配置 MySQL 5.7 实例时,每次都必须连接到实例并使用该dba.configureLocalInstance()
操作。当实例选项文件在本地可用时,此操作会将设置持久保存到实例选项文件中。请参阅 第 6.2.4 节,“持久设置”。-
运行 MySQL 5.7 的实例不支持自动节点配置,因此在将它们加入集群之前,您必须手动将它们与其他集群实例同步。这意味着要么依赖 Group Replication 的分布式恢复,这需要启用 GTID 的二进制日志,并且当有大量事务需要恢复时可能需要等待很长时间,要么使用 MySQL Enterprise Backup 等工具手动复制数据。
通过在 8.0 版中添加 MySQL Clone 插件,实例可以由 AdminAPI 自动配置。当您添加支持 MySQL Clone 的 8.0 版实例时,AdminAPI 会自动选择最佳方式使加入的实例与现有实例同步。例如,如果集群包含大量事务,则使用 MySQL Clone 直接恢复数据,然后使用分布式恢复同步集群在克隆操作期间处理的任何事务。您可以直接从 MySQL Shell 监控操作的进度,不需要其他工具。这使得添加实例以扩展 InnoDB 集群和提高高可用性的机会等任务变得毫不费力。有关详细信息,请参阅 第 7.4.6 节,“将 MySQL 克隆与 InnoDB Cluster 一起使用”。
运行 MySQL 5.7 的实例与 InnoDB ReplicaSet 不兼容。
运行 MySQL 5.7 的实例与 InnoDB ClusterSet 不兼容。
使用 MySQL 5.7 服务器时,无法动态更改 InnoDB 集群拓扑(无论是在单主模式还是多主模式下运行)。有关详细信息,请参阅更改集群的拓扑结构。
运行 MySQL 5.7 的实例与并行复制应用程序不兼容。有关详细信息,请参阅 第 7.5.6 节,“配置并行复制应用程序”。
运行 MySQL 5.7 的实例不支持
autoRejoinTries
和exitStateAction
选项,这些选项配置实例尝试重新加入集群的次数以及实例离开时发生的情况。有关详细信息,请参阅 第 7.5.5 节,“配置实例的自动重新加入”。运行 MySQL 5.7 的实例不支持该
consistency
选项。有关详细信息,请参阅 第 7.5.4 节,“配置故障转移一致性”。运行 MySQL 5.7 的实例不支持该
expelTimeout
选项,该选项配置集群在驱逐与其他实例失去联系的实例之前等待多长时间。
要使用这些功能,请将您的实例升级到 MySQL 8。
对于运行 MySQL 5.7 的实例,请确保
dba.configureInstance()
在将实例添加到集群之前使用以保留配置更改。对于 MySQL 5.7 上的非沙盒服务器实例(您手动配置而不是使用
的实例dba.deploySandboxInstance()
),如果您不使用该dba.configureInstance()
操作,则 MySQL Shell 无法在实例的配置文件中保留任何 InnoDB ClusterSet 配置更改。这会导致以下一种或两种情况:
Group Replication 配置在实例的配置文件中不持久,并且在重新启动时,实例不会重新加入集群。
该实例对于集群使用无效。尽管可以使用 验证实例
dba.checkInstanceConfiguration()
,并且 MySQL Shell 会进行所需的配置更改以使实例为集群使用做好准备,但这些更改不会保留在配置文件中,因此一旦重新启动就会丢失。
如果这两种情况都发生,则无法使用该
dba.rebootClusterFromCompleteOutage()
操作使集群重新联机。这是因为如果没有该dba.configureInstance()
操作,实例将丢失 MySQL Shell 所做的任何配置更改,并且由于它们未持久化,实例将恢复到为集群配置之前的先前状态。这会导致 Group Replication 停止响应,最终命令超时。