Mysql8断电崩溃解决

oyezitan

已于 2023-02-28 10:28:46 修改

阅读量798

点赞数

分类专栏：数据库文章标签：数据库 mysql 服务器

于 2023-02-28 10:19:12 首次发布

本文链接：https://blog.csdn.net/goodmentc/article/details/129255977

版权

数据库专栏收录该内容

10 篇文章 0 订阅

订阅专栏

一、概述

单机Mysql8数据库服务器运行过程中突然断电，导致数据库崩溃，无法重启。

二、查找原因

查看mysql运行错误日志：WIN-SOTMI68HRV6.err （在Data目录下）

InnoDB: End of page dump
InnoDB: Page may be a system page
2023-02-01T09:31:02.878917Z 0 [Warning] [MY-010915] [Server] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
2023-02-01T09:31:02.882631Z 0 [System] [MY-010116] [Server] C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld.exe (mysqld 8.0.23) starting as process 3496
2023-02-01T09:31:02.923391Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2023-02-01T09:31:05.964384Z 1 [ERROR] [MY-011971] [InnoDB] Tablespace 'innodb_system' Page [page id: space=0, page number=5] log sequence number 3275776865 is in the future! Current system log sequence number 3197057036.
2023-02-01T09:31:05.966225Z 1 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2023-02-01T09:31:05.98



InnoDB: End of page dump
InnoDB: Page may be a system page
2023-02-01T11:03:39.767939Z 1 [ERROR] [MY-011906] [InnoDB] Database page corruption on disk or a failed file read of page [page id: space=4294967278, page number=101]. You may have to recover from a backup.
 len 16384; hex 4359822100000065000000000000000000000000c340647700060000000000000000ffffffeefffffffe0000000000000000ffffffff0000ffffffff0000ffffffee000000580932000000d600000154fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

很明显[ERROR] ，找不到磁盘文件。通过上述日志可以得知：数据库出现错误，无法重启。
原因：为了保护数据，InnoDB使用校验和（与页储存在一起）。当InnoDB从磁盘读取时，它计算每个页的校验和，并与磁盘加载的校验和进行比较。如果值是不同的，可能真的发生了一些错误。InnoDB将关闭MySQL服务器，以防止进一步的逻辑或物理损坏。

三、解决方案

1.如何找出损坏发生的原因

没有通用的解决方案。最典型的是有一些硬件问题，例如：物理磁盘或内存故障，坏的驱动器/控制器，甚至操作系统内核的bug。下面是一些建议：

在Linux平台上，有时会重置页缓存能解决这个问题：
echo 2 > /proc/sys/vm/drop_caches

检查系统日志有没有可能的硬件故障。
如果InnoDB每次在特定页崩溃，最典型的是物理磁盘发生故障：运行对于你的OS /硬件的详细磁盘诊断。
如果崩溃是随机的且不在相同查询重复，可能是RAM故障：运行详细的RAM诊断。
在MySQL关闭时，用innochecksum工具检查InnoDB文件是有帮助的。

作者这里故障原因是断电导致数据出现问题，只能重装Mysql。

2.如何从损坏中恢复

最重要的是执行详细的硬件诊断，以消除问题扩散的机会。如果操作系统I / O缓存是磁盘读损坏的原因，重置缓存或重新启动操作系统应有助于消除当前的问题，数据库可能会重新运作。
有时唯一的解决办法是在有效恢复模式下备份数据。

笔者后面尝试强制启动，可以启动Mysql，但是数据库只能读不能写，通过日志又找不到损坏的数据表，无奈，只能先备份数据库，然后重装Mysql。

修改数据库，一直报错：

running in read_only mode 1836

将mysql改为强制启动：
在my.ini中【mysqld】节点下加上

  innodb_force_recovery=0

然后对数据库进行备份。
备份方式：

一、数据库备份
第一种：（cmd窗口使用）
在命令提示符用mysqldump命令行备份数据库。
命令格式
mysqldump -u用户名 -p 数据库名 > 保存名.sql
范例：

mysqldump -uroot -p dataname > d:\data.sql

（导出数据库dataname到data.sql文件）
提示输入密码时，输入该数据库用户名的密码。

第二种：指定导出备份编码

mysqldump -u root -p密码 --default-character-set=数据编码 数据库名称> data.sql

案例：

mysqldump -u root -p123456 --default-character-set=utf8 discuss_chi>d:/data.sql

mySQL数据库在windows环境下备份与恢复：
二，恢复数据库，一共二种方式。
第一种；定义还原编码类型（cmd窗使用）
定义编码导入:

mysql -u root -p --default-character-set=utf8 -f dataname<d:/dis.sql

如果乱码使用二进导入

mysql -u root -p --default-character-set=binary -f dataname<d:/dis.sql

第二种：
source 命令（mysql控制台窗口使用）
进入mysql数据库控制台，
如在运行中输入:mysql -u root -p
mysql>use databasename;
1、确定数据库默认编码，比如编码为gbk,将读入途径编码同样设为gbk，命令为：
set names gbk;（导入数据出现乱码的时候用平常不用）
2、然后使用source命令，后面参数为脚本文件（如这里用到的.sql）
mysql>source d:\data.sql;

备份后，重装Mysql，恢复数据库。