Mysql8斷電崩潰解決
一、概述
單機Mysql8數(shù)據(jù)庫服務器運行過程中突然斷電,導致數(shù)據(jù)庫崩潰,無法重啟。
二、查找原因
查看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] ,找不到磁盤文件。通過上述日志可以得知:數(shù)據(jù)庫出現(xiàn)錯誤,無法重啟。
原因:為了保護數(shù)據(jù),InnoDB使用校驗和(與頁儲存在一起)。當InnoDB從磁盤讀取時,它計算每個頁的校驗和,并與磁盤加載的校驗和進行比較。如果值是不同的,可能真的發(fā)生了一些錯誤。InnoDB將關(guān)閉MySQL服務器,以防止進一步的邏輯或物理損壞。
三、解決方案
1.如何找出損壞發(fā)生的原因
沒有通用的解決方案。最典型的是有一些硬件問題,例如:物理磁盤或內(nèi)存故障,壞的驅(qū)動器/控制器,甚至操作系統(tǒng)內(nèi)核的bug。下面是一些建議:
在Linux平臺上,有時會重置頁緩存能解決這個問題:
echo 2 > /proc/sys/vm/drop_caches
檢查系統(tǒng)日志有沒有可能的硬件故障。
如果InnoDB每次在特定頁崩潰,最典型的是物理磁盤發(fā)生故障:運行對于你的OS /硬件的詳細磁盤診斷。
如果崩潰是隨機的且不在相同查詢重復,可能是RAM故障:運行詳細的RAM診斷。
在MySQL關(guān)閉時,用innochecksum工具檢查InnoDB文件是有幫助的。
作者這里故障原因是斷電導致數(shù)據(jù)出現(xiàn)問題,只能重裝Mysql。
2.如何從損壞中恢復
最重要的是執(zhí)行詳細的硬件診斷,以消除問題擴散的機會。如果操作系統(tǒng)I / O緩存是磁盤讀損壞的原因,重置緩存或重新啟動操作系統(tǒng)應有助于消除當前的問題,數(shù)據(jù)庫可能會重新運作。
有時唯一的解決辦法是在有效恢復模式下備份數(shù)據(jù)。
筆者后面嘗試強制啟動,可以啟動Mysql,但是數(shù)據(jù)庫只能讀不能寫,通過日志又找不到損壞的數(shù)據(jù)表,無奈,只能先備份數(shù)據(jù)庫,然后重裝Mysql。
修改數(shù)據(jù)庫,一直報錯:
running in read_only mode 1836
將mysql改為強制啟動:
在my.ini中【mysqld】節(jié)點下加上
innodb_force_recovery=0
然后對數(shù)據(jù)庫進行備份。
備份方式:
一、數(shù)據(jù)庫備份
第一種:(cmd窗口使用)
在命令提示符用mysqldump命令行備份數(shù)據(jù)庫。
命令格式
mysqldump -u用戶名 -p 數(shù)據(jù)庫名 > 保存名.sql
范例:
mysqldump -uroot -p dataname > d:\data.sql
(導出數(shù)據(jù)庫dataname到data.sql文件)
提示輸入密碼時,輸入該數(shù)據(jù)庫用戶名的密碼。
第二種:指定導出備份編碼
mysqldump -u root -p密碼 --default-character-set=數(shù)據(jù)編碼 數(shù)據(jù)庫名稱> data.sql
案例:
mysqldump -u root -p123456 --default-character-set=utf8 discuss_chi>d:/data.sql
mySQL數(shù)據(jù)庫在windows環(huán)境下備份與恢復:
二,恢復數(shù)據(jù)庫,一共二種方式。
第一種;定義還原編碼類型(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數(shù)據(jù)庫控制臺,
如在運行中輸入:mysql -u root -p
mysql>use databasename;
1、確定數(shù)據(jù)庫默認編碼,比如編碼為gbk,將讀入途徑編碼同樣設(shè)為gbk,命令為:
set names gbk;(導入數(shù)據(jù)出現(xiàn)亂碼的時候用平常不用)
2、然后使用source命令,后面參數(shù)為腳本文件(如這里用到的.sql)
mysql>source d:\data.sql;
備份后,重裝Mysql,恢復數(shù)據(jù)庫。
到此這篇關(guān)于Mysql8斷電崩潰解決的文章就介紹到這了,更多相關(guān)Mysql8斷電崩潰內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
MySQL使用IF語句及用case語句對條件并結(jié)果進行判斷?
這篇文章主要介紹了MySQL使用IF語句及用case語句對條件并結(jié)果進行判斷,文章通過圍繞主題展開詳細的內(nèi)容介紹,具有一定的參考價值,需要的小伙伴可以參考一下2022-09-09Ubuntu下啟動、停止、重啟MySQL,查看錯誤日志命令大全
這篇文章主要介紹了Ubuntu下啟動、停止、重啟MySQL,查看錯誤日志命令大全,需要的朋友可以參考下2014-06-06Mysql?optimize?table?時報錯:Temporary?file?write?fail的解決
這篇文章主要介紹了Mysql?optimize?table?時報錯:Temporary?file?write?fail的解決方案,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-09-09