StatefulSet 的 volumeClaimTemplates 是唯一正确入口，必须用它为每个 Pod 自动生成专属 PVC（如 mysql-data-mysql-0），确保 name 与 volumeMounts.name 一致、storageClassName 可用且 volumeBindingMode 为 WaitForFirstConsumer（云环境）、accessModes 为 ReadWriteOnce，并配好 Headless Service。
StatefulSet 的 volumeClaimTemplates 是唯一正确入口
直接在 StatefulSet 里写 volumeClaimTemplates，别碰静态 PVC。手动创建 mysql-data-0、mysql-data-1 这类 PVC 不仅无法随扩缩容自动增减，还会因命名/绑定关系错乱导致从节点挂载主节点数据，InnoDB 直接崩溃。
必须确保以下三点同时成立：
-
volumeClaimTemplates中的name（如mysql-data）要和容器volumeMounts的name完全一致 -
storageClassName必须存在且可用；用云盘时（如alicloud-disk-essd），volumeBindingMode得是WaitForFirstConsumer -
accessModes只能是ReadWriteOnce—— MySQL 不支持多节点并发写入，设成ReadWriteMany看似“更灵活”，实则让两个 Pod 同时改同一份 ibdata1，几秒内就损坏
StorageClass 的 volumeBindingMode 决定调度成败
查不到错误日志却卡在 Pending？八成是 volumeBindingMode 配错了。云环境（AWS/GCP/阿里云）必须用 WaitForFirstConsumer，否则 PV 提前在某个可用区建好，而 Pod 被调度到另一可用区，挂载失败且无明确报错。
验证方式：
kubectl describe sc <your-sc-name></your-sc-name>
确认输出里有 VolumeBindingMode: WaitForFirstConsumer。不是？那就新建一个 SC 并在 StatefulSet 中显式引用它，别试图 patch 默认 SC —— 多数集群禁止修改。
本地 NFS 或 Longhorn 可用 Immediate，但前提是所有 Node 都能 mount 同一 NFS 路径，且权限、UID/GID 对齐，否则 MySQL 启动时提示 Permission denied 或 Can't create test file。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
Headless Service 缺失会导致 PVC 绑定静默失败
StatefulSet 依赖 Headless Service（clusterIP: None）生成稳定 DNS 名称（如 mysql-0.mysql-headless.default.svc.cluster.local）。如果漏掉这步，或 serviceName 字段和 StatefulSet 的 serviceName 值不一致，PVC 会卡在 Pending，kubectl describe pvc 显示 no persistent volumes available for this claim，但实际 PV 没问题——只是绑定逻辑被阻断。
检查清单：
- 是否存在名为
mysql-headless的 Service（名称需与 StatefulSet 的serviceName严格匹配） - 该 Service 的
selector是否正确匹配 StatefulSet Pod 的 label（如app: mysql） - Service 类型是否为
None，而非ClusterIP或NodePort
主从 PVC 必须隔离，不能共用 storageClassName 参数
主从 StatefulSet 必须各自定义独立的 volumeClaimTemplates，哪怕都叫 mysql-data。Kubernetes 会按 Pod 名自动补全为 mysql-data-mysql-source-0 和 mysql-data-mysql-replica-0。如果两个 StatefulSet 共用同一个 storageClassName，而该 SC 不支持并发创建（比如某些本地存储驱动），第二个 PVC 就会无限等待。
更隐蔽的问题：主从使用同一 StorageClass 但底层 PV 实际分配到了不同节点，而 MySQL 主从复制要求从节点能稳定访问主节点 binlog —— 这本身不依赖共享存储，但若误配成共享，后果比宕机还糟：主从写同一套文件系统，GTID 事务号冲突，SHOW SLAVE STATUS 显示 Seconds_Behind_Master: NULL 且 IO_Running 为 No，日志里只有模糊的 Got fatal error 1236。
