在 MySQL 8 中,二进制日志会自动清除(由 binlog_expire_logs_seconds
定义)。这意味着运行时间超过 binlog_expire_logs_seconds
的集群最终可能不会包含具有完整二进制日志的实例,该日志包含实例应用的所有事务。这可能导致需要自动配置实例(例如使用 MySQL Enterprise Backup),然后才能加入集群。运行 8.0.17 及更高版本的实例支持 MySQL Clone 插件,该插件通过提供不依赖于增量恢复的自动配置解决方案来解决此问题,请参见 第 7.4.6 节,“将 MySQL Clone 与 InnoDB 集群一起使用”。运行早于 8.0.17 版本的实例仅支持增量恢复,结果是,根据实例运行的 MySQL 版本,可能必须自动配置实例。否则,依赖于分布式恢复的操作(例如
等)可能会失败。Cluster
.addInstance()
在运行早期版本 MySQL 的实例上,以下规则用于清除二进制日志
运行早于 8.0.1 版本的实例没有自动清除二进制日志,因为
expire_logs_days
的默认值为 0。运行 8.0.1 到 8.0.4 之间版本的实例会在 30 天后清除二进制日志,因为
expire_logs_days
的默认值为 30。运行 8.0.10 以后版本的实例会在 30 天后清除二进制日志,因为
binlog_expire_logs_seconds
的默认值为 2592000,而expire_logs_days
的默认值为 0。
MySQL Server 8.2.0 中删除了 expire_logs_days
。
因此,根据集群运行时间,二进制日志可能已被清除,您可能必须手动配置实例。同样,如果您手动清除二进制日志,则可能会遇到相同的情况。因此,强烈建议您升级到 8.0.17 以后版本的 MySQL,以充分利用 MySQL Clone 为分布式恢复提供的自动配置,并在为 InnoDB 集群配置实例时最大程度地减少停机时间。