mysqlcluster资源定义是operator工作的唯一入口，必须使用且需满足spec.replicas≥3、spec.secretname存在有效密码、spec.storage显式声明；底层依赖statefulset保障pvc绑定与启动顺序，deployment会导致数据混乱。
MySQLCluster 资源定义就是声明式集群的入口，不是“能不能”，而是“必须用它才能让 Operator 真正工作”。
直接上手前先确认：你用的是 Bitpoke（Presslabs）的 mysql-operator，不是 Oracle 官方那个已基本停更的版本。后者只支持 MySQL 8.0+、依赖 MGR、无备份集成，生产环境踩坑概率高。
为什么必须用 StatefulSet 而不是 Deployment？
因为 MySQLCluster 底层控制器会生成 StatefulSet，而 Deployment 会导致数据错绑或复制断裂：
-
mysql-0重启后，如果用 Deployment，新 Pod 可能挂载mysql-2的 PVC，数据直接混乱 -
StatefulSet保证每个 Pod 名字固定、PVC 名称可预测（如data-mysql-0）、启动顺序可控（主节点先就绪再拉从库） - Orchestrator 故障检测依赖稳定的 Pod DNS 名（
mysql-0.mysql-headless.default.svc.cluster.local），Deployment 无法提供
MySQLCluster YAML 中最关键的三个字段
一份最小可用的集群定义，去掉注释后实际只有 12 行左右，但以下三项漏掉任一，Operator 就不会创建 Pod：
-
spec.replicas：必须 ≥ 3 才能触发自动主从选举；设为 1 是单实例，不走 Orchestrator，也不算“集群” -
spec.secretName：必须存在且含rootPassword和replicationPassword字段；Operator 不会帮你生成密码，空 secret 导致PodPending状态卡住 -
spec.storage：即使你用本地hostPath测试，也得显式写size: 10Gi和persistent: true；默认值为空，Operator 拒绝 reconcile
备份失败最常见的两个原因
配置了 backupSchedule 却没看到 S3 备份文件？先查这两处：
-
backupURL值末尾不能带斜杠 ——s3://bucket-name/会失败，必须写成s3://bucket-name - Operator Pod 必须有对应云存储的权限：AWS 场景下，是给
mysql-operator的 ServiceAccount 绑定 IRSA 角色，不是给 MySQL Pod 绑；权限错位会导致 backup job 启动即失败，日志里只有failed to list backups这类模糊报错
集群状态卡在 Provisioning 怎么办？
这是 Operator 最常被问的问题，本质是底层资源没就绪，不是 Operator 本身坏了：
- 检查
kubectl get pvc -n default—— 如果 PVC 处于Pending，90% 是 StorageClass 不存在或 Provisioner 未运行（比如你写了storageClassName: nfs-client，但集群没装 nfs-subdir-external-provisioner） - 检查
kubectl logs -l app=mysql-operator—— 关键线索在 “reconciling MySQLCluster” 后面那句 error，比如 “failed to create headless service”，说明 RBAC 权限缺services的 create 权限 - 别删 CR 重试 ——
MySQLCluster删除后，Operator 不会自动清理关联的 StatefulSet 和 PVC，残留资源会干扰下次部署
