Mysql8断电崩溃解决
一、概述
单机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.98InnoDB: 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平台上,有时会重置页缓存能解决这个问题:
?1 | 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】节点下加上
?1 | innodb_force_recovery=0 |
然后对数据库进行备份。
备份方式:
一、数据库备份
第一种:(cmd窗口使用)
在命令提示符用mysqldump命令行备份数据库。
命令格式
mysqldump -u用户名 -p 数据库名 > 保存名.sql
范例:
1 | mysqldump -uroot -p dataname > d:\data.sql |
(导出数据库dataname到data.sql文件)
提示输入密码时,输入该数据库用户名的密码。
第二种:指定导出备份编码
?1 | mysqldump -u root -p密码 --default-character-set=数据编码 数据库名称> data.sql |
案例:
?1 | mysqldump -u root -p123456 --default-character-set=utf8 discuss_chi>d:/data.sql |
mySQL数据库在windows环境下备份与恢复:
二,恢复数据库,一共二种方式。
第一种;定义还原编码类型(cmd窗使用)
定义编码导入:
1 | mysql -u root -p --default-character-set=utf8 -f dataname<d:/dis.sql |
如果乱码使用二进导入
?1 | mysql -u root -p --default-character-set=binary -f dataname<d:/dis.sql |
第二种:
source 命令(mysql控制台窗口使用)
进入mysql数据库控制台,
如在运行中输入:mysql -u root -p
?1 | mysql>use databasename; |
1、确定数据库默认编码,比如编码为gbk,将读入途径编码同样设为gbk,命令为:
set names gbk;(导入数据出现乱码的时候用平常不用)
2、然后使用source命令,后面参数为脚本文件(如这里用到的.sql)
1 | mysql>source d:\data.sql; |
备份后,重装Mysql,恢复数据库。
到此这篇关于Mysql8断电崩溃解决的文章就介绍到这了,更多相关Mysql8断电崩溃内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家!
原文链接:https://blog.csdn.net/goodmentc/article/details/129255977
1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。