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）需优先升级，避免工具链脱节。