一、事件概述
本次事件表现为：
- Kubernetes 集群异常
- MySQL Pod 无法正常启动
- 数据库服务中断
- 后续恢复过程中出现数据乱码问题
经排查，本次故障并非数据库系统自身原发问题，而是由基础网络配置异常引发的连锁故障。
二、影响范围
-
受影响系统：Kubernetes 集群内业务系统
-
核心组件：MySQL（5.7.44）
-
影响类型：
- 数据库服务不可用
- 业务读写中断
-
数据影响：
- 数据未完全丢失
- 但原实例 InnoDB 结构受损，需通过重建恢复
三、事件时间线（简化）
- 现场出现网络异常（节点 IP 被占用）
- Kubernetes 集群出现异常（节点通信异常 / Pod 异常）
- MySQL Pod 非正常退出
- MySQL 重启后 InnoDB crash recovery 失败
- 数据库无法启动（报错 redo log 检查点缺失）
- 通过
innodb_force_recovery=6强制拉起实例 - 导出数据并重建 MySQL 实例
- 导入过程中出现字符集问题（中文乱码）
- 修复字符集配置并重新导入，最终恢复业务
四、根因分析
4.1 直接根因
主机 IP 被现场设备（摄像头）占用，导致网络冲突。
该问题直接引发：
- Kubernetes 节点网络通信异常
- Pod 调度及运行异常
- 关键服务（MySQL）运行环境失效
4.2 次级影响
由于 MySQL Pod 运行在 Kubernetes 中：
- 节点网络异常导致 Pod 非正常中断（非优雅退出）
- InnoDB 未完成正常 checkpoint / redo flush
在 MySQL 重启时触发：
InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT
Plugin 'InnoDB' registration as a STORAGE ENGINE failed
说明：
InnoDB redo log 链不完整
crash recovery 无法完成
数据库无法启动
4.3 恢复期问题
在数据恢复过程中，又出现：
- MySQL 字符集配置未生效（server/client 为 latin1）
- dump 文件使用
SET NAMES utf8 - 表结构为
utf8mb4
导致：UTF-8 数据 → 按 latin1 解析 → 再写入 utf8mb4
最终造成：中文数据二次编码污染（乱码）
五、技术分析
5.1 为什么 MySQL 无法启动
InnoDB 依赖 redo log 完成 crash recovery：
- redo log 中缺失
MLOG_CHECKPOINT - 数据页与日志不一致
- InnoDB 无法确定恢复边界
因此直接 abort，导致：mysqld: Failed to initialize builtin plugins
5.2 为什么 innodb_force_recovery=6 能启动
该参数作用：
- 跳过 redo log recovery
- 禁用部分 InnoDB 校验机制
- 强制只读模式启动
日志表现：
InnoDB: Started in read only mode
skipping log redo
说明： 数据库已处于“抢救态”，非正常运行状态
5.3 为什么数据会乱码
三层字符集不一致：
| 表 | utf8mb4 |
| dump | utf8 |
| MySQL server | latin1 |
导致链路：
UTF-8 → latin1误解码 → 再写入 → 数据污染
典型表现：
人文风光 → 人文风光
5.4 为什么 NFS 风险更高
本环境 MySQL 使用：
- PVC（nfs-client）
风险点：
- 非本地盘
- IO 延迟不可控
- 异常中断后更容易出现数据不一致
- 不适合承载单实例数据库核心数据
六、处理过程
- 定位网络问题，修复 IP 冲突
- 恢复 Kubernetes 集群状态
- 排查 MySQL 无法启动问题
- 使用
innodb_force_recovery=6强制启动 - 导出数据库数据（逻辑备份）
- 重建 MySQL 实例
- 修复字符集配置（utf8mb4）
- 修改 dump 文件字符集声明
- 重新导入数据
- 验证数据一致性及业务恢复
七、最终结果
- MySQL 实例已重建完成
- 数据成功恢复（通过逻辑导出导入）
- 字符集问题已修复
- 业务系统恢复正常
八、问题总结
本次事件属于典型的：基础设施问题引发的数据库级连锁故障
并叠加：恢复阶段配置不一致引入的新问题
九、改进建议
9.1 网络与基础设施
- 建立 IP 地址管理机制（IPAM）
- 禁止手工随意占用服务器 IP
- 增加冲突检测机制
9.2 Kubernetes 层
- 节点异常自动告警
- Pod 异常退出监控
- 关键服务（数据库）设置更高保护策略
9.3 数据库层
-
禁止 MySQL 单实例运行在 NFS 上
-
使用：
- 本地盘 / 云盘（块存储）
- 或托管数据库
9.4 数据安全
- 定期逻辑备份（mysqldump）
- 定期恢复演练
- 避免只依赖单一存储
9.5 配置规范
统一字符集：
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci
导入导出统一：
--default-character-set=utf8mb4
十、结论
本次故障根因明确：
由现场 IP 冲突引发 Kubernetes 集群异常，进而导致 MySQL Pod 非正常中断，最终造成 InnoDB 数据恢复失败。
数据库问题属于结果，而非起因。
