MySQL在云原生中必须解耦计算与存储，StatefulSet为底线但需配合init脚本和外部协调；PV/PVC须匹配ReadWriteOnce+Retain或对象存储适配；连接池需按容器规格调优并指向Headless Service；备份应基于存储快照+binlog或xtrabackup挂载PV实现。
直接上结论：MySQL 在云原生环境里不能当“普通服务”跑，必须拆开算——计算节点要无状态、存储必须独立、连接池得按容器规格收口，否则轻则连接打满、重则数据丢失。
StatefulSet 是底线，不是最优解
Kubernetes 原生的 StatefulSet 确实能保证 Pod 有序启停和稳定网络标识，但它默认绑定本地存储或简单 PV，容易变成单点瓶颈。真实生产中常见问题包括：
- 滚动更新时主从切换失败，因为 PVC 没做跨节点可读写（
ReadWriteOnce限制） - 扩容新实例后无法自动加入集群，缺少初始化逻辑（如
mysqld --initialize-insecure或 GTID 同步配置） - 没有预设
initContainer校验存储路径权限，导致 MySQL 启动报错Can't create test file /var/lib/mysql/...
建议做法是用 StatefulSet + 自定义 init 脚本 + 外部一致性协调（如 Operator 或脚本化 bootstrap），而不是裸用。
PV/PVC 必须匹配访问模式与回收策略
MySQL 数据目录要求强一致性写入，hostPath 或 local 类型 PV 在多节点集群中基本不可用；而 ReadWriteMany 又不被多数块存储支持。实际可行路径只有两条：
- 用支持
ReadWriteOnce的分布式块存储（如 Ceph RBD、AWS EBS、阿里云云盘），配合Retain回收策略，避免误删数据 - 走对象存储 + 存储引擎适配路线（如 Vitess + S3 backend），但需放弃原生 MySQL 备份工具链
特别注意：storageClassName 必须显式声明，K8s 不会自动 fallback；且 PVC 的 resources.requests.storage 一旦绑定 PV，后续扩容需底层存储支持在线 resize（如 CSI 插件启用 ExpandVolume）。
连接池参数不调等于裸奔
在容器里用 mysql33/mysql 或 mysql2 时，connectionLimit 不能照搬物理机配置。一个 2C4G 的 Pod，设成 50 个连接大概率触发 OOMKilled —— 因为每个连接平均吃 10–15MB 内存，加上 InnoDB buffer pool 预留，很容易超限。
-
waitForConnections: true必开，否则请求直接抛PoolClosedError -
queueLimit: 0表示不限队列长度，但得配合上游熔断（如 Envoy 的 max_requests_per_connection） -
enableKeepAlive: true+keepAliveInitialDelay: 0防止 K8s Service 的 connection idle timeout 断连
更关键的是：环境变量里的 DB_HOST 必须指向 Headless Service（如 mysql-headless.default.svc.cluster.local），而非 ClusterIP，否则 DNS 轮询会破坏连接池局部性。
备份和恢复不能依赖 mysqldump
容器生命周期短，mysqldump 这种全量导出方式在百 GB 级别数据上既慢又占资源。云原生场景下真正可用的方案是：
- 利用底层存储快照（如 AWS EBS Snapshots、Ceph RBD Export）做秒级备份，再配合 binlog 流式归档实现 PITR
- 用
xtrabackup容器化执行，但必须挂载同一 PV 并指定--target-dir到共享路径，否则备份文件留在临时容器里就丢了 - Operator 自动拉起临时 Job 执行备份，并把结果推到对象存储（S3/OSS），同时更新自定义资源
MySQLBackup状态
最容易被忽略的一点：备份任务的 ServiceAccount 必须有 PV 的 use 权限，否则挂载失败静默退出，你以为备份成功了，其实什么都没干。
