必须启用 architecture=replication 才能部署一主两从；需显式设置 auth.replicationPassword（≥8位字母数字）、匹配 storageClass 和 persistence.size（≥10Gi），并保持 Headless Service 名不变以确保主从发现。
architecture=replication 是必须打开的开关
Bitnami 的 mysql Chart 默认部署单节点，不带主从。想跑一主两从，第一步就得显式启用复制架构，否则所有后续配置（比如 secondary.replicaCount=2）都无效。这个参数不是可选优化项，而是功能开关 —— 它会触发 Chart 内部不同的模板分支，生成 StatefulSet + Headless Service + 复制初始化逻辑。
-
architecture=replication启用后，Chart 会创建两个独立的 StatefulSet：primary和secondary，而不是一个带多副本的 Deployment - 不设这个值，即使你硬加
secondary.replicaCount=2，Helm 也会静默忽略，只起一个 primary Pod - 如果你用的是旧版 Chart（
9.x之前），这个参数叫replication.enabled，注意版本差异
auth.replicationPassword 必须显式提供
MySQL 主从复制依赖 CHANGE MASTER TO，而 Bitnami Chart 在 secondary Pod 启动时会自动执行该语句，前提是它能拿到合法的复制用户密码。这个密码和 root 密码是分开管理的，不能复用 auth.rootPassword。
-
auth.replicationPassword是强制字段：不提供会导致 secondary Pod 卡在 InitContainer 阶段，日志里反复报ERROR 1045 (28000): Access denied for user 'repl'@'%' - 密码长度建议 ≥8 位，且不能含特殊字符如
$、@、(等——Shell 解析或 Base64 编码时容易出错，推荐用字母+数字组合 - 该密码最终会写入 Secret，并在
primary上创建repl用户，权限仅限REPLICATION SLAVE
persistence.size 和 storageClass 要匹配实际环境
默认 Chart 使用 storageClass: standard，但很多集群（尤其是 Kind、Minikube 或自建集群）根本没有名为 standard 的 StorageClass。Pod 会一直 Pending，事件显示 failed to provision volume。
- 先运行
kubectl get storageclass看真实可用的名称，常见值有local-path（k3s/Kind）、managed-nfs-storage（NFS）、gp2（AWS EKS） -
persistence.size建议 ≥10Gi：MySQL 8.0 的 ibdata1、binlog、relay log 加起来，8Gi 在写入压力稍大时容易触发磁盘满告警 - 如果测试环境不想配持久化，必须显式关掉：
persistence.enabled=false，否则 PVC 会一直等待绑定
primary.service.port 和 secondary.service.port 不能随意改
Chart 默认让 primary 用 ClusterIP 暴露 3306，secondary 只暴露读服务（也是 3306），但它们背后是两个独立 Service，DNS 名不同：{release-name}-mysql 指向 primary，{release-name}-mysql-secondary 指向 secondary 集群。
- 改
primary.service.port会影响应用连接串，且 secondary 的探针仍按默认 3306 去健康检查 primary，导致 readiness probe 失败 - secondary 的 Service 类型默认是 ClusterIP，不支持 NodePort 或 LoadBalancer：因为它是内部读负载均衡，外部流量不应直连从库（破坏读写分离语义）
- 若需外部访问 primary，应额外加一个独立的 Service（比如 NodePort），不要动 Chart 内置的
primary.service
StatefulSet 的稳定网络标识是主从同步的前提，别碰 serviceName
Chart 为 replication 架构生成的 Headless Service 名固定为 {release-name}-mysql-headless，primary Pod DNS 是 {release-name}-mysql-primary-0.{release-name}-mysql-headless，secondary 是 {release-name}-mysql-secondary-0/1.{release-name}-mysql-headless。
- 这个 DNS 名被硬编码进 secondary 的启动脚本，用于自动发现 primary 地址
- 如果你手动改了
serviceName或删了这个 Headless Service，secondary 就找不到主库，日志里会出现getent hosts {release-name}-mysql-primary-0.{release-name}-mysql-headless: No address associated with hostname - 所有 Pod 的 hostname（如
mysql-test-primary-0）也依赖这个 Service，改了就断复制
真正难调试的点不在安装命令，而在 secondary Pod 启不来时——它不报错，只是卡在 Running 状态但 READY 0/1。这时候得进容器看 /opt/bitnami/scripts/mysql-replication/setup.sh 日志，而不是只盯 kubectl get pods。
