这个问题出现在MySQL5.7之后的版本,主要的原因是MySQL会在最新的check point完成后都会在redolog写一个一字节的MLOG_CHECKPOINT标记,用来标记在此之前的redo都已checkpoint完成。
如果处于任何原因没有找到这个标记,那么整个redolog文件都会被忽略。出现这个错误的话,最好是有备份进行恢复,如果没有做好备份,那只能采取非常规的启动方式,但可能造成数据丢失。
介绍
MySQL是一个关系型数据库管理系统,由瑞典MySQLAB公司开发,属于Oracle旗下产品。MySQL是最流行的关系型数据库管理系统之一,在WEB应用方面,MySQL是最好的RDBMS应用软件之一。
MySQL是一种关系型数据库管理系统,关系数据库将数据保存在不同的表中,而不是将所有数据放在一个大仓库内,这样就增加了速度并提高了灵活性。
MySQL数据库在升级到5.7版本后,和之前的版本有些不一样,没有data文件夹,我们都知道MySQL数据库文件是保存在data文件夹中的,网上有人说把5.6版本的data文件夹拷贝一个,这种说法听听都不靠谱,我也试了,确实能够登录,但是无法修改管理员密码,下面还是给个标准的解决方法。\x0d\x0a安装好MySQL5.7后,打开cmd命令窗口,并且进入到MySQL安装目录中的bin目录,然后输入如下命令回车即可:\x0d\x0amysqld --initialize-insecure --user=mysql\x0d\x0a执行完上面命令后,MySQL会自建一个data文件夹,并且建好默认数据库,登录的用户名为root,密码为空,后面的 *** 作就跟之前版本一样了故障处理移除当前使用的 redo log 文件,然后可以试着启动数据库,结果启动失败!
提示:
[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.
这样的错误,这是因为 MySQL writer 线程按照配置的时间间隔以 page 为单位刷新 buffer 数据到磁盘。当数据刷新到磁盘的时候,新写入磁盘的 page 包含了较新的 LSN,此时系统 system 表空间头的 LSN 并没有同步更新,通常这是检查点线程的工作。在正常的崩溃恢复中,MySQL 可以借助 redo log 来进行前滚和回滚,但是此时 redo log 已经被我们删掉了,MySQL 无法进行恢复 *** 作。此时,我们设置 innodb_force_recovery=3 来强制启动 MySQL,仍然启动不成功,改成 4 后启动了!
再使用 mysqldump 导出备份,结果噩梦又降临了!MySQL 又 crash 了。
提示:
InnDB: Failed to find tablespace for table......
设置参数 innodb_force_recovery=5,数据库仍然启动失败,再设置成 6,启动成功!用 sqldump 顺利把数据备份出来了!
再初始化数据库,把刚刚备份的数据库导入,数据库恢复成功完成!
参数说明
这里的关键是设置 innodb_force_recovery 参数,对应这个参数的说明如下:
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:不执行前滚的 *** 作。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)