前言

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

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)過類似的情況時(shí)，是因?yàn)閮?nèi)存不足，因日志中也有對(duì)應(yīng)的提示：

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.

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

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

[mysqld]
max_connections = 50

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

初步處理未果。

2.   添加innodb_force_recovery 解決不斷重啟

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

[mysqld]
innodb_force_recovery = 4

添加后，再次啟動(dòng)MySQL，此時(shí)不再出現(xiàn)反復(fù)重啟。

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

因?yàn)榇藭r(shí)可以打開數(shù)據(jù)庫(kù)，于是嘗試啟動(dòng)從庫(kù)，但是此時(shí)報(bào)錯(cuò)，提示Table 'mysql.slave_relay_log_info' is read only.

此時(shí)再看錯(cuò)誤日志，如下

因此，本次啟動(dòng)時(shí)，innodb_force_recovery 設(shè)置為 4，在MySQL 5.6.15 以后，當(dāng) innodb_force_recovery 的值大于等于 4 的時(shí)候，InnoDB 表處于只讀模式，因啟動(dòng)復(fù)制時(shí)需要將信息寫入表中，所以此時(shí)報(bào)錯(cuò)。

注： 因設(shè)置為1-3 時(shí)，依舊未生效，因此我在處理時(shí)設(shè)置的為4（4 以上的值可能永久導(dǎo)致數(shù)據(jù)文件損壞。如果生產(chǎn)環(huán)境出現(xiàn)類似問題務(wù)必先拷貝一份測(cè)試，在測(cè)試通過后再在生產(chǎn)環(huán)境處理）。此時(shí)可以將所有數(shù)據(jù)dump出，之后再恢復(fù)即可。

3.  innodb_force_recovery 參數(shù)

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

1 (SRV_FORCE_IGNORE_CORRUPT): 忽略檢查到的 corrupt 頁(yè)。盡管檢測(cè)到了損壞的 page 仍強(qiáng)制服務(wù)運(yùn)行。一般設(shè)置為該值即可，然后 dump 出庫(kù)表進(jìn)行重建。

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

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

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

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

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

注意：

1. 為了安全，當(dāng)設(shè)置參數(shù)值大于 0 后，可以對(duì)表進(jìn)行 select, create, drop 操作,但 insert, update 或者 delete 這類操作是不允許的。
2. MySQL 5.6.15 以后，當(dāng) innodb_force_recovery 的值大于等于 4 的時(shí)候，InnoDB 表處于只讀模式。
3. 在值小于等于 3 時(shí)可以通過 select 來 dump 表，可以 drop 或者 create 表。
4. MySQL 5.6.27 后大于 3 的值也支持 DROP TABLE； 如果事先知道哪個(gè)表導(dǎo)致了崩潰則可 drop 掉這個(gè)表。
5. 如果碰到了由失敗的大規(guī)模導(dǎo)入或大量 ALTER TABLE 操作引起的 runaway rollback，則可 kill 掉 mysqld 線程然后設(shè)置 innodb_force_recovery = 3 使數(shù)據(jù)庫(kù)重啟后不進(jìn)行 rollback。然后刪除導(dǎo)致 runaway rollback 的表； 如果表內(nèi)的數(shù)據(jù)損壞導(dǎo)致不能 dump 整個(gè)表內(nèi)容。那么附帶 order by primary_key desc 從句的查詢或許能夠 dump 出損壞部分之后的部分?jǐn)?shù)據(jù)；

總結(jié)

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