今天中午发现服务器磁盘又快满了。按目录顺序排查了一遍，发现是 MySQL 的 binlog 文件占用了大量空间。之前通过 mysql console 设置的 binlog_expire_logs_seconds 参数（限制保持3天）在重启 mysql docker 容器后就失效了。参考前文 设置 MySQL binlog 保存天数，节省服务器硬盘空间。
好在今天的开发任务基本完成，也上线测试通过。所以就有时间来折腾一下 docker 中的 MySQL 配置了。以前是能不动就不动，主要是不太想过多了解 docker 的细节，感觉太浪费生命。但是，在自动化运维上，没搞定一项配置，就能节省以后的重复劳动，还是很有必要的。毕竟 AI 虽然可以写代码，但是我并不敢让 OpenClaw 这类神兽去线上服务器操作，还是得自己来。
使用配置文件（最推荐，易于维护）
首先我问了一下 Gemini，这是她最推荐的方式。即，创建一个自定义的配置文件，并将其挂载到容器中。在宿主机创建一个文件，例如 mysql.cnf:
[mysqld]
binlog_expire_logs_seconds=259200
259200 秒代表 3 天。在 docker-compose.yml 中挂载该文件：
services:
mysql:
image: mysql:8.0
volumes:
- ./mysql.cnf:/etc/mysql/conf.d/mysql.cnf
注：MySQL 会自动读取 /etc/mysql/conf.d/ 目录下所有以 .cnf 结尾的文件。
docker volumes 可以设置单个文件么
可以的。即支持挂载单个文件，也支持挂载整个目录。
确认 docker 中的 /etc/mysql/conf.d/ 目录是否存在
docker compose exec mysql bash
# ls /etc/mysql/
conf.d
# ls /etc/mysql/conf.d/
容器内 /etc/mysql/conf.d/ 目录存在，但是没有任何配置文件。
查看 /etc/my.cnf 文件内容，确认是否包含以下行：
!includedir /etc/mysql/conf.d/
通常在最后一行。
使新配置生效
docker compose up -d mysql
自动停止、删除旧容器，并根据新配置启动新容器。
如果只修改了宿主机上被挂载的文件内容，MySQL 通常需要重启才能读取新配置，但此时你执行 docker restart
执行速度很快，感觉嗖的一下就重启好了。
心惊胆颤地检查了一下网站是否正常，以及配置是否生效，结果一切正常，binlog_expire_logs_seconds 的值也正确了。没用的 docker 知识又增加了😓
关于作者 🌱
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊，或者关注我的个人公众号“大象工具”， 查看更多联系方式