MySQL 8.0.11 無故崩潰怎么辦

本篇文章為大家展示了MySQL 8.0.11 無故崩潰怎么辦，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

MySQL 8.0.11 無故崩潰的crash日志：

2018-09-04T02:01:13.313544Z 21276 [Warning] [MY-010055] [Server] IP address '192.168.114.125' could not be resolved: Name or service not known

2018-09-04T04:57:10.808864Z 0 [Warning] [MY-010909] [Server] /usr/sbin/mysqld: Forcing close of thread 21592  user: 'BI@BL'.

2018-09-04T04:57:10.809204Z 0 [Warning] [MY-010909] [Server] /usr/sbin/mysqld: Forcing close of thread 21578  user: 'BI@BL'.

2018-09-04T04:57:10.811552Z 0 [Warning] [MY-010909] [Server] /usr/sbin/mysqld: Forcing close of thread 21242  user: 'BI@BL'.

2018-09-04T04:57:10.811681Z 0 [Warning] [MY-010909] [Server] /usr/sbin/mysqld: Forcing close of thread 21579  user: 'BI@BL'.

2018-09-04T04:57:10.815922Z 0 [Warning] [MY-010909] [Server] /usr/sbin/mysqld: Forcing close of thread 21311  user: 'BI@BL'.

2018-09-04T04:57:14.426047Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.11)  MySQL Community Server - GPL.

2019-12-09T06:02:30.162866Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.11) starting as process 21276

2019-12-09T06:03:01.852081Z 0 [ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: page0cur.cc:1182

InnoDB: thread 139750246643456

InnoDB: We intentionally generate a memory trap.

InnoDB: Submit a detailed bug report to http://bugs.mysql.com.

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/8.0/en/forcing-innodb-recovery.html

InnoDB: about forcing recovery.

06:03:01 UTC - 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.

Attempting to collect some information that could help diagnose the problem.

As this is a crash and something is definitely wrong, the information

collection process might fail.

日志顯示MySQL數據庫崩潰了。

修復崩潰數據庫。

當MySQL服務異常重啟失敗后，可以通過配置參數innodb_force_recovery來對MySQL服務進行修復啟動。

參數innodb_force_recovery選項：

1 (SRV_FORCE_IGNORE_CORRUPT): 忽略檢查到的 corrupt 頁。盡管檢測到了損壞的 page 仍強制服務運行。一般設置為該值即可，然后 dump 出庫表進行重建。 2 (SRV_FORCE_NO_BACKGROUND): 阻止主線程的運行，如主線程需要執行 full purge 操作，會導致 crash。 阻止 master thread 和任何 purge thread 運行。若 crash 發生在 purge 環節則使用該值。 3 (SRV_FORCE_NO_TRX_UNDO): 不執行事務回滾操作。 4 (SRV_FORCE_NO_IBUF_MERGE): 不執行插入緩沖的合并操作。如果可能導致崩潰則不要做這些操作。不要進行統計操作。該值可能永久損壞數據文件。若使用了該值，則將來要刪除和重建輔助索引。 5 (SRV_FORCE_NO_UNDO_LOG_SCAN): 不查看重做日志，InnoDB 存儲引擎會將未提交的事務視為已提交。此時 InnoDB 甚至把未完成的事務按照提交處理。該值可能永久性的損壞數據文件。

6 (SRV_FORCE_NO_LOG_REDO): 不執行前滾的操作?；謴蜁r不做 redo log roll-forward。使數據庫頁處于廢止狀態，繼而可能引起 B 樹或者其他數據庫結構更多的損壞。

參數innodb_force_recovery設置：

在配置文件中的mysqld模塊添加參數innodb_force_recovery。

[mysqld]

innodb_force_recovery    =     N

然后按照1-6啟動MySQL服務。

1-5都失敗，6終于把數據庫服務拉起來了。

數據庫啟動后是只讀模式，需要把數據導出到別的地方還原出來。

上述內容就是MySQL 8.0.11 無故崩潰怎么辦，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。