17370845950

MySQL报错Got error 12或Input/output error时，需先通过dmesg、smartctl和dd测试确认是否为真实硬盘故障，再结合错误可复现性及系统日志综合判断。

MySQL 报错 Got error 12 from storage engine 或 Input/output error 怎么快速定位是不是硬盘坏了

这类错误大概率指向底层 I/O 异常，但不能一上来就换硬盘——先确认是 MySQL 自身行为触发的假性 I/O 错误，还是真实硬件故障。关键看错误是否可复现、是否伴随系统级日志异常。

• 立刻检查 dmesg -T | grep -i "ata\|nvme\|sd\|error"，出现 end_request: I/O error、timeout、aborted command 等字样，基本可判定磁盘/控制器异常
• 运行 smartctl -a /dev/sdX（替换为实际设备），重点关注 Reallocated_Sector_Ct、Current_Pending_Sector、UDMA_CRC_Error_Count 是否非零且持续增长
• 用 dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=direct 测试写入是否卡住或报 Input/output error；再用 dd if=/tmp/testfile of=/dev/null bs=1M iflag=direct 测试读取——任一失败即硬件层已不可靠
• 若 MySQL 错误只出现在特定表（如 SELECT * FROM broken_table 必现 I/O 错误），而其他表正常，优先怀疑该表对应文件（ibd 或 MYD）所在区域存在坏块，而非整盘故障

MySQL 崩溃后启动失败，提示 InnoDB: Database page corruption on disk 怎么抢救数据

InnoDB 页面损坏不等于数据全丢，只要 ibdata1 和 ib_logfile* 未被覆盖，且磁盘还能读出部分扇区，就有机会提取有效记录。

• 停止所有写入操作，立即对整个 MySQL 数据目录做 ddrescue -d -r3 /dev/sdX /mnt/rescue.img /mnt/rescue.log 镜像（避免反复读取坏道）
• 在镜像上尝试启动 MySQL：修改 my.cnf 加入 innodb_force_recovery = 1，逐级试到 6（仅 1–3 级允许 SELECT；4–6 级禁止 INSERT/UPDATE/DELETE）
• 能启动后，用 mysqldump --single-transaction --skip-lock-tables 导出尚可访问的库表；若导出中断，改用 mysqlpump 或直接拷贝 .ibd 文件（需匹配 MySQL 版本和页大小）
• 切勿在损坏实例上执行 ALTER TABLE ... ENGINE=InnoDB 或 OPTIMIZE TABLE——这些操作会强制重写页面，可能让残存数据彻底消失

使用 innodb_force_recovery 后仍无法启动，或者 mysqldump 报 Got error -1 from storage engine

说明 InnoDB 已无法解析事务日志或表空间头信息，常规恢复路径中断，必须转向二进制解析或专业工具。

• 用 strings /var/lib/mysql/yourdb/yourtable.ibd | head -50 检查是否还能看到明文字段名或业务数据——如果可见，说明数据页物理结构尚存，只是逻辑索引断裂
• 尝试 innodb-tools（如 ibdconnect 重建表空间头，ibd2sql 直接解析 ibd 文件提取行记录），注意其对 MySQL 版本和页大小（innodb_page_size）高度敏感
• 若服务器启用了 LVM，检查是否存在可用快照：lvs -o +seg_monitor，有则立即 lvconvert --merge 回滚（需逻辑卷未激活）
• 云环境（如 AWS RDS、阿里云 RDS）遇到此错误，应立刻停止实例并创建快照，不要自行挂载底层 EBS 卷——厂商快照机制可能保留更早时间点的干净副本

恢复后如何验证数据完整性，以及

预防下次再崩

恢复不是终点，没验证的“恢复”等于没恢复；而预防的关键在于把 I/O 压力从单点硬件上卸下来。

• 对比恢复前后 CHECKSUM TABLE your_table 结果（需启用 checksum_algorithm = INNODB），不一致说明行级数据已静默损坏
• 用 pt-table-checksum 对主从做一致性校验，重点看 Differences 列是否为 0；若从库也损坏，说明问题发生在 binlog 写入前，根源在主库存储层
• 禁用 innodb_doublewrite 是高风险操作，除非你有电池后备缓存（BBU）的 RAID 卡且确认其健康——否则务必保持开启
• 把 datadir 迁移到支持原子写（atomic write）的 NVMe 设备，并配置 innodb_flush_method = O_DIRECT_NO_FSYNC（MySQL 8.0.14+），可绕过内核页缓存减少 I/O 路径故障点

真正棘手的不是报错本身，而是错误发生时 MySQL 还在继续接受写入——这会让坏块扩散到更多页面。所以一旦发现 Input/output error，第一反应不是重启 mysqld，而是冻结写入、保现场、再诊断。