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

前言

近期，測試環(huán)境出現(xiàn)了一次MySQL數(shù)據(jù)庫不斷自動重啟的問題，導致的原因是強行kill -9 殺掉數(shù)據(jù)庫進程導致，報錯信息如下：

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. 初探過程

之前出現(xiàn)過類似的情況時，是因為內(nèi)存不足，因日志中也有對應的提示：

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.

此測試環(huán)境物理內(nèi)存確實不大，且剩余內(nèi)存也不足，而且是作為另一個測試環(huán)境的從庫，內(nèi)存分配的也少。

之前一些環(huán)境也出現(xiàn)過類似的情況，通過調(diào)整參數(shù)及釋放內(nèi)存的等處理后可以正常啟動，于是嘗試著關閉一些臨時程序并調(diào)整MySQL上述幾個參數(shù)的值，如：

[mysqld]
max_connections = 50

然后重新啟動MySQL，結(jié)果依舊不斷重啟。

初步處理未果。

2.   添加innodb_force_recovery 解決不斷重啟

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

[mysqld]
innodb_force_recovery = 4

添加后，再次啟動MySQL，此時不再出現(xiàn)反復重啟。

查看數(shù)據(jù)庫日志，有提示 [Note] InnoDB: !!! innodb_force_recovery is set to 4 !!!如下：

因為此時可以打開數(shù)據(jù)庫，于是嘗試啟動從庫，但是此時報錯，提示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 以上的值可能永久導致數(shù)據(jù)文件損壞。如果生產(chǎn)環(huán)境出現(xiàn)類似問題務必先拷貝一份測試，在測試通過后再在生產(chǎn)環(huán)境處理）。此時可以將所有數(shù)據(jù)dump出，之后再恢復即可。

3.  innodb_force_recovery 參數(shù)

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

1 (SRV_FORCE_IGNORE_CORRUPT): 忽略檢查到的 corrupt 頁。盡管檢測到了損壞的 page 仍強制服務運行。一般設置為該值即可，然后 dump 出庫表進行重建。

2 (SRV_FORCE_NO_BACKGROUND): 阻止主線程的運行，如主線程需要執(zhí)行 full purge 操作，會導致 crash。 阻止 master thread 和任何 purge thread 運行。若 crash 發(fā)生在 purge 環(huán)節(jié)則使用該值。

3 (SRV_FORCE_NO_TRX_UNDO): 不執(zhí)行事務回滾操作。

4 (SRV_FORCE_NO_IBUF_MERGE): 不執(zhí)行插入緩沖的合并操作。如果可能導致崩潰則不要做這些操作。不要進行統(tǒng)計操作。該值可能永久損壞數(shù)據(jù)文件。若使用了該值，則將來要刪除和重建輔助索引。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN): 不查看重做日志，InnoDB 存儲引擎會將未提交的事務視為已提交。此時 InnoDB 甚至把未完成的事務按照提交處理。該值可能永久性的損壞數(shù)據(jù)文件。

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

注意：

1. 為了安全，當設置參數(shù)值大于 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. 如果碰到了由失敗的大規(guī)模導入或大量 ALTER TABLE 操作引起的 runaway rollback，則可 kill 掉 mysqld 線程然后設置 innodb_force_recovery = 3 使數(shù)據(jù)庫重啟后不進行 rollback。然后刪除導致 runaway rollback 的表； 如果表內(nèi)的數(shù)據(jù)損壞導致不能 dump 整個表內(nèi)容。那么附帶 order by primary_key desc 從句的查詢或許能夠 dump 出損壞部分之后的部分數(shù)據(jù)；

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。