MySQL磁盘坏块处理的全流程

MySQL 磁盘坏块问题的处理总体流程

下面是推荐的分阶段处理流程，适用于生产环境，强调数据保护、风险评估、逐步推进：

第一阶段：问题确认与隔离

1.1 检查 MySQL 日志确认症状

查看 mysqld.err 或 MySQL 日志是否存在以下关键词：

• InnoDB: Operating system error number 5
• InnoDB: Unable to read page
• InnoDB: corruption
• Got error -1 from storage engine
• IO error 5 / IO error 13
• 实例崩溃、自动重启堆栈信息（signal 11）

1.2 确认是否磁盘 I/O 层问题

使用如下工具：

dmesg | grep -i error
dmesg | grep -i sda  # 根据你使用的磁盘设备

重点关注如：

Buffer I/O error on device /dev/sda3, logical block 123456
EXT4-fs error (device sda3): ...

第二阶段：应急保护与备份

2.1 立即备份其他健康数据

• 使用 mysqldump、xtrabackup、cp 等方式备份未受影响的库/表。
• 防止坏块扩大损害。

2.2 停止写入请求

可通过 FLUSH TABLES WITH READ LOCK; 锁定全局读取；

或直接将 MySQL 实例切换为只读：

SET GLOBAL read_only = ON;

第三阶段：诊断坏块位置与影响

3.1 使用 badblocks 工具检测磁盘坏块

badblocks -sv /dev/sda > badblocks.txt

• 可配合 fsck、e2fsck 使用映射坏块文件排查表空间损坏。

3.2 确认受损数据文件位置（特别是 .ibd 文件）

ls -lh /var/lib/mysql/databasename/
file /var/lib/mysql/databasename/table.ibd

可配合 strace -f -p $(pidof mysqld) 跟踪是否某个 .ibd 文件访问时报错。

第四阶段：修复受影响表或表空间

4.1 若只影响单表，可尝试以下修复操作：

方法A：导出可导出的数据后删除表

SELECT * FROM problem_table INTO OUTFILE '/tmp/backup.csv';
TRUNCATE TABLE problem_table;
DROP TABLE problem_table;

方法B：将表移出数据目录再尝试 DROP

systemctl stop mysqld
mv /var/lib/mysql/dbname/problem_table.ibd /tmp/
systemctl start mysqld

# 然后登录 MySQL 执行：
DROP TABLE dbname.problem_table;

注意这样会让 InnoDB 报告表空间文件不存在，但通常可跳过 DROP 阶段的 crash。

方法C：使用 innodb_force_recovery 修复

编辑 my.cnf 添加：

[mysqld]
innodb_force_recovery=1

数值从 1 到 6 逐级递增（数值越高风险越大，建议从 1 开始测试）

然后重启 MySQL，再尝试导出或 DROP 表。

第五阶段：系统层修复或替换磁盘

5.1 标记/屏蔽坏块（临时措施，不推荐长期使用）

e2fsck -l badblocks.txt /dev/sda3

5.2 若坏块不可控，推荐更换磁盘

• 使用 ddrescue 拷贝数据至新磁盘；
• 全量备份 + 恢复到新设备是最终手段。

附：innodb_force_recovery 参数说明

总结：MySQL 磁盘坏块处理建议

如果你能提供 mysqld.err 或 dmesg 日志中具体的报错信息，我可以帮你进一步诊断。需要我协助你写具体的修复操作脚本也可以。

到此这篇关于MySQL磁盘坏块处理的全流程的文章就介绍到这了,更多相关MySQL磁盘坏块处理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论