MySQL不停地自動重啓的解決方法

這篇文章主要給大家介紹了關於MySQL不停地自動重啓的解決方法，文中通過示例代碼介紹的非常詳細，對大家學習或者使用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 樹或者其他數據庫結構更多的損壞。

注意：

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

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對神馬文庫的支持。