はじめに：
この投稿は、次のすばらしい投稿のコピーです：
https://blackbird.si/mysql-corrupted-innodb-tables-recovery-step-by-step-guide/https://blackbird .si / mysql-corrupted-innodb-tables-recovery-step-by-step-guide /
ここにいくつかの重要な成果があります：
MySQL –破損したInnoDBテーブルの回復–ステップバイステップガイド
データベースへの投稿AlenKrmelj、2013年3月19日、5〜6分
InnoDBテーブルは簡単に破損することはありませんが、破損した場合、通常、ハードウェアの問題、停電、またはMySQLのバグが原因で発生します。 InnoDBテーブルスペースに破損したページが残り、そこからの回復が問題になる可能性があります。 MySQLが適切にクラッシュし、復帰したくない場合は、同様のエラーのループが表示されることがあります：
InnoDB: Assertion failure in thread 1129654592 in file ibuf0ibuf.c line 4231 InnoDB: Failing assertion: page_get_n_recs(page) > 1 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even 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.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. mysqld got signal 6 ; 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. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. ... some backtrace ... The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. mysqld_safe Number of processes running now: 0 mysqld_safe mysqld restarted
破損したInnoDBテーブルからの回復
ステップ1–データベースをリカバリモードで起動します
データベースを停止する必要があります。まだ実行中であり、ログにこれらのメッセージをスパムしている場合は、シャットダウンしてください。最後の手段として、プロセスを強制終了することもできます。データベースを元に戻すには、innodb_force_recoveryを使用してデータベースをリカバリモードで起動する必要があります。 。このリカバリモードでは、データベースが読み取り専用になることを知っておく必要があります。接続しているユーザーは、既存のデータを更新、挿入、またはその他の方法で変更することはできません。 MySQLが戻ってきた瞬間に打たれるのを防ぐために、MySQLサーバーのポートも3306からランダムなものに変更することをお勧めします。 innodb_force_recovery=1を追加します my.cnfに サーバーが復帰したくない場合は、この数をさらに1から6に増やすことができます。違いは、MySQLのマニュアルを確認してください。
MySQLログを確認し、次のようなループが発生するかどうかを確認してください。
InnoDB: Waiting for the background threads to start
innodb_purge_threads=0も追加する必要があります my.cnfに 。
したがって、データベースを元に戻すために、これら3つのパラメーターをmy.cnfに追加する必要がありました。 ：
port = 8881 innodb_force_recovery=3 innodb_purge_threads=0
ステップ2–破損しているテーブルを確認し、リストを作成します
これで、データベースがバックアップされて実行されていますが、リカバリモードになっています。データベース/テーブルを変更することはできません。試してみると、エラーが発生します：
Got error -1 from storage engine
どのテーブルが破損したかを調べる必要があります。これを行うには、次のコマンドを実行します。mysqlcheck --all-databases
テーブルが破損していると表示されている行を確認します。エラーが発生したすべてのテーブル/データベースを書き留めます。 mysqldumpする必要があります それらをリカバリモードで起動し、通常のMySQLモードに戻ってから再インポートします。また、innochecksum コマンドは、破損しているテーブルを見つけるのに役立たなかったので、気にしないでください。
ステップ3–破損したテーブルのバックアップと削除
破損したテーブルのリストを取得したら、それらを独自の.sqlファイルにmysqldumpする必要があります。これにより、再インポート用のバックアップが作成されます。データベースに1つのテーブルのみをダンプする方法がわからない場合：
mysqldumpmy_databaseテーブル>database.table.sql
バックアップを作成したら、次のコマンドを実行して、破損したテーブルを削除します。drop table database.table; MySQLシェルから。これでMySQLデータベースがクリーンアップされたので、リカバリモードなしでデータベースを再起動します。
ステップ4–MySQLを通常モードで再起動します
データベースに破損したテーブルが残っていない場合は、手順1で追加したmy.cnf設定を削除する必要があります。データベースにはバックアップしたテーブルがまだないため、ポート設定はまだ削除しないでください。再インポートされます。 MySQLを再起動します。
ステップ5–バックアップ.sqlをインポートする
ダンプされた各.sqlテーブルをそれらの尊重されたデータベースにインポートします。 CLIからそれを行うには：
mysql database < database.table.sql
ステップ6–ポートを変更してビールを飲みます
テーブルのインポートが完了したら、my.cnfでポート設定を自由に変更できます。 。もちろん、後でMySQLを再起動します。クラッシュする前と同じように、戻って動作を開始するはずです。ビールを飲み、この投稿の上部をクリックして、この記事が問題の解決に役立ったことを知らせてください。