突发！rm -rf数据目录，MySQL故障导致大数据平台彻底瘫痪

MySQL作为CDH的元数据库，集中管理Hive表结构、分区信息、数据位置及权限配置，是Hive/Impala高效查询的基石，这不用户由于MySQL5.5.6备库故障，需要修复，而误删除主库数据目录，导致大数据平台彻底瘫痪。

本次分享故障的修复过程及最终复盘，本次恢复的关键就是业务不能停止，以最快的速度，恢复持有的句柄，详细的过程如下

一、锁定数据库

-- 设置数据库只读SET GLOBAL read_only = 1; -- 锁表阻止写入FLUSH TABLES WITH READ LOCK;

二、定位删除文件句柄

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

三、分类恢复数据文件

1、恢复共享表空间文件

# 恢复ibdata1（句柄号以实际输出为准）cat /proc/$pid/fd/64 > /var/lib/data/ibdata1chown mysql:mysql /var/lib/data/ibdata1
# 恢复日志文件（如ib_logfile0）cat /proc/$pid/fd/65 > /var/lib/data/ib_logfile0chown mysql:mysql /var/lib/data/ib_logfile0

2、恢复独立表空间

示例：恢复表mydb.tab1的ibd文件cat /proc/$pid/fd/66 > /var/lib/data/mydb/tab1.ibdchown mysql:mysql /var/lib/data/mydb/tab1.ibd

3、恢复表结构文件

--从备库复制.frm文件（需与原表结构一致）cp /path/to/backup/mydb/tab1.frm /var/lib/data/mydb/chown mysql:mysql /var/lib/data/mydb/tab1.frm如果遇到.frm文件，通过创建表产生

四、校验frm与ibd文件一致性

步骤1：解除表空间绑定（需表已存在）--删除当前.ibd文件链接ALTER TABLE 表名 DISCARD TABLESPACE;
步骤2：重新绑定并校验-- 系统自动校验文件与.frm是否匹配ALTER TABLE 表名 IMPORT TABLESPACE;

五、技术原理

1、Linux文件删除机制

rm 仅移除文件索引，当进程仍持有句柄时，数据仍存于磁盘，通过 /proc//fd 可访问。

2、MySQL依赖句柄

InnoDB引擎在运行时保持 .ibd 文件句柄打开，删除后文件状态为 deleted，但内容未清除。

3、版本差异

MySQL 5.6+：默认开启 innodb_file_per_table，优先使用独立 .ibd 文件

MySQL 8.0+：取消 .frm 文件，表结构存于系统表空间（mysql.ibd）

六、总结

此次事故暴露了元数据管理脆弱性与运维流程漏洞，CDH高度依赖MySQL，元数据丢失直接导致集群瘫痪，需以“核心生产组件”级别防护MySQL。

预防优于修复，严格权限控制（如sudo审计）、多级备份（本地+云+日志）、自动化巡检（表空间校验）是避免类似灾难的关键。

技术债代价高昂，老旧版本（如MySQL 5.5）需优先升级，避免工具链脱节。

作者丨詹姆斯邦德007

来源丨公众号：IT邦德（ID：jeamesDB ）

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn