dbaplus社群 19小时前
突发!rm -rf数据目录,MySQL故障导致大数据平台彻底瘫痪
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

MySQL作为CDH元数据库,因备库故障误删主库数据目录导致大数据平台瘫痪。文章分享了故障修复过程,包括锁定数据库、定位删除文件句柄、恢复数据文件、校验文件一致性等步骤,并分析了Linux文件删除机制、MySQL依赖句柄等技术原理。强调元数据管理脆弱性与运维流程漏洞的危害,提出预防措施如权限控制、多级备份、自动化巡检及升级老旧版本。

🔍锁定数据库是关键步骤,通过设置数据库只读和FLUSH TABLES WITH READ LOCK阻止写入,确保数据一致性。

📂恢复数据文件需分类处理,共享表空间文件如ibdata1和日志文件需先恢复,独立表空间文件如.ibd文件随后处理,表结构文件.frm通过备库复制或创建表产生。

🧪校验文件一致性是最后一步,通过解除表空间绑定和重新绑定操作,系统自动校验文件与.frm是否匹配,确保数据完整性。

🔧技术原理方面,Linux文件删除机制仅移除索引,MySQL依赖句柄访问数据,当进程仍持有句柄时,数据未清除,理解这点是恢复关键。

🛡️预防措施至关重要,需以核心生产组件级别防护MySQL,严格权限控制、多级备份、自动化巡检及升级老旧版本是避免灾难的关键。

詹姆斯邦德007 2025-07-20 08:03 广东

元数据管理脆弱性与运维流程漏洞,一下子全部暴露出来了……

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/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


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、恢复表结构文件

--从备库复制.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

阅读原文

跳转微信打开

Fish AI Reader

Fish AI Reader

AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

FishAI

FishAI

鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

联系邮箱 441953276@qq.com

相关标签

MySQL 元数据管理 大数据平台 故障修复 运维流程
相关文章