web-dev-qa-db-ja.com

MySQLがクラッシュし、起動しません

私たちのプロダクションmysqlサーバーがクラッシュしただけで、復旧しません。 segfaultエラーが発生しています。私は再起動を試みましたが、他に何を試すべきかわからないだけです。これがスタックトレースです：

 140502 14:13:05 [注]プラグイン「FEDERATED」が無効になっています。
 InnoDB：チェックポイントlsn 108 1057948207を超えてログスキャンが進行しました
 140502 14:13:06 InnoDB：データベースが正常にシャットダウンされませんでした！
 InnoDB：クラッシュリカバリを開始しています。
 InnoDB：.ibdファイルからテーブルスペース情報を読み込んでいます... 
 InnoDB：可能性のある、半分書き込まれたデータページを復元していますダブルライトから
 InnoDB：バッファ... 
 InnoDB：リカバリを実行中：ログシーケンス番号108 1058059648 
 InnoDB：1つ以上のトランザクションをロールバックするか、クリーンアップ
 InnoDB：元に戻す合計15行の操作
 InnoDB：Trx idカウンターは0 562485504 
 140502 14:13:06 InnoDB：ログレコードの適用バッチの開始データベース... 
 InnoDB：進捗率（％）：4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
 InnoDB：バッチの適用が完了しました
 InnoDB：コミットされていないトランザクションのロールバックをバックグラウンドで開始しています
 140502 14:13:06 InnoDB：ID 0 562485192のtrxをロールバックし、15行を元に戻します
 140502 14:13:06 InnoDB：開始。ログシーケンス番号108 1058059648 
 140502 14:13:06 InnoDB：ファイル../../../storage/innobase/fsp/fsp0fsp.c行1593 
のスレッド1873206128でのアサーションエラーInnoDB：アサーションの失敗：frag_n_used> 0 
 InnoDB：意図的にメモリトラップを生成します。
 InnoDB：詳細なバグレポートをhttp://bugs.mysql.com。
に送信してくださいInnoDB：アサーションエラーまたはクラッシュが繰り返し発生する場合、
 InnoDB：mysqldの起動直後に、
 InnoDB：InnoDBテーブルスペースが破損している可能性があります。 
 InnoDBを参照してください：http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB：強制的なリカバリについて。
 140502 14:13:06-mysqldがシグナル6を取得しました; 
これは、バグにヒットしたためである可能性があります。また、このバイナリ
またはリンクされたライブラリの1つが破損しているか、不適切に構築されているか、
が正しく構成されていない可能性もあります。このエラーは、ハードウェアの誤動作によっても発生する可能性があります。
問題の診断に役立つと思われる情報を収集するために全力を尽くします
問題はすでにクラッシュしていますので、何かが間違いです
これは失敗する可能性があります。
 
 key_buffer_size = 16777216 
 read_buffer_size = 131072 
 max_used_connections = 0 
 max_threads = 151 
 threads_connected = 0 
 mysqldが最大
 key_buffer_size +（read_buffer_size + sort_buffer_size）* max_threads = 345919 K 
バイトのメモリ
を使用する可能性があるOK;そうでない場合は、方程式の一部の変数を減らします。
 
 thd：0x0 
バックトレースを試みます。以下の情報を使用して、mysqldが死んだ場所を見つけることができます。
この後にメッセージが表示されない場合、何かがうまくいきました。
ひどく間違っています... 
 stack_bottom =（nil）thread_stack 0x30000 
 140502 14:13:06 [注意]イベントスケジューラ：読み込まれました0イベント
 140502 14:13:06 [注意]/usr/sbin/mysqld：接続準備完了。
バージョン： '5.1.41-3ubuntu12.10'ソケット： '/ var/run /mysqld/mysqld.sock 'ポート：3306（Ubuntu）
/usr/sbin/mysqld（my_print_stacktrace + 0x2d）[0xb7579cbd] 
/usr/sbin/mysqld（handle_segfault + 0x494）[0xb7245854 ] 
 [0xb6fc0400] 
/lib/tls/i686/cmov/libc.so.6（abort + 0x182）[0xb6cc5a82] 
/usr/sbin/mysqld（+ 0x4867e9 ）[0xb74647e9] 
/usr/sbin/mysqld（btr_page_free_low + 0x122）[0xb74f1622] 
/usr/sbin/mysqld（btr_compress + 0x684）[0xb74f4ca4] 
/usr/sbin/mysqld（btr_cur_compress_if_useful + 0xe7）[0xb74284e7] 
/usr/sbin/mysqld（btr_cur_pessimistic_delete + 0x332）[0xb7429e72] 
/usr/sbin/mysqld（btr_node_ptf_deleter [btr_node_ptr_delete] .____。]/usr/sbin/mysqld（btr_discard_page + 0x175）[0xb74f41e5] 
/usr/sbin/mysqld（btr_cur_pessimistic_delete + 0x3e8）[0xb7429f28] 
/usr/sbin/mysqld（+ 0x526197）[0xb7504197] 
/usr/sbin/mysqld（row_undo_ins + 0x1b1）[ 0xb7504771] 
/usr/sbin/mysqld（row_undo_step + 0x25f）[0xb74c210f] 
/usr/sbin/mysqld（que_run_threads + 0x58a）[0xb74a31da] 
/usr/sbin/mysqld（trx_rollback_or_clean_all_without_sess + 0x3e3）[0xb74ded43] 
/lib/tls/i686/cmov/libpthread.so.0（+ 0x596e）[0xb6f9f96e] 
/lib/tls/c686/cmov/cmov .so.6（clone + 0x5e）[0xb6d65a4e] 
 http://dev.mysql.com/doc/mysql/en/crashing.htmlのマニュアルページには、
役立つ情報が含まれていますクラッシュの原因を突き止めます。

何かお勧めですか？

mysqlinnodbcrash
20
tilleryj

痛い。

InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.

提案されたWebページを確認してください： http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html 。

基本的には、MySQLサーバーをリカバリモードで起動して、クラッシュしたテーブルのバックアップを作成してください。

/etc/my.cnfを編集して追加：

 innodb_force_recovery = 1

...データベースにアクセスしてデータを取得できるかどうかを確認し、破損したテーブルを見つけます。

通常、これが発生するのは再構築です（少なくとも1つまたは2つの破損したテーブル）。

http://chepri.com/mysql-innodb-corruption-and-recovery/ から：

  1. 停止mysqld（service mysql stop）。
  2. バックアップ/var/lib/mysql/ib*

  3. 次の行を/etc/my.cnfに追加します。

    innodb_force_recovery = 1

    （4を推奨しますが、1から開始し、開始しない場合は増分するのが最善です）

  4. mysqld（service mysql start）を再起動します。

  5. すべてのテーブルをダンプ：mysqldump -A > dump.sql
  6. リカバリが必要なすべてのデータベースを削除します。
  7. 停止mysqld（service mysql stop）。
  8. 削除/var/lib/mysql/ib*
  9. コメントアウトinnodb_force_recovery in /etc/my.cnf
  10. mysqldを再起動します。 mysqlエラーログを確認します。新しい/var/lib/mysql/server/hostname.com.errファイルがどのように作成されるかを確認するには、デフォルトでib*にする必要があります。
  11. ダンプからデータベースを復元します：mysql < dump.sql
27
Jonathan

Mysql：5.7 docker imageを使用しているときに、私はこの同じエラーに直面していました。主な間違いは、デフォルトで存在するrootユーザーを作成しようとしたことです。詳細： https://github.com/docker-library/mysql/issues/129

上記のリンクにあるように、解決策は、Dockerイメージの起動時に環境変数にMYSQL_USERおよびMYSQL_PASSWORDを設定しないことでした。

2
rahuljain1311

これは、Laravel Homesteadで発生しました（Mac OS Sierra 10.12.4（16E195）を実行しているカーネルパニック後の放浪）：

_$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

$ mysql -V
mysql  Ver 14.14 Distrib 5.7.9, for Linux (x86_64) using  EditLine 
wrapper
_

私にとってうまくいった修復オプションはありませんが：

https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

https://forums.mysql.com/read.php?22,603093,604631#msg-604631

https://support.plesk.com/hc/en-us/articles/213939865-How-to-fix-InnoDB-corruption-cases-for-the-MySQL-database

私はmysql設定に強制リカバリを追加してみました（1から始めて、数値が大きくなると永続的な破損が発生する可能性があるため、徐々に大きくしていきます）。

_Sudo nano /etc/mysql/my.cnf_

_[mysqld]
innodb_force_recovery = 1
#innodb-read-only=1
#innodb_purge_threads=0
#key_buffer_size=16M
#event-scheduler=disabled
_

別のウィンドウで、以下を実行します。

_tail -f /var/log/mysql/error.log_

次に、さまざまなオプションを有効にしてmysqldを再起動してみます。

_Sudo /etc/init.d/mysql restart_

タイムアウトした場合は、次のコマンドでmysqlプロセスを強制的に再起動できます。

_# process id is first column with number, just ignore lines with grep because they list the process running 'grep mysql'
ps aux | grep mysql
Sudo kill -9 <process-id>
Sudo /etc/init.d/mysql restart
_

動作する場合、ログは次のように表示されます。

Version: '5.7.9' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

失敗した場合、ログは次のように表示されます。

_InnoDB: Assertion failure in thread 140049488692992 in file log0recv.cc line 1420_

状況が悪化すると、破損している可能性のあるデータベースを削除しようとしました。

_Sudo ls -alt /var/lib/mysql_

私が作業していたデータベースは、リストの一番上にある最後に変更されたデータベースであることがわかりました。幸い、私はその日からSQLダンプを持っていたので、削除することができました。

_Sudo rm -rf /var/lib/mysql/<database_name>_

他のファイルはすべて残しましたが、mysqlはとにかく起動できました。

更新：mysqlが再び機能するようになったら、必ず_innodb_force_recovery = 1_を無効にしてください。無効にしないと、データベースやテーブルを変更しようとするとエラーが発生します。

その後、Sequel Proを使用してデータベースを再作成し、データを再インポートして、他のプロジェクトからすべてのデータベースを破棄せずに先に進むことができました。

今後は、mysqlデータベースが破損する可能性があると想定し、毎日のバックアップを保持して、データベース再作成スクリプトを継続的インテグレーションツールに文書化またはコード化する必要があります

1
Zack Morris