一、概述

單機(jī)Mysql8數(shù)據(jù)庫(kù)服務(wù)器運(yùn)行過(guò)程中突然斷電，導(dǎo)致數(shù)據(jù)庫(kù)崩潰，無(wú)法重啟。

二、查找原因

查看mysql運(yùn)行錯(cuò)誤日志：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] ，找不到磁盤(pán)文件。通過(guò)上述日志可以得知：數(shù)據(jù)庫(kù)出現(xiàn)錯(cuò)誤，無(wú)法重啟。

原因：為了保護(hù)數(shù)據(jù)，InnoDB使用校驗(yàn)和（與頁(yè)儲(chǔ)存在一起）。當(dāng)InnoDB從磁盤(pán)讀取時(shí)，它計(jì)算每個(gè)頁(yè)的校驗(yàn)和，并與磁盤(pán)加載的校驗(yàn)和進(jìn)行比較。如果值是不同的，可能真的發(fā)生了一些錯(cuò)誤。InnoDB將關(guān)閉MySQL服務(wù)器，以防止進(jìn)一步的邏輯或物理?yè)p壞。

三、解決方案

1.如何找出損壞發(fā)生的原因

沒(méi)有通用的解決方案。最典型的是有一些硬件問(wèn)題，例如：物理磁盤(pán)或內(nèi)存故障，壞的驅(qū)動(dòng)器/控制器，甚至操作系統(tǒng)內(nèi)核的bug。下面是一些建議：

在Linux平臺(tái)上，有時(shí)會(huì)重置頁(yè)緩存能解決這個(gè)問(wèn)題：

echo 2 > /proc/sys/vm/drop_caches

檢查系統(tǒng)日志有沒(méi)有可能的硬件故障。
如果InnoDB每次在特定頁(yè)崩潰，最典型的是物理磁盤(pán)發(fā)生故障：運(yùn)行對(duì)于你的OS /硬件的詳細(xì)磁盤(pán)診斷。
如果崩潰是隨機(jī)的且不在相同查詢重復(fù)，可能是RAM故障：運(yùn)行詳細(xì)的RAM診斷。
在MySQL關(guān)閉時(shí)，用innochecksum工具檢查InnoDB文件是有幫助的。

作者這里故障原因是斷電導(dǎo)致數(shù)據(jù)出現(xiàn)問(wèn)題，只能重裝Mysql。

2.如何從損壞中恢復(fù)

最重要的是執(zhí)行詳細(xì)的硬件診斷，以消除問(wèn)題擴(kuò)散的機(jī)會(huì)。如果操作系統(tǒng)I / O緩存是磁盤(pán)讀損壞的原因，重置緩存或重新啟動(dòng)操作系統(tǒng)應(yīng)有助于消除當(dāng)前的問(wèn)題，數(shù)據(jù)庫(kù)可能會(huì)重新運(yùn)作。
有時(shí)唯一的解決辦法是在有效恢復(fù)模式下備份數(shù)據(jù)。

筆者后面嘗試強(qiáng)制啟動(dòng)，可以啟動(dòng)Mysql，但是數(shù)據(jù)庫(kù)只能讀不能寫(xiě)，通過(guò)日志又找不到損壞的數(shù)據(jù)表，無(wú)奈，只能先備份數(shù)據(jù)庫(kù)，然后重裝Mysql。

修改數(shù)據(jù)庫(kù)，一直報(bào)錯(cuò)：

running in read_only mode 1836

將mysql改為強(qiáng)制啟動(dòng)：

在my.ini中【mysqld】節(jié)點(diǎn)下加上

innodb_force_recovery=0

然后對(duì)數(shù)據(jù)庫(kù)進(jìn)行備份。
備份方式：

一、數(shù)據(jù)庫(kù)備份

第一種：（cmd窗口使用）
在命令提示符用mysqldump命令行備份數(shù)據(jù)庫(kù)。
命令格式
mysqldump -u用戶名 -p 數(shù)據(jù)庫(kù)名 > 保存名.sql
范例：

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

（導(dǎo)出數(shù)據(jù)庫(kù)dataname到data.sql文件）
提示輸入密碼時(shí)，輸入該數(shù)據(jù)庫(kù)用戶名的密碼。

第二種：指定導(dǎo)出備份編碼

mysqldump -u root -p密碼 --default-character-set=數(shù)據(jù)編碼 數(shù)據(jù)庫(kù)名稱> data.sql

案例：

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

mySQL數(shù)據(jù)庫(kù)在windows環(huán)境下備份與恢復(fù)：

二，恢復(fù)數(shù)據(jù)庫(kù)，一共二種方式。

第一種；定義還原編碼類型（cmd窗使用）
定義編碼導(dǎo)入:

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

如果亂碼使用二進(jìn)導(dǎo)入

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

第二種：
source 命令（mysql控制臺(tái)窗口使用）
進(jìn)入mysql數(shù)據(jù)庫(kù)控制臺(tái)，

如在運(yùn)行中輸入:mysql -u root -p

mysql>use databasename;

1、確定數(shù)據(jù)庫(kù)默認(rèn)編碼，比如編碼為gbk,將讀入途徑編碼同樣設(shè)為gbk，命令為：
set names gbk;（導(dǎo)入數(shù)據(jù)出現(xiàn)亂碼的時(shí)候用平常不用）
2、然后使用source命令，后面參數(shù)為腳本文件（如這里用到的.sql）

mysql>source d:\data.sql;

備份后，重裝Mysql，恢復(fù)數(shù)據(jù)庫(kù)。

到此這篇關(guān)于Mysql8斷電崩潰解決的文章就介紹到這了,更多相關(guān)Mysql8斷電崩潰內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論