mysql 使用 Forcing InnoDB Recovery 恢复数据库

环境:

CentOS release 6.6 (Final)

Server version: 5.5.42-37.1-log Percona Server (GPL), Release 37.1, Revision 39acee0

现象:

数据库挂掉,重启报错

The server quit without updating PID file (/var/lib/mysql/cm.data.dingkai.com.pid).[失败]

日志:

150721 12:38:37  InnoDB: Database was not shut down normally!

InnoDB: Starting crash recovery.

InnoDB: Reading tablespace information from the .ibd files...

InnoDB: Restoring possible half-written data pages from the doublewrite

InnoDB: buffer...

InnoDB: Doing recovery: scanned up to log sequence number 9044491443

150721 12:38:37  InnoDB: Error: page 7 log sequence number 17979997238

InnoDB: is in the future! Current system log sequence number 9044491443.

InnoDB: Your database may be corrupt or you may have copied the InnoDB

这说明库在重启启动后需要做恢复,但是数据库的log出现坏块。

解决:

使用Forcing InnoDB Recovery 启动库并备份数据,重新建库。

关于innodb_force_recovery 参数值的描述如下:

As a safety measure, InnoDB prevents INSERTUPDATE, or DELETE operations when innodb_force_recovery is greater than 0.

  • 1 (SRV_FORCE_IGNORE_CORRUPT)

    Lets the server run even if it detects a corrupt page. Tries to make SELECT * FROM tbl_name jump over corrupt index records and pages, which helps in dumping tables.

  • 2 (SRV_FORCE_NO_BACKGROUND)

    Prevents the master thread and any purge threads from running. If a crash would occur during the purgeoperation, this recovery value prevents it.

  • 3 (SRV_FORCE_NO_TRX_UNDO)

    Does not run transaction rollbacks after crash recovery.

  • 4 (SRV_FORCE_NO_IBUF_MERGE)

    Prevents insert buffer merge operations. If they would cause a crash, does not do them. Does not calculate tablestatistics. This value can permanently corrupt data files. After using this value, be prepared to drop and recreate all secondary indexes.

  • 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

    Does not look at undo logs when starting the database: InnoDB treats even incomplete transactions as committed. This value can permanently corrupt data files.

  • 6 (SRV_FORCE_NO_LOG_REDO)

    Does not do the redo log roll-forward in connection with recovery. This value can permanently corrupt data files. Leaves database pages in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures.

在my.cnf文件配置参数

innodb_force_recovery = 6

innodb_purge_thread=0

注意: innodb_purge_thread 参数的设置为0 ,以免在配置别的值后,数据库启动会一直报错 InnoDB: Waiting for the background threads to start。

[[email protected] ~]# service mysql start

Starting MySQL (Percona Server)..[确定]

启动成功,接下来dump 数据,接着重建库就OK了!

时间: 2024-11-06 12:25:18

mysql 使用 Forcing InnoDB Recovery 恢复数据库的相关文章

MySQL · 引擎特性 · InnoDB 崩溃恢复过程

MySQL · 引擎特性 · InnoDB 崩溃恢复过程 在前面两期月报中,我们详细介绍了 InnoDB redo log 和 undo log 的相关知识,本文将介绍 InnoDB 在崩溃恢复时的主要流程. 本文代码分析基于 MySQL 5.7.7-RC 版本,函数入口为 innobase_start_or_create_for_mysql,这是一个非常冗长的函数,本文只涉及和崩溃恢复相关的代码. 在阅读本文前,强烈建议翻阅我们之前的两期月报:1. MySQL · 引擎特性 · InnoDB

Mysql binlog日志及binlog恢复数据库操作

初识MySQL 日志binlogMySQL重要log,二进制日志文件,记录所有DDL和DML语句(除select),事件形式记录,包含语句所执行的消耗时间,事务安全型.DDL(数据库定义语言),主要命令有create.alter.drop等.DDL主要定义或改变表table的结构.数据类型.建表时使用.MDL(数据操纵语言),主要命令有select.update.insert.delete. mysqlbinlog常见选项:--start-datetime:从二进制中读取指定时间戳.--stop

MySQL 8.0 InnoDB Cluster 恢复故障成员

InnoDB Cluster 一节点丢失初始化故障节点 systemctl stop mysqld rm -rf /var/lib/mysql/* systemctl start mysqld 导出正常节点的数据库,并传到故障节点 mysqldump --all-databases --triggers --routines --events --quick --single-transaction --flush-logs --master-data=2 > dbs.dump scp dbs.

使用MySQL命令行备份及恢复数据库

使用MySQL命令行,可以实现对数据库的备份以及恢复,下面就为您介绍使用MySQL命令行实现该功能的详细方法步骤,供您参考. MySQL命令行导出数据库:1,进入MySQL目录下的bin文件夹:cd MySQL中到bin文件夹的目录如我输入的命令行:cd C:\Program Files\MySQL\MySQL Server 4.1\bin(或者直接将windows的环境变量path中添加该目录) 2,导出数据库:mysqldump -u 用户名 -p 数据库名 > 导出的文件名 如我输入的命令

Mysql启停以及恢复备份恢复数据库

1.mysql启停 进入cmd 输入如下命令 net stop mysql(自己起的mysql名称) -------停 net strat mysql   --------------------------起 2.备份及恢复数据库 我只采用备份C:\ProgramData\MySQL\MySQL Server 5.1\data路径下的数据库文件夹(例如worktime) 备份脚本如下: color 0A --设置颜色title 工时管理数据库备份(请不要关闭,你可以最小化)!@echo off

Linux 文件系统引起的云盘文件系统异常导致 MySQL 数据页损坏事故恢复复盘

事故的起因是因为当我访问某个数据库的某个表的时候,MySQL 立即出现崩溃并且去查看 MySQL 的错误日志出现类似信息 2019-05-09T05:52:19.232564Z 1027 [ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=1668620387, page number=16777216], should be [page id: space=1321, page

MySQL授权用户及密码恢复设置

MySQL密码恢复及设置1.停止MySQL服务程序.2.跳过授权表启动MySQL服务程序skip-grant-tables(添加在配置文件)3.重设root密码(更新user表记录)4.以正常方式重启MySQL服务程序 例: 1.恢复数据库管理员密码(操作系统管理员有权限修改) #systemctl stop mysqld #vim /etc/my.cnf [mysqld] ... skip-grant-tables ... #systemctl start mysqld #mysql mysq

MySQL系列:innodb源码分析之redo log恢复

在上一篇<innodb源码分析之重做日志结构>中我们知道redo log的基本结构和日志写入步骤,那么redo log是怎么进行数据恢复的呢?在什么时候进行redo log的日志推演呢?redo log的推演只有在数据库异常或者关闭后,数据库重新启动时会进行日志推演,将数据库状态恢复到关闭前的状态.那么这个过程是怎么进行的呢?以下我们逐步来解析. 1.recv_sys_t结构 innodb在MySQL启动的时候,会对重做日志文件进行日志重做,重做日志是通过一个recv_sys_t的结构来进行数

Mysql 一次性备份导出/导入恢复所有数据库

Mysql 一次性备份导出/导入恢复所有数据库 有木有遇到过这种情况?电脑或者服务器需要重装系统?可是你电脑上存着n多个网站的数据库,怎么办?把数据库文件夹拷贝出来,重装系统之后再拷回去?如果你使用了InnoDB引擎,恐怕那样做会出麻烦的,一个一个往外导数据库?天哪,那要搞到何年何月啊?今天合肥网站制作向阳互联就来介绍一下如何一口气导出全部数据库,再把数据库恢复回来,其实利用mysqldump的-all-databases参数可以一口气把你数据库root用户下的所有数据库一口气导出到一个sql文