Kubernetes中postStart hook引发竞争条件致MySQL PVC损坏如何解决

问题根因 #

你遇到的问题核心原因是Kubernetes的postStart hook执行时机和容器内部服务就绪状态无绑定关系：K8s会在容器进程启动后立刻触发postStart，不会等待readinessProbe检测通过，也不感知容器内部应用的初始化进度。首次启动时MySQL需要完成PVC挂载、系统表创建、权限初始化等一系列操作，你硬编码的12秒等待不足以覆盖这个初始化周期，此时执行SQL查询会打断MySQL的初始化流程，导致PVC内的数据库文件损坏。二次重启时PVC内已经完成了初始化，12秒足够MySQL完成常规启动，因此可以正常运行。

另外需要明确：readinessProbe无法解决这个问题，它的作用仅仅是标记Pod是否就绪、是否可以接入流量，不会阻塞postStart hook的执行，二者是并行运行的。

修复方案 #

方案一：替换硬编码等待为可用性检测（最快适配现有逻辑） #

将postStart内的固定sleep改为循环检测MySQL真实服务状态，确认可用后再执行目标查询：

lifecycle:
  postStart:
    exec:
      command:
        - /bin/sh
        - -c
        - |
          hostname
          # 循环检测直到MySQL可正常处理请求
          until /opt/rh/rh-mysql80/root/usr/bin/mysql -h localhost -u root -D grafana -P 3306 -e "SELECT 1" > /dev/null 2>&1
          do
            sleep 2
          done
          # 检测通过后再执行查询
          echo $QUERY | /opt/rh/rh-mysql80/root/usr/bin/mysql -h localhost -u root -D grafana -P 3306

方案二：优化探针配置避免假就绪 #

将原有的TCP端口检测探针替换为实际MySQL可用性检测，确保Pod就绪状态和数据库真实服务能力对齐：

readinessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - /opt/rh/rh-mysql80/root/usr/bin/mysql -h localhost -u root -e "SELECT 1"
  initialDelaySeconds: 15
  periodSeconds: 2
  timeoutSeconds: 1
  failureThreshold: 10
livenessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - /opt/rh/rh-mysql80/root/usr/bin/mysql -h localhost -u root -e "SELECT 1"
  initialDelaySeconds: 120
  periodSeconds: 5
  timeoutSeconds: 1

方案三：使用原生初始化逻辑（最稳妥） #

如果你要执行的QUERY是库表初始化操作，直接将SQL文件放入MySQL镜像的/docker-entrypoint-initdb.d/目录即可，MySQL官方启动脚本会保证所有初始化SQL在数据库完全初始化完成后才执行，从根源上规避时序错误导致的文件损坏。如果是运行时查询逻辑，也可以单独写一个K8s Job在Pod就绪后执行，不要放到postStart中。

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