一同事反饋有一MySQL實(shí)例因?yàn)閿嚯娭?,啟?dòng)不了。用了innodb_force_recovery=6也無效,于是前往查看。
排查過程:
最早的啟動(dòng)信息里面,沒有任何報(bào)錯(cuò),只有一行[ERROR] Aborting提示,如下:
![](http://img.jbzj.com/file_images/article/201804/2018428163746731.jpg?201832816388)
接著同事用了innodb_force_recovery=6的方式,才多出現(xiàn)了如下的錯(cuò)誤提示,但仍無法啟動(dòng)成功,這個(gè)時(shí)候,我才決定去看個(gè)究竟。
![](/d/20211018/16c2e8fb6b6790da92e107458a739750.gif)
過濾啟動(dòng)日志,grep ERROR /data/mysql/3306/mysql_run.err
可以看到,全部報(bào)錯(cuò)主要如下:
![](/d/20211018/c22550a355d173690564e26f9bcaf93b.gif)
MySQL大多數(shù)不能啟動(dòng)的原因,都是系統(tǒng)數(shù)據(jù)庫(kù)的原因,看來這個(gè)也不例外。
嘗試使用帶--skip-grant-tables的方式登錄系統(tǒng),竟然成功了。
/usr/local/mysql/bin/mysqld_safe --defaults-file=/data/mysql/3306/my.cnf --user=mysql --skip-grant-tables
緊接著,抓緊對(duì)innodb進(jìn)行檢查,執(zhí)行:
innochecksum ibdata1
后發(fā)現(xiàn)沒有任何輸出。
接著執(zhí)行mysqlcheck,果然修復(fù)一些mysql庫(kù)下面的表報(bào)錯(cuò)。之后以正常方式重啟系統(tǒng),MySQL恢復(fù)正常。
mysqlcheck -u root -p --repair -A
總結(jié):
1、MySQL并沒有那么脆弱,沒必要在損壞的時(shí)候就通過備份恢復(fù)的方式執(zhí)行還原,費(fèi)時(shí)費(fèi)力;
2、啟動(dòng)過程中,可以通過設(shè)置--skip-grant-tables或者設(shè)置innodb_force_recovery(這個(gè)參數(shù)要修改cnf文件)來讓MySQL跳過一些檢查,使實(shí)例成功啟動(dòng);
3、啟動(dòng)之后,可以執(zhí)行數(shù)據(jù)備份或者導(dǎo)出數(shù)據(jù),并且嘗試對(duì)實(shí)例做修復(fù);
4、該實(shí)例出現(xiàn)這個(gè)問題,懷凝是因?yàn)榕c實(shí)時(shí)存盤的參數(shù)設(shè)置不當(dāng)有關(guān)。
以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
您可能感興趣的文章:- MySQL 查看鏈接及殺掉異常鏈接的方法
- MySQL手動(dòng)注冊(cè)binlog文件造成主從異常的原因
- MySQL數(shù)據(jù)庫(kù)連接異常匯總(值得收藏)
- mysql innodb 異常修復(fù)經(jīng)驗(yàn)分享
- MySQL定義異常和異常處理詳解
- MySQL存儲(chǔ)過程中一些基本的異常處理教程
- 分析一個(gè)MySQL的異常查詢的案例
- MySQL異常處理淺析
- 分析MySQL拋出異常的幾種常見解決方式