architecture=replication是硬性开关，因bitnami mysql chart默认仅部署单节点deployment，必须启用该参数才能触发复制模板分支，生成primary/secondary两个statefulset、headless service及初始化逻辑；否则secondary相关资源完全不创建。
architecture=replication 必须显式启用，否则所有主从配置都无效。
为什么 architecture=replication 是硬性开关？
Bitnami 的 mysql Chart 默认只起单节点 Deployment，根本不会生成从库 Pod。只有设了 architecture=replication，Chart 才会切换模板分支，创建两个独立的 StatefulSet：primary 和 secondary，并配套生成 Headless Service、复制初始化 Job 和专用 Secret 挂载逻辑。
常见错误现象：明明写了 secondary.replicaCount=2，但 kubectl get pods 只看到 1 个 Pod，且 secondary 相关资源完全没生成——这就是因为漏掉了这个开关。
- 旧版 Chart（9.x 之前）用的是
replication.enabled=true，注意版本差异 - 该参数不是“优化项”，不设就等于告诉 Chart：“我只要单机”，后续所有复制相关字段都会被静默忽略
- Headless Service 名必须保持默认（如
mysql-headless），否则secondaryPod 启动时无法通过 DNS 发现primary
auth.replicationPassword 必须提供且满足格式要求
Secondary Pod 的 InitContainer 会执行 CHANGE MASTER TO，依赖 repl 用户连接主库。这个密码和 root 密码完全隔离，不能复用 auth.rootPassword。
不提供或格式错误会导致 secondary Pod 卡在 InitContainer 阶段，日志反复出现：ERROR 1045 (28000): Access denied for user 'repl'@'%'。
- 长度 ≥8 位，仅用大小写字母 + 数字（避免
$、@、(等 Shell 或 Base64 编码易出错字符） - 必须显式写入
values.yaml或命令行：--set auth.replicationPassword=MyReplPass123 - 该密码最终用于在
primary上创建repl用户，并授予REPLICATION SLAVE权限
storageClass 和 persistence.size 要匹配集群真实能力
Pod 一直 Pending，kubectl describe pod 显示 failed to provision volume，大概率是 storageClass 名字对不上。
Bitnami Chart 默认用 storageClass: standard，但 Kind、k3s、Minikube 或自建集群通常没有这个 StorageClass。
- 先运行
kubectl get storageclass查真实可用名，常见值有：local-path（k3s/Kind）、managed-nfs-storage、gp2（EKS） -
persistence.size建议 ≥10Gi：MySQL 8.0 的ibdata1、binlog、relay log 在写入压力下很容易撑满 8Gi - 测试环境不想配持久化？必须显式关闭：
--set persistence.enabled=false，否则 PVC 会无限等待绑定
别混淆 mysql Chart 和 mysql-operator Chart
用 helm install mysql bitnami/mysql 部署出来的，永远只是主从架构（无自动故障转移）；想实现真正高可用（组复制、自动选主、声明式扩缩容），必须用 Operator。
Operator 不是 Helm 的替代品，而是 Helm 安装的目标之一：你用 Helm 安装的是控制器（mysql-operator），它再监听 MysqlCluster 这类 CRD 来驱动集群行为。
- 正确流程：
helm repo add presslabs https://charts.presslabs.org→helm install mysql-operator presslabs/mysql-operator→ 再kubectl apply -f cluster.yaml（含MysqlCluster资源） - 常见卡点：Operator Pod 没 Running，就直接 apply CR，结果静默失败，
kubectl get mysqlcluster看不到任何资源 - Operator 方案里，
architecture=replication这类参数不存在——那是裸 Chart 的概念，Operator 用的是更高层的 CR 字段（如spec.replicas、spec.gtid）
architecture=replication 就能跑起来；后者必须引入 Operator 或第三方控制器，否则主挂了，没人接管，应用连接串得手动切——这不叫高可用。
