如何在K8s集群中通过Helm Chart部署高可用MySQL？

必须启用 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。