一、問題

斷電重啟機器後，mariadb服務啟動失敗。使用mysql -uroot -p 連線時報錯
Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

二、常見解決方案

網上的解決方法大致為 ①空間不足（df -h 檢視） ②許可權不足（/var/lib資料夾）chown -R mysql:mysql /vdb1/lib/ ③修改my.cnf ,重新配置socket路徑 ④使用mysql -h127.0.0.1 -uroot -p連線 ⑤幹掉殭屍程序 ps -ef | grep mysql

三、本次解決方案

1、以上方法對於本人當前環境均沒有用，使用④方法，報錯為

ERROR 2003 (HY000): Can't connect to MySQL server on "host" (111)

2、經大神指導，在mariadb日誌（/var/log/mariadb/mariadb.log）中看到 mysqld got signal 6

Version: ‘5.5.64-MariaDB’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MariaDB Server
200617 22:54:24 InnoDB: Assertion failure in thread 140689172858624 in file fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
200617 22:54:24 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
 

3、根據錯誤，網上查詢，得到可通過設定恢復模式啟動mysql

[設定恢復模式啟動mysql官網](https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html)

編輯配置檔案
vim /etc/my.cnf
新增配置項：
innodb_force_recovery = 1
其中後面的值設定為1、如果1不想再逐步增加為2/3/4/5/6等。直到能啟動mysql為止，若不想嘗試直接寫6即可；
對於含有業務的伺服器，最好是慢慢上調，以免永久性損壞資料。值得意義在官網有說明，摘錄如下：

Only set innodb_force_recovery to a value greater than 0 in an emergency situation, so that you can start InnoDB

 and dump your tables. Before doing so, ensure that you have a backup copy of your database in case you need to recreate it. Values of 4 or greater can permanently corrupt data files. Only use an innodb_force_recovery setting of 4 or greater on a production server instance after you have successfully tested the setting on a separate physical copy of your database. When forcing InnoDB recovery, you should always start with innodb_force_recovery=1 and only increase the value incrementally, as necessary.

設定完成即重啟mariadb服務：
systemctl restart mariadb
若重啟失敗，或啟動時一直列印：200618 17:45:56 InnoDB: Waiting for the background threads to start
則在my.cnf中的[mysqld]中增加：innodb_purge_thread=0再嘗試重啟。
啟動成功後測試資料庫連線：mysql -uroot -p;

4、備份資料庫

備份資料庫方法在另一篇文章:mysql備份與恢復

5、備份資料檔案與重啟

關閉服務
systemctl stop mariadb
備份檔案
mv /var/lib/mysql /root/mysql_back

正常模式在啟動mysql：
vim /etc/my.cnf
註釋配置項：

#innodb_force_recovery = 1
#innodb_purge_thread=0

再重啟：
systemctl restart mariadb

6、資料恢復

mysql備份與恢復

至此大功告成！

四、經驗與教訓

出問題，可以先根據表面的錯誤去尋找答案，但是在試了各種方法後還不能解決，就需要換個思路，去仔細閱讀日誌
如果其值內容較複雜，則優先看error日誌

解決問題的過程中，也要稍加總結分類已查到的解決方案，以免重複試錯。

這篇文章僅僅簡單記述一下解決問題的經過，同樣的錯誤，可能有各種各樣的理由。歡迎大家留言該錯誤的更多解決方案，以便於後面的人更快解決問題！另外亦歡迎大家可以關注我的微信公眾號，方便利用零碎時間互相交流。共勉！

路漫漫其修遠兮，吾將上下而求索。。。