在Kind集群部署MySQL遇CrashLoopBackOff及InnoDB重做日志创建失败

1. 清理残留的损坏存储卷 #

InnoDB重做日志/数据文件损坏大概率是之前异常退出后PVC里残留了损坏文件，直接清理重建存储卷是最快的解决方式：

• 查看当前MySQL对应的PVC：
  kubectl get pvc
• 删除故障pod绑定的PVC（比如名为mysql-data-mysql-0）：
  kubectl delete pvc mysql-data-mysql-0
• 删除故障pod，让StatefulSet重新调度并创建干净的存储卷：
  kubectl delete pod mysql-0

2. 检查MySQL配置的权限与日志路径 #

确认ConfigMap里的InnoDB配置路径正确，且容器内目录权限为mysql用户所有：

• 查看ConfigMap中的MySQL配置：
  kubectl describe configmap mysql-config
• 确保innodb_log_group_home_dir指向的路径存在且权限正确，若使用自定义路径，可在StatefulSet中添加initContainer修复权限：

  initContainers:
  - name: fix-mysql-perms
    image: busybox:1.36
    command: ["sh", "-c", "chown -R 999:999 /var/lib/mysql"]
    volumeMounts:
    - name: mysql-data
      mountPath: /var/lib/mysql
  

3. 适配多节点Kind集群的存储限制 #

Kind默认用hostPath存储类，多节点集群中pod调度到不同节点会无法访问原节点的存储文件，导致数据损坏：

• 查看当前存储类：
  kubectl get storageclass
• 要么给MySQL pod添加节点固定调度，避免跨节点调度：

  spec:
    template:
      spec:
        nodeSelector:
          kubernetes.io/hostname: kind-control-plane # 替换为你的集群节点名称
  

• 要么替换为支持分布式的存储类（比如local-path-provisioner），确保多节点间存储可访问。

4. 手动清理损坏的InnoDB文件（极端情况） #

如果重新创建PVC后仍有问题，可临时挂载存储卷手动删除损坏文件：

• 启动临时清理容器：
  kubectl run -it --rm --image=busybox:1.36 temp-cleaner --volume-name=mysql-data-mysql-0 --mount-path=/var/lib/mysql
• 在容器内删除损坏的InnoDB文件：
  rm -rf /var/lib/mysql/ib_logfile* /var/lib/mysql/ibdata1
• 退出容器后重新创建mysql-0 pod即可。

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