12人参与 • 2025-07-22 • 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
使用如下工具:
dmesg | grep -i error dmesg | grep -i sda # 根据你使用的磁盘设备
重点关注如:
buffer i/o error on device /dev/sda3, logical block 123456 ext4-fs error (device sda3): ...
mysqldump
、xtrabackup
、cp
等方式备份未受影响的库/表。可通过 flush tables with read lock;
锁定全局读取;
或直接将 mysql 实例切换为只读:
set global read_only = on;
badblocks -sv /dev/sda > badblocks.txt
fsck
、e2fsck
使用映射坏块文件排查表空间损坏。ls -lh /var/lib/mysql/databasename/ file /var/lib/mysql/databasename/table.ibd
可配合 strace -f -p $(pidof mysqld)
跟踪是否某个 .ibd
文件访问时报错。
方法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 表。
e2fsck -l badblocks.txt /dev/sda3
ddrescue
拷贝数据至新磁盘;值 | 含义 | 风险级别 |
---|---|---|
1 | 跳过 insert buffer 的恢复 | 安全 |
2 | 跳过 redo log 的应用 | 中 |
3 | 跳过 undo log 恢复 | 中 |
4 | 不执行 purge 操作 | 高 |
5 | 不执行 insert buffer 合并 | 高 |
6 | 禁止双写缓冲,跳过一切恢复流程 | 极高 |
步骤 | 行动 | 目的 |
---|---|---|
1 | 确认日志、dmesg、坏块位置 | 确认是否真为磁盘故障 |
2 | 备份健康数据 | 防止坏块扩散影响 |
3 | 使用 truncate 或 rename + drop | 规避触发 i/o 错误 |
4 | 启用 innodb_force_recovery 修复 | 数据导出和表结构清理 |
5 | 标记坏块或更换磁盘 | 根除问题源头 |
如果你能提供 mysqld.err
或 dmesg
日志中具体的报错信息,我可以帮你进一步诊断。需要我协助你写具体的修复操作脚本也可以。
到此这篇关于mysql磁盘坏块处理的全流程的文章就介绍到这了,更多相关mysql磁盘坏块处理内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论