不支持。MySQL Operator本身不提供全自动、无人值守的MySQL版本升级能力，仅负责集群生命周期管理；版本升级需人工介入，包括备份、停写、滚动替换Pod、手动执行mysql_upgrade等分阶段验证操作。
MySQL Operator 是否支持自动升级？
不支持。MySQL Operator（如 Oracle 官方的 mysql-operator 或 Percona 的 percona-server-mysql-operator）本身**不提供全自动、无人值守的 MySQL 版本升级能力**。它负责的是集群生命周期管理（部署、扩缩容、备份恢复、故障转移），但版本升级始终被设计为一个需人工介入、分阶段验证的操作。
为什么不能直接改 spec.version 触发升级？
直接修改 MySQLCluster CR 中的 spec.version 字段（例如从 8.0.32 改成 8.0.34）通常不会触发滚动升级，甚至可能被 Operator 忽略或报错。原因包括：
- Operator 默认将
version视为“初始安装约束”，而非可热更新字段； - MySQL 主版本升级（如 5.7 → 8.0）涉及数据字典变更、SQL 语法兼容性破坏，必须停机执行
mysqld --upgrade； - 即使同属 8.0.x 小版本，InnoDB 表空间格式、系统表结构也可能有隐式变更，需人工确认
mysql_upgrade是否必需。
可行的升级路径：Operator + 手动编排
在 Kubernetes 中安全升级 MySQL，本质是用 Operator 管理底层资源，但把升级逻辑拆解为可控步骤。关键操作如下：
- 先备份：用 Operator 自带的
MySQLBackupCR 创建全量备份，确保status.phase == "Completed"； - 停写流量：通过 Service 或 Ingress 暂时切断应用写请求（只读可保持）；
- 滚动替换 Pod：手动删除旧 Pod（如
kubectl delete pod mysql-sample-0），Operator 会按新镜像重建，但仅当image字段显式覆盖时才生效； - 验证启动日志：新 Pod 启动后检查日志是否含
MySQL init process done. Ready for start up.及后续无ERROR； - 运行升级命令：进入新 Pod 执行
mysql_upgrade -u root -p$MYSQL_ROOT_PASSWORD（仅当 Operator 文档明确要求时）； - 切回流量并观察监控：重点关注
mysql_global_status_questions、连接数、慢查询率。
容易被忽略的兼容性陷阱
升级失败往往不是因为 Operator 配置错，而是忽略了 MySQL 层面的约束：
-
default_authentication_plugin在 8.0.4+ 默认为caching_sha2_password，老客户端（如某些 Java JDBC 8.0.22 以下驱动）会报Public Key Retrieval is not allowed； - Operator 使用的
initContainer镜像必须与目标 MySQL 版本兼容——例如 Percona Operator 的perconalab/mysql-shell-init若未同步更新，可能无法解析新版mysqld --verbose --help输出； - 自定义
my.cnf中若含已废弃参数（如query_cache_type在 8.0 被移除），Pod 会卡在启动状态，日志只显示mysqld: unknown variable 'query_cache_type=1'。
真正耗时的从来不是改 YAML，而是确认这些细节是否闭环。
