MySQL Shell 9.0  /  ...  /  InnoDB 集群和二进制日志清除

7.5.8 InnoDB 集群和二进制日志清除

在 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。

注意

expire_logs_days 在 MySQL Server 8.2.0 中被移除。

因此,根据集群运行的时间长短,二进制日志可能已被清除,您可能需要手动预配实例。同样,如果您手动清除了二进制日志,您可能会遇到相同的情况。因此,强烈建议您升级到高于 8.0.17 版本的 MySQL,以充分利用 MySQL Clone 为分布式恢复提供的自动预配功能,并在为 InnoDB 集群预配实例时最大限度地减少停机时间。