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 

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選項：

(SRV_FORCE_IGNORE_CORRUPT): 忽略檢查到的 corrupt 頁。儘管檢測到了損壞的 page 仍強制服務執行。一般設定為該值即可，然後 dump 出庫表進行重建。
(SRV_FORCE_NO_BACKGROUND): 阻止主執行緒的執行，如主執行緒需要執行 full purge 操作，會導致 crash。 阻止 master thread 和任何 purge thread 執行。若 crash 發生在 purge 環節則使用該值。
(SRV_FORCE_NO_TRX_UNDO): 不執行事務回滾操作。
(SRV_FORCE_NO_IBUF_MERGE): 不執行插入緩衝的合併操作。如果可能導致崩潰則不要做這些操作。不要進行統計操作。該值可能永久損壞資料檔案。若使用了該值，則將來要刪除和重建輔助索引。
(SRV_FORCE_NO_UNDO_LOG_SCAN): 不檢視重做日誌，InnoDB 儲存引擎會將未提交的事務視為已提交。此時 InnoDB 甚至把未完成的事務按照提交處理。該值可能永久性的損壞資料檔案。
(SRV_FORCE_NO_LOG_REDO): 不執行前滾的操作。恢復時不做 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 無故崩潰

相關文章