MySQL が自動的に再起動する問題の解決方法

序文

最近、テスト環境で MySQL データベースが自動的に再起動し続ける問題が発生しました。原因は、データベースプロセスが kill -9 によって強制終了されたことです。エラーメッセージは次のとおりでした。

2019-07-24T01:14:53.769512Z 0 [注記] 非推奨のパーティションエンジンを使用しているテーブルのリストを取得するには、「SELECT * FROM INFORMATION_SCHEMA.TABLES;」を実行します。このチェックをスキップするには、起動オプション「--disable-partition-engine-check」を使用できます。
2019-07-24T01:14:53.769516Z 0 [注記] ネイティブにパーティション分割されていないテーブルのリストの始まり
01:14:53 UTC - mysqld はシグナル 11 を取得しました。
これはバグに遭遇したためかもしれません。また、このバイナリが
または、リンクされているライブラリの1つが破損しているか、不適切に構築されているか、
または構成が誤っています。このエラーは、ハードウェアの故障によっても発生する可能性があります。
問題の診断に役立つ情報を収集しようとしています。
これは事故であり、何かが間違いなく間違っているので、情報は
収集プロセスが失敗する可能性があります。
Percona Serverの改善にご協力ください。
バグについては http://bugs.percona.com/ をご覧ください
キーバッファサイズ=33554432
読み取りバッファサイズ=8388608
最大使用接続数=0
最大スレッド数=501
スレッド数=4
接続数=0
mysqldは最大で
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4478400 K バイトのメモリ
大丈夫だと思いますが、そうでない場合は、方程式内のいくつかの変数を減らしてください。
スレッドポインタ: 0x7f486900e000
バックトレースを試行しています。次の情報を使用して調べることができます。
mysqldが死んだ。その後にメッセージが表示されない場合は、何かが起こった可能性があります。
ひどく間違っています...
スタックボトム = 7f4846172820 スレッドスタック 0x80000
/usr/local/mysql5.7/bin/mysqld(my_print_stacktrace+0x2c)[0xed481c]
/usr/local/mysql5.7/bin/mysqld(ハンドル致命的シグナル+0x461)[0x7a15a1]
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]
libpthread.so.0(+0x7aa1)[0x7f4986974aa1] の続きを読む
/lib64/libc.so.6(クローン+0x6d)[0x7f4984c6bc4d]
いくつかの変数を取得しようとしています。
一部のポインタが無効になり、ダンプが中止される可能性があります。
クエリ（0）：無効なポインタです
接続ID（スレッドID）：2
ステータス: NOT_KILLED
Percona Serverの操作マニュアルは、次のサイトからダウンロードできます。
http://www.percona.com/software/percona-server/ で情報を見つけることができます
クラッシュの原因を特定するのに役立ちます。

1. 初期探索プロセス

以前同様の状況が発生したときは、ログに対応するプロンプトがあったため、メモリ不足が原因でした。

キーバッファサイズ=33554432
読み取りバッファサイズ=8388608
最大使用接続数=0
最大スレッド数=501
スレッド数=4
接続数=0
mysqldは最大で
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4478400 K バイトのメモリ
大丈夫だと思いますが、そうでない場合は、方程式内のいくつかの変数を減らしてください。

このテスト環境の物理メモリは確かに大きくなく、残りメモリが不足しています。また、別のテスト環境のスレーブライブラリなので、メモリ割り当ても小さいです。

以前にも、同様の状況がいくつかの環境で発生しました。パラメータを調整してメモリを解放すると、システムは正常に起動できます。そこで、いくつかの一時プログラムを閉じて、MySQL の上記のパラメータの値を調整してみました。

[mysqld]
最大接続数 = 50

その後、MySQL を再起動すると、再起動が続行されます。

初期治療は失敗に終わった。

2. 連続再起動の問題を解決するためにinnodb_force_recoveryを追加する

まず、連続再起動の問題に対処するために、設定ファイルmy.cnfにinnodb_force_recoveryを追加します。

[mysqld]
innodb_force_recovery = 4

追加後、MySQL を再度起動すると、繰り返しの再起動は発生しなくなります。

データベースログを確認すると、次のようにプロンプト [Note] InnoDB: !!! innodb_force_recovery が 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 を超える値はデータファイルを永久に破損する可能性があります。本番環境で同様の問題が発生する場合は、必ず最初にテストをコピーし、テストが合格した後に本番環境で処理してください)。この時点ですべてのデータをダンプし、後で復元することができます。

3. innodb_force_recoveryパラメータ

innodb_force_recovery は 1 ～ 6 に設定でき、値が大きいほど、それより小さい以前の値の影響がすべて含まれます。

1 (SRV_FORCE_IGNORE_CORRUPT): 検出された破損ページを無視します。破損したページが検出されてもサービスを強制的に実行します。通常、この値に設定してから、テーブルをダンプして再構築することができます。
2 (SRV_FORCE_NO_BACKGROUND): メインスレッドの実行を防止します。メインスレッドが完全なパージ操作を実行する必要がある場合、クラッシュが発生します。マスタースレッドとパージスレッドの実行を防止します。この値は、パージフェーズ中にクラッシュが発生した場合に使用されます。
3 (SRV_FORCE_NO_TRX_UNDO): トランザクションのロールバックを実行しません。
4 (SRV_FORCE_NO_IBUF_MERGE): 挿入バッファのマージを実行しません。クラッシュを引き起こす可能性がある場合は、これらの操作を実行しないでください。統計演算を実行しないでください。この値により、データファイルが永久に破損する可能性があります。この値を使用すると、将来的にセカンダリインデックスを削除して再作成する必要があります。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN): InnoDB ストレージエンジンは、REDO ログを参照せずに、コミットされていないトランザクションをコミット済みとして扱います。この時点で、InnoDB は未完了のトランザクションもコミット済みとして扱います。この値により、データファイルが永久に破損する可能性があります。
6 (SRV_FORCE_NO_LOG_REDO): ロールフォワード操作を実行しません。リカバリ中にREDOログのロールフォワードは実行されません。これにより、データベースページが無効な状態になり、B ツリーやその他のデータベース構造にさらなる損傷が発生する可能性があります。

知らせ：

安全上の理由から、パラメータ値が 0 より大きい値に設定されている場合、テーブルに対して選択、作成、およびドロップ操作は実行できますが、挿入、更新、または削除操作は実行できません。
MySQL 5.6.15 以降では、innodb_force_recovery の値が 4 以上の場合、InnoDB テーブルは読み取り専用モードになります。
値が 3 以下の場合、テーブルを選択、削除、または作成することでテーブルをダンプできます。
MySQL 5.6.27 以降では、3 より大きい値に対する DROP TABLE もサポートされています。クラッシュの原因となったテーブルが事前にわかっている場合は、そのテーブルを削除できます。
大規模なインポートの失敗や大量の ALTER TABLE 操作によってロールバックが暴走した場合は、mysqld スレッドを強制終了し、innodb_force_recovery = 3 を設定して、再起動後にデータベースがロールバックしないようにすることができます。次に、暴走ロールバックの原因となったテーブルを削除します。テーブル内のデータが破損している場合は、テーブルの内容全体をダンプすることはできません。次に、order by primary_key desc 句を含むクエリを実行すると、破損した部分の後のデータの一部をダンプできる可能性があります。

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。

以下もご興味があるかもしれません: