StatefulSet是必须的，因其提供稳定网络标识（如mysql-0）、独立PVC绑定、有序启停，确保MySQL主从数据持久性与复制一致性；Deployment无状态特性会导致数据丢失和标识混乱。
容器编排中实现 MySQL 高可用，不能只靠 docker-compose up -d 起多个实例就完事——StatefulSet + 持久化存储 + 复制协议才是生产级底线。
为什么 StatefulSet 是必须的，而不是 Deployment
Deployment 管理的是无状态 Pod，重启或漂移后名字、网络标识、挂载点全变，MySQL 数据目录一丢就无法恢复。StatefulSet 才能保证：
- 每个 Pod 有固定名称（如
mysql-0、mysql-1），DNS 可解析为mysql-0.mysql-headless.default.svc.cluster.local - PVC 名称按序绑定（
mysql-data-mysql-0→mysql-0），节点重建后仍挂载原数据卷 - 启动/终止严格有序（
mysql-0启动完成才启mysql-1），避免复制链初始化混乱
跳过 StatefulSet 直接用 Deployment 部署 MySQL，等于把数据库当临时缓存用，RPO=全量丢失。
主从复制在 Kubernetes 中怎么自动初始化
容器里手动 CHANGE MASTER TO 不可维护。真实做法是靠 initContainer + 配置脚本驱动复制关系建立：
- 所有 Pod 共享同一 ConfigMap，定义
MYSQL_ROLE=master或slave，由 Pod 标签或 hostname 动态识别角色 - initContainer 运行
wait-for-mysql.sh，确认mysql-0已就绪再继续 - slave Pod 的 entrypoint 脚本执行
mysql -h mysql-0 -e "CHANGE MASTER TO ..."，binlog 文件名和位置从mysql-0的SHOW MASTER STATUS实时获取
硬编码 MASTER_LOG_FILE 和 MASTER_LOG_POS 在 yaml 里是典型反模式——每次重建集群都得重查、重改、重部署。
GTID + 半同步是最低安全水位
异步复制下，主库 crash 后未同步到从库的 binlog 就永远丢失。必须启用：
-
gtid_mode=ON+enforce_gtid_consistency=ON：避免CHANGE MASTER时因日志偏移错位导致复制中断 -
plugin_load_add='rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so'：加载半同步插件 -
rpl_semi_sync_master_enabled=ON+rpl_semi_sync_slave_enabled=ON：开启半同步
不配 GTID，故障切换后从库可能重复执行事务；不配半同步，Kubernetes 自动驱逐主 Pod 时，最后几笔事务大概率静默消失。
Headless Service 和探针配置决定故障是否真能自动转移
光有复制不够，客户端必须连上“当前主库”。这依赖两个关键配置：
- Headless Service（
clusterIP: None）暴露所有 Pod 的 DNS 记录，配合脚本轮询SELECT @@read_only才能识别主库 - Liveness 探针必须检查
mysqladmin ping -u root -p$MYSQL_ROOT_PASSWORD，而不仅仅是端口通——否则复制中断的从库也会被当成健康实例接入流量 - Readiness 探针应额外判断
SHOW SLAVE STATUS\G中Slave_IO_Running和Slave_SQL_Running是否均为Yes
没做这些，HAProxy 或 ProxySQL 就算接入了，也只会把读请求打到已停止同步的从库上，数据延迟无限放大。
最易被忽略的一点：所有节点的 server-id 必须全局唯一且写死在配置中（不能靠环境变量生成），否则 MGR 或传统主从在脑裂恢复时会拒绝加入集群——Kubernetes 下动态生成的 server-id 是自毁式操作。
