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

本番mysqlサーバーがクラッシュしただけで、復旧しません。セグメンテーションエラーが発生しています。再起動を試みましたが、他に何を試すべきかわかりません。スタックトレースは次のとおりです。

140502 14:13:05 [注]プラグイン「FEDERATED」は無効です。
InnoDB：ログスキャンがチェックポイントlsn 108を超えて進行しました10 1059948207
140502 14:13:06 InnoDB：データベースは正常にシャットダウンされませんでした！
InnoDB：クラッシュリカバリを開始しています。
InnoDB：.ibdファイルからのテーブルスペース情報の読み取り...
InnoDB：ダブルライトからのハーフライトデータページの復元
InnoDB：バッファー...
InnoDB：リカバリを実行中：ログシーケンス番号108までスキャン10 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、元に戻す15行のtrxをロールバック
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
メモリのバイト
大丈夫だと思います。そうでない場合は、方程式のいくつかの変数を減らします。

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_ptr_delete + 0x82）[0xb74f4012]
/ 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/i686/cmov/libc.so.6(clone+0x5e）[0xb6d65a4e]
http://dev.mysql.com/doc/mysql/en/crashing.htmlのマニュアルページには、
クラッシュの原因を特定するのに役立つ情報。

推奨事項はありますか？

mysql innodb crash

— ティレリジ
ソース

最初に最初のもの; 誰かが何らかの形でMySQLの構成を変更しましたか？の最新の修正日を参照してください/etc/mysql/my.cnf。

— ジャンヌピッカライネン

いいえ。mysqldumpを実行するためにinnodb_force_recovery = 3を設定する必要があり、その後、DBを削除して再追加しました。これで修正されました。

— ティレリー

回答:

痛い。

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/から：

停止mysqld（service mysql stop）。
バックアップ /var/lib/mysql/ib*
に次の行を追加します/etc/my.cnf。
```
innodb_force_recovery = 1
```
（4を推奨しますが、1から開始し、開始しない場合は増分するのが最善です）
再起動mysqld（service mysql start）。
すべてのテーブルをダンプします。 mysqldump -A > dump.sql
リカバリが必要なすべてのデータベースを削除します。
停止mysqld（service mysql stop）。
削除する /var/lib/mysql/ib*
コメントアウトinnodb_force_recoveryに/etc/my.cnf
再起動しmysqldます。mysqlエラーログを確認します。デフォルトでは、/var/lib/mysql/server/hostname.com.err新しいib*ファイルの作成方法を確認する必要があります。
ダンプからデータベースを復元します。 mysql < dump.sql

— ジョナサン
ソース

最初に、ファイルシステムの破損またはディスクの不良が考えられます。

— ボムカー14年

6までのすべてのinnodb_force_recovery値を試してください。innodb_purge_threads= 0を追加します。メインスレッドが起動できないことがあります。エラーログに表示されます

— akuzminsky

私はこれが古いスレッドであることを知っていますが、どのデータベースを回復する必要があるかを判断するための詳細はありますか？

— nkanderson

@nicolekandersonその点についてもいくつか説明をお願いします。mysqldumpを実行した後、データベースが破損していることを示すことはありません。

— アンドリュータデウスマーティン

答えのポイント10-データベースサーバーを再起動してエラーログを読み取ろうとすると、クラッシュしたテーブルの名前が表示されます。mysqldumpはテーブルのコピーのみを提供し、何も実行しません。

— ジョナサン

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

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

— rahuljain1311
ソース

Laravel Homesteadでこれが起こりました（Mac OS Sierra 10.12.4（16E195）を実行しているカーネルパニックの後のVagrant：

$ 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を起動できました。

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

その後、Sequel Proを使用してデータベースを再作成し、データを再インポートして、他のプロジェクトからすべてのデータベースを破棄することなく移動できました。

今後は、mysqlデータベースが破損する可能性があると想定し、毎日のバックアップを維持し、データベース作成スクリプトを文書化して、継続的統合ツールにコーディングする必要があります。

— ザック・モリス
ソース