必须启用architecture=replication，否则Helm静默降级为单节点；该参数是功能开关，决定是否渲染primary/secondary两个StatefulSet、Headless Service及复制初始化逻辑。
architecture=replication 是必须打开的开关，否则 Helm 会静默降级为单节点部署。
不设 architecture=replication 就别想跑主从
Bitnami 的 mysql Chart 默认只起一个 primary Pod，哪怕你写了 secondary.replicaCount=2，也不会创建从节点。这个参数不是“优化项”，而是模板分支开关：只有设了 architecture: replication，Chart 才会渲染出两个 StatefulSet（primary 和 secondary）、Headless Service、以及复制初始化逻辑。
旧版 Chart（9.x 之前）用的是 replication.enabled=true，注意核对 Chart.yaml 中的 appVersion 和文档版本。
- 没设该参数 → 日志里看不到 secondary Pod 启动，
kubectl get statefulset只有mysql-primary - 设错成
architecture: standalone或拼写错误 → Helm install 不报错，但行为等同于未启用 - 想验证是否生效：安装后检查
kubectl get statefulset，应同时存在mysql-primary和mysql-secondary
auth.replicationPassword 必须显式提供且避开 Shell 特殊字符
secondary Pod 启动时，InitContainer 会执行 CHANGE MASTER TO，依赖一个名为 replicator（或你自定义的 auth.replicationUser）的用户。这个密码和 auth.rootPassword 完全独立，不能复用。
不提供 auth.replicationPassword，secondary Pod 会卡在 InitContainer，日志反复出现：ERROR 1045 (28000): Access denied for user 'repl'@'%'。
- 长度建议 ≥8 位，仅用大小写字母 + 数字（如
ReplicaPass2026），避免$、@、(、)等——Base64 编码或 Shell 变量展开时容易被截断或转义失败 - 该密码最终写入 Secret，并在 primary 上自动创建用户，权限仅为
REPLICATION SLAVE - 如果已有 Secret，可用
auth.existingSecret指向它，但需确保 key 名匹配（默认是mysql-replication-password）
StorageClass 和 persistence.size 必须匹配集群真实能力
Pod 卡在 Pending 状态？八成是 PVC 绑定失败。默认值 storageClass: standard 在大多数非云环境（如 Kind、k3s、自建集群）并不存在。
先运行 kubectl get storageclass 查看真实可用名称，常见值包括：local-path（k3s/Kind）、managed-nfs-storage（NFS）、gp2（AWS EKS）、alicloud-disk-efficiency（阿里云）。
-
persistence.size建议 ≥10Gi：MySQL 8.0 的 ibdata1 + binlog + relay log 在中等写入压力下，8Gi 容易触发磁盘满告警 - 测试环境不想用持久化？必须显式关掉：
persistence.enabled=false，否则 PVC 会无限等待 - secondary 的
storageClass可以和 primary 不同（如用 NFS 做主库，本地盘做从库），但需确保两者都真实存在且可绑定
Headless Service 名称不能改，否则主从发现失败
secondary Pod 启动时，靠解析 Headless Service 名（默认是 mysql-headless）来发现 primary 的 DNS 名（如 mysql-primary-0.mysql-headless.default.svc.cluster.local）。这个服务名由 Chart 固定生成，硬编码在模板里。
如果你在 values.yaml 中修改了 primary.fullnameOverride 或 nameOverride，可能导致 Headless Service 名变更，secondary 就连不上 primary。
- 不要碰
primary.service.headless.name这类内部字段（Chart 未暴露为可配项） - 对外访问用
primary.service.type（如NodePort或LoadBalancer），不影响内部发现 - 验证方法：进 secondary Pod 执行
nslookup mysql-headless，应能解析出 primary 的 A 记录
