Kubernetes中运行Mysql5.7初始化失败原因

运维笔谈 2025-03-26

“ lost+found 目录导致。”

公司测试环境的Mysql需要从5.6升级到5.7，所以打算先测试下，备份下原来5.6的数据，然后导入新建的Mysql5.7中。

创建好了Mysql5.7的StatefulSet相关yaml文件，运行的时候发现MySQL启动报错了，具体报错如下：

[ERROR] --initialize specified but the data directory has files in it. Aborting.
[ERROR] Aborting

这是提示MySQL在初始化的时候时检测到数据目录中已存在文件。可是这个PV是我刚刚创建初始化的啊，里面不应该有文件的啊。

我确认好MySQL运行的Node节点，然后登录到对应的节点上运行：

df -h  |grep pvc

可以找到pvc所在宿主机的目录，比如/var/lib/kubelet/pods/5****-11f0-a474-76***/volumes/kubernetes.io~csi/pvc-***1f0/mount，cd 到这个目录中我发现的确是有个lost+found目录。

直接粗暴删掉了这个文件夹，MySQL初始化成功了。

2025-03-25T09:12:20.872243Z 0 [Note] Event Scheduler: Loaded 0 events
2025-03-25T09:12:20.872556Z 0 [Note] mysqld: ready for connections.
Version: '5.7.44'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)

我们也可以通过在yaml清单添加忽略这个目录。

containers:
- name: mysql-ops
  args:
  - "--ignore-db-dir=lost+found"  # 忽略生成的目录

尽管确认新建的 PV 是空的，MySQL 仍报错「数据目录非空」，通常是由于以下原因导致：

存储系统自动生成隐藏文件（比如NFS 的 lost+found 目录、本地存储的 .Trash 等）。
PV 挂载路径未隔离：直接挂载到根目录（如 var/lib/mysql）时，存储系统的隐藏文件会被 MySQL 视为已有数据。
动态存储供应商的默认行为：部分 StorageClass 可能在初始化时生成元数据文件。

我检查了我们的动态存储卷是使用的 Ceph CSI 的RBD插件 provisioner: csi-rbdplugin，它默认使用的文件系统是ext4。ext4是会生成lost+found 目录用来磁盘异常修复，修复过程中发现的无法正确链接的文件或目录碎片，会被移动到lost+found目录。我们也可以动态存储卷那边指定fsType为xfs。

运维笔谈已经开通AI智能对话功能，解答有关运维日常工作中遇到的问题以及经验分享，感兴趣的大佬来和我聊聊吧！对话 “阿里云k8s” 可以获取《阿里云Kubernetes项目实战手册》pdf。

文章转载自运维笔谈，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Kubernetes中运行Mysql5.7初始化失败原因

评论