MySQL作为CDH的元数据库，集中管理Hive表结构、分区信息、数据位置及权限配置，是Hive/Impala高效查询的基石，这不用户由于MySQL5.5.56备库故障，需要修复，而误删除主库数据目录，导致大数据平台彻底瘫痪。
本次分享故障的修复过程及最终复盘，本次恢复的关键就是业务不能停止，以最快的速度，恢复持有的句柄，详细的过程如下
1.锁定数据库
-- 设置数据库只读 SET GLOBAL read_only = 1; -- 锁表阻止写入 FLUSH TABLES WITH READ LOCK;
2.定位删除文件句柄
mysql> SHOW VARIABLES LIKE 'datadir';
+---------------+------------------------+
| Variable_name | Value |
+---------------+------------------------+
| datadir | /usr/local/mysql/data/ |
+---------------+------------------------+
查看被删除但未释放的文件句柄
lsof | grep deleted | grep \
"/usr/local/mysql-5.5.56-linux-glibc2.5-x86_64/data" \
| awk '{print $2, $5, $10}' \
> /tmp/deleted_files.txt
3.分类恢复数据文件
3.1 恢复共享表空间文件
# 恢复ibdata1（句柄号以实际输出为准） cat /proc/$pid/fd/64 > /var/lib/data/ibdata1 chown mysql:mysql /var/lib/data/ibdata1 # 恢复日志文件（如ib_logfile0） cat /proc/$pid/fd/65 > /var/lib/data/ib_logfile0 chown mysql:mysql /var/lib/data/ib_logfile0
3.2 恢复独立表空间
示例：恢复表mydb.tab1的ibd文件 cat /proc/$pid/fd/66 > /var/lib/data/mydb/tab1.ibd chown mysql:mysql /var/lib/data/mydb/tab1.ibd
3.3 恢复表结构文件
--从备库复制.frm文件（需与原表结构一致） cp /path/to/backup/mydb/tab1.frm /var/lib/data/mydb/ chown mysql:mysql /var/lib/data/mydb/tab1.frm 如果遇到.frm文件，通过创建表产生
4.校验frm与ibd文件一致性
步骤1：解除表空间绑定（需表已存在） --删除当前.ibd文件链接 ALTER TABLE 表名 DISCARD TABLESPACE; 步骤2：重新绑定并校验 -- 系统自动校验文件与.frm是否匹配 ALTER TABLE 表名 IMPORT TABLESPACE;
5.技术原理
5.1 Linux文件删除机制
rm 仅移除文件索引，当进程仍持有句柄时，数据仍存于磁盘，通过 /proc//fd 可访问。
5.2 MySQL依赖句柄
InnoDB引擎在运行时保持 .ibd 文件句柄打开，删除后文件状态为 deleted，但内容未清除。
5.3 版本差异
MySQL 5.6+：默认开启 innodb_file_per_table，优先使用独立 .ibd 文件
MySQL 8.0+：取消 .frm 文件，表结构存于系统表空间（mysql.ibd）
6.总结
此次事故暴露了元数据管理脆弱性与运维流程漏洞，CDH高度依赖MySQL，元数据丢失直接导致集群瘫痪，需以“核心生产组件”级别防护MySQL。
预防优于修复，严格权限控制（如sudo审计）、多级备份（本地+云+日志）、自动化巡检（表空间校验）是避免类似灾难的关键。
技术债代价高昂，老旧版本（如MySQL 5.5）需优先升级，避免工具链脱节。
