MySQL Forcing InnoDB Recovery
2016-03-23 15:50
477 查看
Forcing InnoDB Recovery
MySQL非正常重启或者磁盘故障可能导致MySQL数据文件损坏。这种情况下,如果没有可用的备份文件则可使用innodb_force_recovery选项强制InnoDB引擎启动。这时一些后台操作不会运行,可以较为安全的dump出数据库中的表。
innodb_force_recovery选项可选的值为0-6,默认也即正常情况下值为0,在发生故障需要强制启动时可在MySQL配置文件[mysqld]节添加innodb_force_recovery = 1配置(或者其他值)。3或者以下的值对于强制重启后dump数据来说相对安全,可能个别损坏的页上的一些数据会丢失。4或者以上的值相对危险因为数据文件可能永久性的损坏。6这个值最为危险。
当innodb_force_recovery值大于0时InnoDB会阻止INSERT、UPDATE、DELETE操作。MySQL5.6.15以后4及以上的值使InnoDB为只读模式。
几个取值的意义:
1 (SRV_FORCE_IGNORE_CORRUPT)
尽管检测到了损坏的页扔强制服务器运行。一本情况设置为该值即可,然后dump出库表进行重建。
2 (SRV_FORCE_NO_BACKGROUND)
阻止master thread和任何purge thread运行。若崩溃发生在purge环节则使用该值
3 (SRV_FORCE_NO_TRX_UNDO)
崩溃恢复后不运行事务回滚
4 (SRV_FORCE_NO_IBUF_MERGE)
阻止插入缓冲合并操作。如果可能导致崩溃则不要做这些操作。不要进行统计操作。该值可能永久损坏数据文件。若使用了该值,则将来要删除和重建辅助索引。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库时不查看undo日志。此时InnoDB甚至把未完成的事务按照提交处理。该值可能永久性的损坏数据文件。
6 (SRV_FORCE_NO_LOG_REDO)
恢复时不做redo log roll-forward。使数据库页处于废止状态,继而可能引起B树或者其他数据库结构更多的损坏。
在值小于等于3时可以通过SELECT来dump表,可以drop或者create表。MySQL5.6.27后大于3的值也支持DROP TABLE;
如果事先知道哪个表导致了崩溃则可drop掉这个表。如果碰到了由失败的大规模导入或大量ALTER TABLE操作引起的runaway rollback,则可kill掉mysqld线程然后设置 innodb_force_recovery为3使数据库重启后不进行rollback。然后删除导致runaway rollback的表;
如果表内的数据损毁导致不能dump整个表内容。那么附带ORDER BY primary_key DESC 从句的查询或许能够dump出损毁部分之后的部分数据;
若使用更高的innodb_force_recovery值,那么一些损坏的数据结构可能引起复杂的查询无法运行。此时可能只能运行最基本的SELECT * FROM T语句。
需要注意的是,这仅是紧急情况下的一种补救,不能依赖于这个办法,最好的办好还是做好数据备份工作,包括全备份和日志备份。确定要使用该方案是要确保有原始损坏数据的副本。4以上的值可能永久导致数据文件损坏。务必在测试环境测试通过后再在生产环境使用。
MySQL非正常重启或者磁盘故障可能导致MySQL数据文件损坏。这种情况下,如果没有可用的备份文件则可使用innodb_force_recovery选项强制InnoDB引擎启动。这时一些后台操作不会运行,可以较为安全的dump出数据库中的表。
innodb_force_recovery选项可选的值为0-6,默认也即正常情况下值为0,在发生故障需要强制启动时可在MySQL配置文件[mysqld]节添加innodb_force_recovery = 1配置(或者其他值)。3或者以下的值对于强制重启后dump数据来说相对安全,可能个别损坏的页上的一些数据会丢失。4或者以上的值相对危险因为数据文件可能永久性的损坏。6这个值最为危险。
当innodb_force_recovery值大于0时InnoDB会阻止INSERT、UPDATE、DELETE操作。MySQL5.6.15以后4及以上的值使InnoDB为只读模式。
几个取值的意义:
1 (SRV_FORCE_IGNORE_CORRUPT)
尽管检测到了损坏的页扔强制服务器运行。一本情况设置为该值即可,然后dump出库表进行重建。
2 (SRV_FORCE_NO_BACKGROUND)
阻止master thread和任何purge thread运行。若崩溃发生在purge环节则使用该值
3 (SRV_FORCE_NO_TRX_UNDO)
崩溃恢复后不运行事务回滚
4 (SRV_FORCE_NO_IBUF_MERGE)
阻止插入缓冲合并操作。如果可能导致崩溃则不要做这些操作。不要进行统计操作。该值可能永久损坏数据文件。若使用了该值,则将来要删除和重建辅助索引。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库时不查看undo日志。此时InnoDB甚至把未完成的事务按照提交处理。该值可能永久性的损坏数据文件。
6 (SRV_FORCE_NO_LOG_REDO)
恢复时不做redo log roll-forward。使数据库页处于废止状态,继而可能引起B树或者其他数据库结构更多的损坏。
在值小于等于3时可以通过SELECT来dump表,可以drop或者create表。MySQL5.6.27后大于3的值也支持DROP TABLE;
如果事先知道哪个表导致了崩溃则可drop掉这个表。如果碰到了由失败的大规模导入或大量ALTER TABLE操作引起的runaway rollback,则可kill掉mysqld线程然后设置 innodb_force_recovery为3使数据库重启后不进行rollback。然后删除导致runaway rollback的表;
如果表内的数据损毁导致不能dump整个表内容。那么附带ORDER BY primary_key DESC 从句的查询或许能够dump出损毁部分之后的部分数据;
若使用更高的innodb_force_recovery值,那么一些损坏的数据结构可能引起复杂的查询无法运行。此时可能只能运行最基本的SELECT * FROM T语句。
需要注意的是,这仅是紧急情况下的一种补救,不能依赖于这个办法,最好的办好还是做好数据备份工作,包括全备份和日志备份。确定要使用该方案是要确保有原始损坏数据的副本。4以上的值可能永久导致数据文件损坏。务必在测试环境测试通过后再在生产环境使用。
相关文章推荐
- MySQL数据库的基本操作
- 【MySQL解惑】索引简介
- MySQL Workbench使用及教程
- MySQL5.7新特性之Multi-Source多源复制
- mysql字符函数简析
- MySQL 字符串相关函数简析
- 版本引发的血案check the manual that corresponds to your MySQL server version for the right syntax
- Jena读取Mysql数据的本体数据
- MySQL5.6相比5.5的新特性之GTID
- MySQL数据类型--常用数据类型总结
- mysql创建用户以及授权
- MySQL MHA配置
- MySql各种优化
- MySQL 级联删除需要注意的几点
- mysql 时间戳转换为日期
- MySQL主从复制的安装配置
- MySQL多表查询核心优化
- mysql 统计连续登录天数
- MySQL使用游标批量处理进行表操作
- mysql死锁