必须使用mysql operator而非helm裸chart部署高可用mysql集群，因其通过mysqlcluster等crd实现自动故障转移、组复制管理和声明式扩缩容，而bitnami/mysql等chart仅提供单实例或不可靠主从，无法满足真正高可用要求。

直接上结论：别用 Helm 装 bitnami/mysql 这类裸 MySQL Chart，它压根不提供自动故障转移——你只会得到一个单实例，或手动改 replicas 后复制断裂、主库选不出来。真要高可用，必须走 MySQL Operator 路径，它才是唯一能管理 InnoDB Cluster、组复制、声明式扩缩容的控制器。

为什么不能用 Deployment 或普通 StatefulSet 手搭主从

Deployment 生成的 Pod 名是随机哈希值，重启后 PVC 可能被新 Pod 绑定，数据错乱；StatefulSet 虽有固定名（mysql-0、mysql-1），但仅靠它无法自动完成：

• 主节点宕机后，没人触发 STOP SLAVE; CHANGE MASTER TO ...; START SLAVE
• 新节点加入时，没人自动执行 CLONE 或 BACKUP LOCK 同步数据
• 组复制成员变更（比如 mysql-2 挂了），没人更新 group_replication_group_members 配置

这些逻辑全在 MySQL Operator 的控制器里实现，不是 YAML 写几行就能替代的。

安装 mysql-operator 的 Helm 命令必须分两步走

常见错误是把 Operator 控制器和数据库集群混为一谈，结果 kubectl get pods 看不到 MysqlCluster 对应的 Pod。正确顺序是：

Kubernetes Network Policy Generator

使用加权评分卡在12项标准上评估和比较隐私解决方案供应商。适用于选择隐私管理软件、比较数据保护方案等场景。

下载

• 先加仓库：helm repo add presslabs https://charts.presslabs.org（注意不是 bitnami/mysql）
• 再装控制器：helm install mysql-operator presslabs/mysql-operator --namespace=mysql-operator --create-namespace
• 验证控制器就绪：kubectl get pods -n mysql-operator -l app=mysql-operator，必须看到 Running 状态，否则后续 CR 创建会静默失败
• 最后才部署集群资源：kubectl apply -f cluster.yaml，其中 apiVersion: mysql.presslabs.org/v1alpha1，kind: MysqlCluster

漏掉任一环节，MysqlCluster 就只是个 YAML 文件，Operator 根本不会响应。

MysqlCluster CR 中几个关键字段不能瞎填

spec.replicas、spec.backupSchedule、spec.secretName 看似简单，但填错会导致集群卡在 Pending 或反复重启：

• replicas 必须 ≥ 3 —— 组复制要求多数派（quorum），2 节点无法容忍任意 1 节点故障
• backupURL 如果写成 s3://bucket/，但没配好 AWS 凭据 Secret，Operator 会不断重试备份并阻塞其他操作
• secretName 必须指向含 rootPassword 和 replicationPassword 的 Secret，且字段名必须严格匹配 Operator 文档定义，少一个 key 就初始化失败
• StorageClass 名要和集群实际存在的 StorageClass 一致，比如用 local-mysql，就不能写成 standard

建议先用 kubectl describe mysqlcluster production-db 查 Events，比看 Pod 日志更快定位问题。

最常被忽略的点是 Operator 启动后不会自动创建备份仓库或初始化用户权限——它只监听 CR 变更，所有配置都得显式声明。哪怕只差一个 backupSchedule 字段，整个集群也不会触发首次备份，而你可能几天后才发现数据根本没落盘。