MySQL Operator 是实现 MySQL 从物理机到 Kubernetes 迁移最稳妥路径，它封装主从切换、备份恢复、故障自愈等运维逻辑，而 StatefulSet 仅提供基础有状态编排，无法理解 MySQL 语义，需手动干预复制链与高可用。
mysql-operator 是目前实现 MySQL 从物理机到 Kubernetes 容器化迁移最稳妥的路径——它不只解决“能不能跑”，而是直接接管主从切换、备份恢复、故障自愈等物理机时代靠人盯的环节。用 StatefulSet 手动搭 MySQL，迁移完还得天天写脚本查 SHOW SLAVE STATUS；换成 Operator，这些逻辑全被封装进控制器里，你只管声明“我要一个三节点高可用集群”，剩下的它来填。
为什么不能跳过 Operator 直接用 StatefulSet 迁移？
StatefulSet 能起 Pod、挂 PVC、保序启动，但它对 MySQL 的语义一无所知：mysql-operator 才知道什么时候该执行 RESET SLAVE ALL，什么时候该触发 MGR 选主，什么时候该拒绝把两个节点同时标为 leader。
- 物理机上一次主库宕机，DBA 手动切从库、改 DNS、刷连接池——K8s 里没人“手动”，必须由 Operator 自动完成
- StatefulSet 的滚动更新会逐个重建 Pod，但 MySQL 主从拓扑不能简单“删一个再建一个”，否则复制链断裂
- Operator 通过 CRD（如
MySQLCluster）把数据库状态映射成 K8s 原生对象，能被kubectl get mysqlclusters查，也能被 Prometheus 抓指标
迁移前必须验证的 3 个物理机状态
Operator 不会帮你修脏数据，它只按声明式配置工作。迁移前务必确认物理机 MySQL 满足以下条件：
-
binlog_format必须是ROW（STATEMENT或MIXED在 Operator 环境下易导致复制不一致） - 主库
server_id非零且全局唯一，所有从库server_id不能与主库冲突（Operator 初始化时会校验并拒绝非法值） - 确保
max_allowed_packet≥ 64M，避免 Operator 同步大事务时被截断（尤其含LONGTEXT或BLOB字段的表）
Operator 部署后如何对接存量数据？
Operator 不提供“一键导入物理机数据”功能，但给出了清晰的衔接路径：先停写、导出、再注入。关键在 initContainer 阶段控制权移交：
- 用
mysqldump --single-transaction --routines --triggers导出全量，**不要加--master-data**（Operator 会自己管理 binlog 位点） - 把 dump 文件挂进 Pod 的
/docker-entrypoint-initdb.d/目录，Operator 启动时自动执行（注意文件权限必须是644，否则被跳过） - 若数据量 >50GB，改用
mydumper并配合myloader并行导入，Operator 的 initContainer 支持 shell 脚本调用
流量切换时最容易忽略的连接池配置
Spring Boot 应用切到新集群后出现大量 Connection refused 或 Communications link failure，90% 是因为没调 HikariCP 的重试参数：
-
connection-timeout建议设为30000（30秒），给 Operator 故障转移留出窗口（MGR 切主通常 10–20 秒） - 必须关闭
auto-commit的隐式提交行为，否则 Operator 触发主从切换瞬间，未提交事务会丢失 -
jdbc:mysql://sample-leader.mysql.svc:3306/mydb?allowPublicKeyRetrieval=true&useSSL=false—— 连接串里必须用 Service 名（如sample-leader），不能写 Pod IP 或 NodePort
Operator 的 leader Service 是动态 Endpoints，底层随主节点变化而更新，这是它和 StatefulSet 最本质的区别：不是靠人工改 DNS 或 ConfigMap，而是靠 K8s Service 控制平面实时同步。
