MySQL错误Got error -1 from storage engine

前言

之前正式服务器数据库挂掉了,被其他同事覆盖数据库,导致正在使用的数据库无法访问,并且所有配置全部丢失,幸好data数据存储在其他路径免受劫难。
在恢复之前,为避免有人往实例里写入内容,所以在my.cnf/my.ini(Linux=my.cnf,Windows=my.ini)内添加了innodb_force_recovery=4

正文

innodb_force_recovery影响整个innodb存储引擎的恢复状况

说明

在未配置属性innodb_force_recovery时,它默认值是0(表示可执行所有),并且不存在于my.cnf/my.ini内。
innodb_force_recovery的参数值可以为0-6,当其大于0时,可以对表进行select、create、drop操作,但insert、update、delete是不允许的。并且重要的一点是,当设置为大于0后,以下条目是包含状态:
1. (SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2. (SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行full purge操作,会导致crash。
3. (SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4. (SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5. (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交。
6. (SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。

附加

innodb_purge_threads 

该参数用于定义处理innodb的清除操作模式,默认的是定期回收无用数据的操作。在之前的几个版本中,清除操作是主线程的一部分,这意味着运行时它可能会堵塞其它的数据库操作。
从MySQL5.5.X版本开始,该操作运行于独立的线程中,并支持更多的并发数。用户可通过设置innodb_purge_threads配置参数来选择清除操作是否使用单独线程。
默认为0,即不启用。设置为 1 时表示使用单独的清除线程。

楼主因为设置过innodb_purge_threads=1,然后又在进行上面操作时更改了innodb_force_recovery=4,之后导致出现无限loop情况。
查询原因发现,mysql源码控制了这2个参数的设置,如果同时启用,则一直挂起在循环内,所以在开启innodb_force_recovery时,注意将innodb_purge_threads=0.

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值