针对 Bitnami MySQL Helm Chart 在 Kubernetes 环境下的主从故障，这里整理了一套从快速恢复到彻底重建的完整修复方案。
一、 故障现象与根因分析
在 Bitnami 部署的 MySQL 集群中，最常见的故障表现为从库（Secondary）Pod 陷入CrashLoopBackOff状态。
核心现象：从库容器反复重启，日志中通常会出现Lock wait timeout exceeded（锁等待超时）或Cannot replicate because the source purged required binary logs（无法复制，主库已清理所需的 binlog）等致命错误。
根因剖析：
升级锁死循环：Bitnami 的容器启动脚本默认会执行mysql_upgrade。如果从库之前发生过异常中断，元数据表可能残留未释放的锁，导致升级脚本中的ALTER TABLE语句超时失败，进而触发容器无限重启。
Binlog 断层：即使手动修复了锁超时问题，由于从库落后主库过多https://www.kuazhi.com/，主库早已清理了从库所需的 Binlog，导致 GTID 复制链路彻底断裂，无法通过简单的START SLAVE恢复。
二、 阶段一：打破死循环，恢复容器启动
在重建数据之前，必须先让从库 Pod 能够正常启动。
1. 尝试环境变量跳过升级（快速尝试）
修改从库的 StatefulSet，在环境变量中注入跳过升级的参数：
env:
- name: MYSQL_SKIP_UPGRADE
value: "yes"
如果重建 Pod 后依然执行升级，则采用以下手动介入方案。
2. 手动覆盖启动命令（强制介入）
休眠容器：通过kubectl edit statefulset mysql-secondary，将容器的command覆盖为["bash", "-c", "sleep infinity"]，让 Pod 保持 Running 状态但不启动 MySQL 服务。
清理元数据：进入容器内部，手动启动 MySQL 服务（跳过升级脚本），连接数据库并清理损坏的元数据表或强制完成升级。
恢复启动：清理完成后，移除command覆盖，让容器恢复默认的 Bitnami 启动脚本。
三、 阶段二：基于物理克隆重建从库（核心修复）
由于 Binlog 已经丢失，传统的增量同步已失效。此时最高效的方案是利用 MySQL 8.0 原生的CLONE INSTANCE插件，从主库进行一次全量的物理克隆。
1. 主库准备
登录主库（Primary），安装 Clone 插件并创建专用的克隆用户：
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
CREATE USER 'clone_user'@'%' IDENTIFIED BY 'password';
GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'%';
2. 从库执行克隆
登录刚刚修复好启动状态的从库，执行克隆指令，将主库的数据完整拉取过来：
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
CLONE INSTANCE FROM 'clone_user'@'<主库IP>:3306' IDENTIFIED BY 'password';
注意：克隆操作会清空从库现有的所有数据，并自动配置好 GTID 复制通道。
3. 验证复制状态
克隆完成后，在从库执行SHOW SLAVE STATUS\G。当看到Slave_IO_Running: Yes和Slave_SQL_Running: Yes，且Seconds_Behind_Master: 0时，标志着主从复制链路已彻底恢复正常。
四、 避坑与预防建议
存储类（StorageClass）陷阱：确保主从节点使用的 PVC 绑定了支持ReadWriteOnce且具备拓扑感知（如WaitForFirstConsumer）的 StorageClass，避免因跨可用区调度导致 PVC 挂载失败。
密码特殊字符：在 Helm 的values.yaml中配置密码时，避免使用@、/等未转义的特殊字符，否则会导致 Bitnami 的 initContainer 解析 Secret 失败。
资源限制：为 MySQL Pod 设置合理的 CPU 和内存 Limit。克隆操作会消耗大量临时空间和 IO，资源不足会导致克隆中途失败。
通过这套“先救活容器，再物理克隆”的组合拳，可以最大程度地减少数据丢失风险，并在最短时间内恢复集群的高可用状态。
需要我把对应的 Helm values.yaml 配置示例也补上吗？包括主从部署、密码管理和 Clone 插件的配置。
