helm install 本身不直接实现高可用，需显式配置 bitnami mysql chart 的 replication 架构及关键参数（如 architecture: replication、replicacount、持久化启用、复制账号等），否则默认部署单节点；真正高可用依赖 chart 内置逻辑与正确调优。
helm install 不能直接部署“高可用 MySQL 集群”——它只负责部署 Chart 定义的资源，而真正的高可用依赖你选的 Chart 是否内置主从逻辑、是否配置了正确的 StatefulSet 拓扑和复制参数。Bitnami 的 mysql Chart 支持一主多从，但默认是单节点；必须显式启用复制并调优关键参数，否则你得到的只是多个孤立的 MySQL 实例。
为什么用 Bitnami mysql Chart 而不是自己写 YAML？
它把 MySQL 复制所需的差异化配置（server-id、gtid_mode、read_only、复制用户初始化）封装进了 initContainer 和 entrypoint 脚本里，避免手动拼接 ConfigMap 或硬编码 Pod 序号。但前提是：你得知道哪些 values 必须改，否则 Chart 会静默降级为单节点模式。
必须修改的 values.yaml 关键项
以下字段不设值，主从复制根本不会启动：
-
architecture: replication—— 不是standalone，也不是默认值（默认是standalone） -
auth.replicationUser和auth.replicationPassword—— 复制专用账号，不能复用root密码 -
primary.persistence.enabled: true且secondary.persistence.enabled: true—— 主从都需持久化，否则重启后复制关系丢失 -
primary.extraFlags和secondary.extraFlags中至少包含--log-bin（主）和--super-read-only（从），Bitnami 默认已加，但若覆盖extraFlags就会清空默认项 -
secondary.replicaCount: 2—— 显式声明从节点数量，不能只靠replicas
StorageClass 配置错误会导致复制中断
常见现象：mysql-secondary-0 一直 Pending，或日志报 Can't start server : Bind on unix socket: Permission denied。这不是权限问题，而是 PVC 绑定失败后，MySQL 进程试图在空目录 /var/lib/mysql 下初始化，触发了容器内 UID 冲突。
必须确保：
- 集群已有支持
ReadWriteOnce的 StorageClass（如nfs-client、ceph-rbd），hostPath或localPV 在多节点场景下不可靠 -
primary.persistence.storageClass和secondary.persistence.storageClass显式指定同一 StorageClass 名称，不要留空（留空可能 fallback 到 default，而 default 可能不存在或不兼容） - StorageClass 的
allowVolumeExpansion: true—— 后续扩容 PVC 时必需，否则kubectl patch pvc会失败
验证复制是否真正在工作
别只看 Pod Running 状态。登录主库执行：
SHOW MASTER STATUS;
再登录任一从库执行：
SHOW SLAVE STATUS\G
关键检查项：
-
Slave_IO_Running: Yes且Slave_SQL_Running: Yes -
Seconds_Behind_Master: 0（初始同步完成后的理想值） -
Retrieved_Gtid_Set和Executed_Gtid_Set不为空且匹配
如果 Seconds_Behind_Master 持续增长，大概率是网络延迟或从节点资源不足（CPU/IO），而非配置错误——这时要查 kubectl top pods -n <ns></ns>，而不是重装 Chart。
@、/）没做 base64 编码也会让 initContainer 解析失败。这些点不提前卡住，helm install 成功只是假象。
