architecture=replication 必须显式设置，否则 helm 静默降级为单节点；它控制模板渲染分支，设错或不设则 secondary 相关资源完全不生成，且 secondary.replicacount 等配置无效。
architecture=replication 必须显式设置，否则 Helm 会静默降级为单节点 —— 这是交付主从集群最常被跳过的硬性前提，不是可选项。
为什么 architecture=replication 是开关，不是配置项？
Bitnami 的 mysql Chart（v9.x+）用 architecture 字段控制整个模板渲染分支：
• 不设或设错（如 standalone、replica、拼写漏字母），templates/ 下所有 secondary 相关文件（StatefulSet、Headless Service、initContainer 逻辑）根本不会被渲染；
• 日志里看不到 secondary 启动失败，kubectl get statefulset 只有 mysql-primary；
• 即使你写了 secondary.replicaCount=3，也完全无效；
• 旧版（9.x 前）用的是 replication.enabled=true，务必核对当前 Chart 的 Chart.yaml 中的 appVersion 和官方文档版本。
auth.replicationPassword 必须独立提供且避开 Shell 特殊字符
Secondary Pod 的 InitContainer 会执行 CHANGE MASTER TO，依赖一个权限受限的复制用户（默认用户名 repl）。这个密码和 auth.rootPassword 完全隔离：
• 不提供 auth.replicationPassword → InitContainer 卡住，日志反复报 ERROR 1045 (28000): Access denied for user 'repl'@'%'；
• 密码含 $、@、(、) 等字符 → 在 Helm CLI 命令行中会被 Shell 提前展开或截断；
• 推荐格式：≥8 位，仅用大小写字母 + 数字（如 ReplicaPass2026）；
• 若用 --set 覆盖，必须加单引号： --set auth.replicationPassword='ReplicaPass2026'；
• 已有 Secret 时，用 auth.existingSecret 指向，并确保 key 名为 mysql-replication-password（默认）。
StorageClass 名称必须与集群真实可用值严格匹配
Pod 卡在 Pending？八成是 PVC 绑定失败，根源常在 storageClass：
• 默认值 standard 在 Kind、k3s、自建集群中几乎不存在；
• 先运行 kubectl get storageclass 查看真实名称（常见值如 local-path、nfs-client、openebs-hostpath）；
• primary 和 secondary 的 persistence.storageClass 可不同（如主用 SSD 类型，从用 HDD），但各自值必须真实存在；
• 如果集群没动态 Provisioner，得提前手动创建 PV，并在 values 中设 persistence.existingClaim 而非依赖自动绑定。
验证是否真跑起了主从，别只看 Pod 状态
Pod Running ≠ 复制链就绪。关键检查点：
• kubectl get statefulset：必须同时存在 mysql-primary 和 mysql-secondary；
• kubectl logs -n NAMESPACE mysql-secondary-0 -c mysql：末尾应出现类似 Replication started successfully 或 Waiting for primary to be ready... 后转为正常 MySQL 启动日志；
• 进入 primary Pod 执行 mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "SHOW SLAVE HOSTS;"：应返回从节点 IP 和端口；
• 进入 secondary Pod 执行 mysql -urepl -p$REPL_PASS -e "SHOW SLAVE STATUS\G" | grep -E "(Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master)"：三者都应为 Yes 且延迟为 0 或极小值。
architecture=replication 的“静默失效”特性——它不报错、不警告、不提示，只默默删掉你想要的全部从节点逻辑。部署后第一件事，不是查 Pod，而是查 StatefulSet 列表。
