mysql資料庫不能啟動（mysql 不能啟動）

本文目錄一覽：

1、mysql 資料庫無法啟動
2、mysql啟動不了服務啟動不了該怎麼辦
3、mysql無法啟動
4、mysql 服務無法啟動

mysql 資料庫無法啟動

故障處理

移除當前使用的 redo log 文件，然後可以試著啟動資料庫，結果啟動失敗！

提示：

[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.

這樣的錯誤，這是因為 MySQL writer 線程按照配置的時間間隔以 page 為單位刷新 buffer 數據到磁碟。當數據刷新到磁碟的時候，新寫入磁碟的 page 包含了較新的 LSN，此時系統 system 表空間頭的 LSN 並沒有同步更新，通常這是檢查點線程的工作。在正常的崩潰恢復中，MySQL 可以藉助 redo log 來進行前滾和回滾，但是此時 redo log 已經被我們刪掉了，MySQL 無法進行恢復操作。此時，我們設置 innodb_force_recovery=3 來強制啟動 MySQL，仍然啟動不成功，改成 4 後啟動了！

再使用 mysqldump 導出備份，結果噩夢又降臨了！MySQL 又 crash 了。

提示：

InnDB: Failed to find tablespace for table……

設置參數 innodb_force_recovery=5，資料庫仍然啟動失敗，再設置成 6，啟動成功！用 sqldump 順利把數據備份出來了！

再初始化資料庫，把剛剛備份的資料庫導入，資料庫恢復成功完成！

參數說明

這裡的關鍵是設置 innodb_force_recovery 參數，對應這個參數的說明如下：

1. SRV_FORCE_IGNORE_CORRUPT：忽略檢查到的 corrupt 頁；

2. SRV_FORCE_NO_BACKGROUND：阻止主線程的運行，如主線程需要執行 full purge 操作，會導致 crash；

3. SRV_FORCE_NO_TRX_UNDO：不執行事務回滾操作；

4. SRV_FORCE_NO_IBUF_MERGE：不執行插入緩衝的合併操作；

5. SRV_FORCE_NO_UNDO_LOG_SCAN：不查看重做日誌，InnoDB 存儲引擎會將未提交的事務視為已提交；

6. SRV_FORCE_NO_LOG_REDO：不執行前滾的操作。

mysql啟動不了服務啟動不了該怎麼辦

一、無法訪問系統資源

MySQL 不能訪問啟動需要的資源是造成而 MySQL 無法啟動的一個常見原因，如：文件，埠等。由於 linux 中用於啟動 mysqld 進程的 mysql 用戶通常是不能登陸的，可以使用類似下面的命令檢查文件的訪問許可權。

sudo -u mysql touch /var/lib/mysql/b

找出問題後，修改對應文件或目錄的許可權或屬主後通常可以解決問題。但有時 mysql 用戶有訪問文件和目錄的許可權，但仍然會被拒絕訪問，例如下面這個例子：

mysql system sudo -u mysql touch /home/mysql/data/a

mysql create table t1 (

id int primary key,n varchar(10

) data directory

ERROR 1030 (HY000): Got error 168 from storage engine

測試說明 mysql 用戶有這個目錄的訪問許可權，但創建文件還是失敗，這種情況讓很多人困惑，這個時候通常是 mysqld 進程的訪問被 linux 的 selinux 或 apparmor 給阻止了，大家可以看到創建的表不是在 mysql 的默認目錄下面，因此 selinux 或 apparmor 的 policy 裡面沒有包含這個目錄的訪問許可權，此時只要對應的修改 policy 就行了，當然把 selinux 或 apparmor 停了也行。

有時雖然對系統資源有訪問的許可權，但系統資源已經被佔用：

mysqld –no-defaults –console –user mysql

2020-11-03T03:36:07.519419Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19) starting as process 21171

2020-11-03T03:36:07.740347Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11

這個故障產生的原因是另外一個 mysqld 進程已經啟動並佔用了對應的文件。

二、參數設置錯誤

參數設置錯誤造成 MySQL 無法啟動的原因也非常常見，此時先要檢查 MySQL 啟動時會調用的參數，下面的命令可以查詢 MySQL 啟動時調用參數文件的順序：

$ mysqld –verbose –help | grep “Default options ” -A 1

Default options are read from the following files in the given order:

/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf

知道了 MySQL 參數文件的調用順序，我們就可以檢查對應的參數文件，找出其中的錯誤，如果覺得參數文件的可讀性不強，可以使用下面的命令顯示 mysqld 程序將要調用的參數：

$ mysqld –print-defaults

/usr/sbin/mysqld would have been started with the following arguments:

……

注意這個命令顯示完參數後就退出，不會真正運行 mysqld。這個命令和 my_print_defaults mysqld 完全是等價的，只不過後者的顯示方式是一行一個參數。

然後開始對可疑的參數進行調試，我個人喜歡加的參數和順序如下：

1. 在 mysqld 後加上第一個參數 –no-defaults ，這個參數的作用是通知 mysqld 在啟動的時候不要讀任何參數文件；

2. 第二個參數是 –console，這個參數會把錯誤信息輸出到屏幕上，這個參數帶來的一個弊端是所有的信息都輸出到屏幕上，讓屏幕顯得比較亂，但對於我們調試卻是很方便的；

3. 第三個參數是 –log-error-verbosity=3，這個參數會顯示詳細的日誌；

4. 然後再在後面加上有把握的參數，可以一次只加一個參數，然後啟動 mysqld，採用排除法逐步找出錯誤的參數。

mysql無法啟動