必须使用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。正确顺序是：
- 先加仓库：
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 字段，整个集群也不会触发首次备份，而你可能几天后才发现数据根本没落盘。
