StatefulSet是唯一能可靠支撑MySQL主从集群的控制器，因其提供稳定网络标识、有序启停和PV自动绑定；必须配合Headless Service（clusterIP: None）实现每个Pod独立DNS解析（如mysql-0.mysql.default.svc.cluster.local），否则从库无法稳定连接主库。
StatefulSet 是唯一能可靠支撑 MySQL 主从集群的控制器，用 Deployment 或 ReplicaSet 部署 MySQL 一定会在 Pod 重建后丢数据、断复制、连错实例——这不是配置问题，是模型不匹配。
为什么必须用 Headless Service 配合 StatefulSet
StatefulSet 的每个 Pod（如 mysql-0）需要被独立寻址，而普通 ClusterIP Service 会做负载均衡，把请求随机转发到任意后端 Pod，导致从库无法稳定连接主库。只有 Headless Service（即 clusterIP: None）才允许 CoreDNS 为每个 Pod 解析出独立的 A 记录，例如 mysql-0.mysql.default.svc.cluster.local。
常见错误现象：mysql-0 启动后反复 CrashLoopBackOff，日志里出现 Can't find hostname mysql-0 或 getaddrinfo failed，90% 是因为 Service 没设成 headless，或 DNS 域名拼错。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
Service的metadata.name必须和StatefulSet的serviceName字段完全一致（大小写、连字符都不能错） - DNS 域名格式固定为：
<pod-name>.<service-name>.<namespace>.svc.cluster.local</namespace></service-name></pod-name>，少字段或拼错都会解析失败 - 验证方法：
kubectl exec -it mysql-0 -- nslookup mysql-0.mysql.default.svc.cluster.local，应返回唯一 IP；若返回多个 IP 或报NXDOMAIN，说明 DNS 未生效
如何让 mysql-0 固定为主库、其余为从库
StatefulSet 本身不处理主从逻辑，必须靠启动脚本或 initContainer 根据 $HOSTNAME（即 mysql-0、mysql-1）做条件判断。
- 主库（
mysql-0）必须启用log-bin和固定server-id=1；从库需用不同server-id（例如用$(hostname | sed 's/mysql-//')生成） - 从库启动前必须等待主库
mysqld就绪：仅靠readinessProbe不够，建议在entrypoint脚本中用mysqladmin ping -h mysql-0.mysql.default.svc.cluster.local轮询，超时退出 - GTID 模式下，从库首次同步前需执行
SET GLOBAL gtid_purged = ''（前提是主库已RESET MASTER或已知 purged 集合），否则START SLAVE会失败 - 主库崩溃重建后，新
mysql-0的 binlog position 和 GTID 已重置，旧从库直接CHANGE MASTER TO会报Could not find first log file name in binary log index file；需人工介入重置复制或使用备份恢复
PVC 绑定失败导致 Pod 卡在 Pending 怎么办
云厂商的默认 StorageClass（如 AWS EBS、Azure Disk、阿里云 cloud_efficiency）通常绑定到单可用区（AZ），而 StatefulSet 每个 Pod 绑定独立 PVC，若调度器把 mysql-1 调度到和 mysql-0 不同的 AZ，且 PVC 已绑定到前者所在 AZ 的磁盘，则后者无法挂载，状态卡在 Pending。
- 解决方案一：改用支持多 AZ 的存储类（如 AWS EFS、阿里云 NAS、Ceph RBD）
- 解决方案二：显式配置
volumeBindingMode: WaitForFirstConsumer并配合nodeAffinity约束，确保 PVC 绑定前先确定调度节点 - 本地测试环境可用
Local PersistentVolume，但必须为每个节点手动创建 PV，并加nodeAffinity对应 PVC，生产环境严禁使用
最易被忽略的点是：DNS 解析是否真正生效、server-id 是否全局唯一、以及主库重建后的 GTID 衔接——这三个地方出错，集群看起来“跑起来了”，实则复制早已中断，数据一致性无法保障。
