直接 kill -9 容器会导致 mysql 数据损坏，因跳过刷盘、binlog 对齐与崩溃恢复准备；docker stop 默认10秒超时易触发sigkill，须设-t 60+并验证日志末尾出现“shutdown complete”。
直接 kill -9 容器会导致 MySQL 数据损坏
MySQL 8.0 在容器中运行时，docker stop 默认发送 SIGTERM，它会触发 MySQL 正常关闭流程（刷盘、写 binlog、关闭连接等）。但如果你用 docker kill -9 或容器被强制终止（如 OOM Kill），MySQL 没机会执行 shutdown hook，ib_logfile0 和 ibdata1 可能处于不一致状态，下次启动大概率报 InnoDB: Database page corruption 或卡在 recovery 阶段。
docker stop 的超时时间必须大于 MySQL 关闭耗时
MySQL 8.0 在有大量未刷盘事务或大 buffer pool 时，正常 shutdown 可能长达 30–60 秒。而 docker stop 默认只等 10 秒，超时后自动发 SIGKILL —— 这就等于人为制造强制终止。
- 务必显式指定
--time（或-t）参数，例如：docker stop -t 60 mysql8 - 若你挂载了大容量数据卷（如 >50GB），建议设为
-t 120 - 可通过
docker inspect mysql8 | grep -i stop确认当前容器的 StopTimeout 值
重启前检查 MySQL 是否真正 clean shutdown
容器退出后不能只看 docker ps -a 显示 Exited (0) 就认为安全。MySQL 内部可能已崩溃但进程退出码碰巧是 0（尤其某些信号处理异常时）。
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 重启前先查日志：
docker logs mysql8 | tail -30，确认末尾有类似mysqld: Shutdown complete或mysqld: ready for connections - 若看到
Aborted connection大量堆积、InnoDB: Starting crash recovery或Waiting for server socket卡住，说明上一次 shutdown 不完整，应先docker start mysql8并观察日志是否恢复成功，再决定是否重建容器 - 生产环境建议加健康检查：
--health-cmd="mysqladmin ping -u root -p\${MYSQL_ROOT_PASSWORD} --silent" --health-interval=30s，避免调度器在 MySQL 未就绪时就认为服务可用
用 docker restart 不等于平滑重启
docker restart 是 stop + start 的组合，但它复用原有容器配置，不会重新加载挂载的配置文件（如 /etc/mysql/conf.d/*.cnf）。如果你改了 my.cnf 但只执行 docker restart，MySQL 实际仍按旧配置运行。
- 修改配置后，必须
docker stop→ 手动验证配置语法（docker run --rm -v $(pwd)/conf:/etc/mysql/conf.d mysql:8.0 mysqld --defaults-file=/etc/mysql/my.cnf --verbose --help | head -5）→docker rm mysql8→docker run ...重建容器 - 如果只是想 reload runtime 参数（如
max_connections），进容器执行mysql -uroot -p -e "SET GLOBAL max_connections = 500;"更快，且不影响连接 - 注意：
docker restart会重置容器的 uptime 和 network namespace，已有长连接会被断开，这不是“零停机”
真正优雅的停止与重启，核心不在命令多炫酷，而在理解 MySQL 的 shutdown 语义和 Docker 的信号传递边界。最容易被忽略的是：MySQL 容器退出码为 0 ≠ 数据已持久化完毕 —— 日志末尾那句 Shutdown complete 才是唯一可信信号。
