statefulset是唯一可行方案，因其提供稳定dns、独立pvc和启停顺序保障；需动态注入错开的server_id与auto_increment参数；initcontainer生成配置、headless service配对、探针校验复制状态缺一不可。
必须用 StatefulSet，不能用 Deployment —— 否则主从连接会断、GTID 定位失效、数据不一致却无报错。
为什么 StatefulSet 是唯一可行方案
Deployment 生成的 Pod 名带随机哈希（如 mysql-7d8f9b4c6-xyz12），重启后 DNS 记录失效，而 MySQL 主从依赖固定主机名做 CHANGE MASTER TO 和 GTID 自动定位；StatefulSet 提供三样不可替代的东西：
-
mysql-0.mysql.namespace.svc.cluster.local这类稳定 DNS，主从之间靠它互相发现 - 每个 Pod 绑定独立
PVC，重建后数据不丢、卷不混 - 启停严格按序（
mysql-0先就绪，mysql-1才启动），避免从库连不上主库
server_id 和 auto_increment 必须动态注入且错开
硬编码 server_id=1 或漏配自增偏移，会导致双主写入冲突、START SLAVE 直接报 ERROR 3021 (HY000)，甚至数据静默丢失。
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 用
hostname解析序号：进容器执行hostname | sed 's/mysql-//' | sed 's/\..*$//'得到0或1，再写入配置或传给mysqld -
auto_increment_offset和auto_increment_increment必须写在[mysqld]段里：mysql-0设为1,2，mysql-1设为2,2 - 别信“启动后 SQL 设置就行”——Pod 重建后配置清空，只靠 SQL 不持久
ConfigMap + initContainer 是最稳的配置落地方式
把 my.cnf 放 ConfigMap 里静态挂载，看似简单，但无法适配不同 Pod 的 server_id 和角色；initContainer 在主容器启动前执行一次，才是可靠解法。
- initContainer 用
busybox镜像，读取/proc/1/cgroup或解析hostname获取序号 - 生成带正确
server_id的临时配置文件，复制到/etc/mysql/conf.d/ - 主容器启动时直接加载该配置，不依赖环境变量或启动参数拼接
- 避免 Helm 中
{{ .Index | add 1 }}这类模板逻辑泄露到运行时，降低调试复杂度
Headless Service 和探针配置容易被忽略的关键点
clusterIP: None 是 Headless Service 的标志，但它只是前提；真正起作用的是 StatefulSet 的 serviceName 字段必须和该 Service 名字一致，否则 DNS 不生效。
-
livenessProbe用mysqladmin ping -h localhost即可，但readinessProbe必须等复制线程就绪：mysql -e "SHOW SLAVE STATUS\G" | grep -q "Slave_IO_Running: Yes" - 主库不需要检查复制状态，但从库必须等
Slave_IO_Running和Slave_SQL_Running都为Yes才标记就绪 - 没配对的探针会导致 Service 把流量导到尚未同步完成的从库，应用读到旧数据
最常被跳过的动作是验证两节点的 SELECT @@server_id, @@auto_increment_offset, @@auto_increment_increment; —— 不亲眼确认，等于没配。
