Docker部署MySQL启动失败：目录占用与线程创建错误排查

1. 为何Docker提示/var/lib/mysql/目录存在文件？这些文件是什么？ #

MySQL官方镜像默认将/var/lib/mysql作为数据存储目录，即便你没有手动挂载本地卷或命名卷，Docker也会自动创建匿名卷来持久化该目录的数据。第一次启动失败后，这个匿名卷中已经生成了MySQL初始化过程中创建的系统数据库文件（如mysql、information_schema等核心库文件）、日志文件及临时文件。当你再次启动容器时，MySQL检测到该目录非空，就会抛出目录存在文件的错误——这是MySQL的保护机制，防止意外覆盖已有数据。

2. 为何无法创建线程处理bootstrap？ #

这个错误最常见的原因是容器内/var/lib/mysql目录的权限异常：

• 你自定义的Dockerfile修改了系统locale，可能间接导致/var/lib/mysql目录的所有者/组发生变化，而MySQL进程默认使用mysql用户（UID=999）运行，该用户没有目录的读写权限，无法创建初始化线程。
• 其次可能是宿主机的安全限制（如SELinux、AppArmor）阻止了容器进程创建线程；或者宿主机内存不足，无法为MySQL分配线程所需的资源。

3. 该如何解决此问题？ #

按以下步骤操作：

• 彻底清理残留资源：执行docker compose down -v，这个命令会彻底停止并删除容器，同时删除关联的匿名卷（比docker volume prune更精准，不会误删其他卷）。
• 重新构建镜像（避免缓存问题）：执行docker compose build --no-cache，确保使用最新的镜像配置，避免之前的权限缓存影响。
• 调整Dockerfile权限（可选但推荐）：在Dockerfile的最后添加一行，确保/var/lib/mysql目录归mysql用户所有：

  RUN chown -R mysql:mysql /var/lib/mysql
  

• 重新启动服务：执行docker compose up，此时容器会重新初始化/var/lib/mysql目录，权限正确的情况下就能正常启动。
• 如果仍有线程创建问题：
  • 检查宿主机内存是否充足，关闭其他占用内存的进程。
  • 临时关闭SELinux（仅测试用）：执行setenforce 0，若能启动则需配置SELinux规则允许容器操作，或在docker-compose.yml中添加安全选项：

    services:
      mysql:
        # ...其他配置
        security_opt:
          - seccomp:unconfined
    

内容的提问来源于stack exchange，提问作者KansaiRobot