MySQL不停地自動重啟怎麼辦

 近期，測試環境出現了一次MySQL資料庫不斷自動重啟的問題，導致的原因是強行kill -9 殺掉資料庫進程導致，報錯信息如下：

2019-07-24T01:14:53.769512Z 0 [Note] Executing 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' to get a list of tables using the deprecated partition engine. You may use the startup option '--disable-partition-engine-check' to skip this check.
2019-07-24T01:14:53.769516Z 0 [Note] Beginning of list of non-natively partitioned tables
01:14:53 UTC - mysqld got signal 11 ;
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.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=33554432
read_buffer_size=8388608
max_used_connections=0
max_threads=501
thread_count=4
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4478400 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f486900e000
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f4846172820 thread_stack 0x80000
/usr/local/mysql5.7/bin/mysqld(my_print_stacktrace+0x2c)[0xed481c]
/usr/local/mysql5.7/bin/mysqld(handle_fatal_signal+0x461)[0x7a15a1]
/lib64/libpthread.so.0(+0xf7e0)[0x7f498697c7e0]
/usr/local/mysql5.7/bin/mysqld(_ZN12ha_federated7rnd_posEPhS0_+0x2f)[0x12bcc3f]
/usr/local/mysql5.7/bin/mysqld(_ZN7handler10ha_rnd_posEPhS0_+0x172)[0x804a12]
/usr/local/mysql5.7/bin/mysqld(_ZN14Rows_log_event24do_index_scan_and_updateEPK14Relay_log_info+0x1e3)[0xe50e23]
/usr/local/mysql5.7/bin/mysqld(_ZN14Rows_log_event14do_apply_eventEPK14Relay_log_info+0x716)[0xe50196]
/usr/local/mysql5.7/bin/mysqld(_ZN9Log_event11apply_eventEP14Relay_log_info+0x6e)[0xe48fde]
/usr/local/mysql5.7/bin/mysqld(_Z26apply_event_and_update_posPP9Log_eventP3THDP14Relay_log_info+0x1f0)[0xe8d6f0]
/usr/local/mysql5.7/bin/mysqld(handle_slave_sql+0x163d)[0xe9a0fd]
/usr/local/mysql5.7/bin/mysqld(pfs_spawn_thread+0x1b4)[0x1209414]
/lib64/libpthread.so.0(+0x7aa1)[0x7f4986974aa1]
/lib64/libc.so.6(clone+0x6d)[0x7f4984c6bc4d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 2
Status: NOT_KILLED

You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.

1. 初探過程

之前出現過類似的情況時，是因為記憶體不足，因日誌中也有對應的提示：

key_buffer_size=33554432
read_buffer_size=8388608
max_used_connections=0
max_threads=501
thread_count=4
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4478400 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

此測試環境物理記憶體確實不大，且剩餘記憶體也不足，而且是作為另一個測試環境的從庫，記憶體分配的也少。

之前一些環境也出現過類似的情況，通過調整參數及釋放記憶體的等處理後可以正常啟動，於是嘗試著關閉一些臨時程式並調整MySQL上述幾個參數的值，如：

[mysqld]
max_connections = 50

然後重新啟動MySQL，結果依舊不斷重啟。

初步處理未果。

2.   添加innodb_force_recovery 解決不斷重啟

在配置文件my.cnf添加innodb_force_recovery 先處理不斷重啟的問題

[mysqld]
innodb_force_recovery = 4

添加後，再次啟動MySQL，此時不再出現反覆重啟。

查看資料庫日誌，有提示 [Note] InnoDB: !!! innodb_force_recovery is set to 4 !!!如下：

因為此時可以打開資料庫，於是嘗試啟動從庫，但是此時報錯，提示Table 'mysql.slave_relay_log_info' is read only.

此時再看錯誤日誌，如下

因此，本次啟動時，innodb_force_recovery 設置為 4，在MySQL 5.6.15 以後，當 innodb_force_recovery 的值大於等於 4 的時候，InnoDB 表處於只讀模式，因啟動複製時需要將信息寫入表中，所以此時報錯。

註： 因設置為1-3 時，依舊未生效，因此我在處理時設置的為4（4 以上的值可能永久導致數據文件損壞。如果生產環境出現類似問題務必先拷貝一份測試，在測試通過後再在生產環境處理）。此時可以將所有數據dump出，之後再恢復即可。

3.  innodb_force_recovery 參數

innodb_force_recovery 可以設置為 1-6，大的值包含前面所有小於它的值的影響。

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): 不執行前滾的操作。恢復時不做 redo log roll-forward。使資料庫頁處於廢止狀態，繼而可能引起 B 樹或者其他資料庫結構更多的損壞。

註意：

• 為了安全，當設置參數值大於 0 後，可以對錶進行 select, create, drop 操作,但 insert, update 或者 delete 這類操作是不允許的。
• MySQL 5.6.15 以後，當 innodb_force_recovery 的值大於等於 4 的時候，InnoDB 表處於只讀模式。
• 在值小於等於 3 時可以通過 select 來 dump 表，可以 drop 或者 create 表。
• MySQL 5.6.27 後大於 3 的值也支持 DROP TABLE； 如果事先知道哪個表導致了崩潰則可 drop 掉這個表。
• 如果碰到了由失敗的大規模導入或大量 ALTER TABLE 操作引起的 runaway rollback，則可 kill 掉 mysqld 線程然後設置 innodb_force_recovery = 3 使資料庫重啟後不進行 rollback。然後刪除導致 runaway rollback 的表； 如果表內的數據損壞導致不能 dump 整個表內容。那麼附帶 order by primary_key desc 從句的查詢或許能夠 dump 出損壞部分之後的部分數據；

耿小廚已開通個人微信公眾號，想進一步溝通或想瞭解其他文章的同學可以關註我