【随笔】MySQL 启动失败分析：权限问题与 expire_logs_days 配置错误

在使用 MySQL 时，遇到启动失败是常见的情况。在这篇博客中，我们将分析一例 MySQL 启动失败的日志，并总结导致 MySQL 启动失败的两个关键问题：配置文件权限问题和 expire_logs_days 配置项不支持的问题。

问题分析

通过查看 MySQL 启动日志，发现了两个主要的问题：

1. 权限问题导致配置文件被忽略

日志中的一项警告提示：

mysqld: [Warning] World-writable config file '/etc/mysql/conf.d/mysql.cnf' is ignored.

这表示 MySQL 在启动时忽略了 /etc/mysql/conf.d/mysql.cnf 配置文件，原因是该文件权限设置为“世界可写”。MySQL 会忽略任何具有全局写权限的配置文件，出于安全考虑，避免其他用户修改配置文件。

2. expire_logs_days 配置项版本错误

另一个关键错误是：

[ERROR] [MY-000067] [Server] unknown variable 'expire_logs_days=7'.

这表明 MySQL 配置文件中存在一个被 MySQL 8.x 版本移除的配置项 expire_logs_days，该项已不再被支持，导致 MySQL 启动失败。

解决方法

1. 解决配置文件权限问题

MySQL 会忽略具有全局写权限的配置文件，因此我们需要修改 mysql.cnf 配置文件的权限，确保它不对所有用户可写。可以通过以下命令修改文件权限：

chmod 644 /etc/mysql/conf.d/mysql.cnf

这样，配置文件的权限将更为安全，MySQL 就能够正常加载该配置文件。

2. 处理 expire_logs_days 配置项错误

expire_logs_days 配置项在 MySQL 8.x 中已经被移除。因此，我们需要在配置文件中移除该配置项，并用新的配置项 binlog_expire_logs_seconds 代替它。新的配置项设置为日志过期时间（单位为秒）。

修改后的配置应该如下所示：

# 删除或注释掉以下配置
# expire_logs_days = 7

# 使用新的配置项代替
binlog_expire_logs_seconds = 604800  # 7 天 = 7 * 24 * 60 * 60 秒

完成配置后，保存文件并重新启动 MySQL。

docker restart <container_name>

其他警告

日志中还包含一些警告信息：

• binlog_format 已弃用：该配置项将在未来版本中被移除。需要检查是否可以替换或去除该配置项。
• innodb_log_file_size 和 innodb_log_files_in_group 配置已弃用：这些参数不再推荐使用，建议改用 innodb_redo_log_capacity 来替代。

虽然这些警告不会立即导致 MySQL 启动失败，但它们提示我们应当关注这些即将弃用的配置项，并考虑逐步替换为新的支持项。

总结

通过分析 MySQL 启动日志，我们发现了两个常见的启动失败原因：

1. 配置文件权限问题：需要确保配置文件的权限设置合理，避免 MySQL 忽略配置文件。
2. expire_logs_days 配置项错误：MySQL 8.x 已不再支持 expire_logs_days，我们需要使用新的配置项 binlog_expire_logs_seconds 来替代。

通过及时解决这些问题，MySQL 可以顺利启动并运行。在实际生产环境中，定期检查 MySQL 配置文件，避免使用已弃用的配置项，可以有效避免类似问题的发生。

希望这篇博客能帮助你解决类似的 MySQL 启动问题。如果你遇到其他问题或有更多疑问，欢迎在评论区留言。