web-dev-qa-db-ja.com

破損したInnodbデータファイルを回復/復元する方法は？

しばらく前、MySQLサーバー5.5.31が実行されているWindows 7システムがクラッシュし、InnoDBデータベースが破損しました。利用可能な毎週のバックアップは、その間に作成されたすべてのテーブルをカバーしているわけではないため、データから可能な限り回復するように努めます。クラッシュの直後に、MySQLのデータフォルダ全体を外部ドライブにコピーしました。これを私の救急活動の出発点として使用したいと思います。

以下では、私の（まだ説得力のない）救助活動の手順を説明し、それを改善する方法についてのコメントやガイダンスに感謝します。

  1. 別のPCにMySQL Server 5.5.31の新規インストールを実行しました
  2. コマンドプロンプトで「net stop MySQL」を使用してMySQLサービスを停止します。
  3. My.iniファイルのinnodbログファイルは、デフォルト値（19MB）とは異なるため（256 MB）、サイズを調整する必要があることはすでにわかりました。
  4. My.iniで、innodb_force_recovery = 6も設定しました
  5. 新規インストールのデータフォルダーで、ibdata1、iblogfile0、iblogfile1ファイルを、クラッシュしたマシンから回復したファイルで上書きします。関連するデータベース（UPDATE：とmysql）フォルダーもここにコピーします（標準ではありません） mysql、 テストおよびパフォーマンスフォルダ）。
  6. MySQLサービスを「net start MySQL」で開始します。
  7. MySQL Workbenchに移動し、サーバーインスタンスを開き、Data Exportに移動し、基本的にデフォルト設定のままにし、データベースのすべてのテーブルを個別のダンプファイルとしてエクスポートします。ダンプするストアード・プロシージャーも設定しました。それ以外の場合は、そこでデフォルト設定を変更しません。
  8. ダンププロセスを開始します。 195テーブルのうち43テーブルを通過します。これら43のうち、
    • 一部を回復できず、エラーが発生します "mysqldump：Got error：1146：Table '... whatever ...' does not exist not when LOCK TABLES"、
    • しかし、多くはできます。ダンプによってエラーが発生しない場合、テーブルのデータは破損していないと思います。
      その後、44番目以降、サーバーに接続できなくなったことが報告されているため、他のすべてのテーブルダンプが失敗します。
      "mysqldump：Got error：2003：Ca n't connect to MySQL server on 'localhost'（10061）when試みるとき
      操作は終了コード2      で失敗しました "
      その後、これらのエラーは44番目から195番目までの残りのすべてのテーブルで発生します。
      44番目のテーブル自体のエラーは次のとおりです： "mysqldump：Error 2013：Lost connection to MySQL server when query when dumping table ...table 44... at row：57 」したがって、このテーブルの破損は行57であるか、行57で始まるようです。

今私の質問に：

  • Innodb_force_recoveryが6に設定されていると、接続が壊れるのはなぜですか？
  • どうやって進める？接続が失われた44番目のテーブルが何であるかを調べ、45番目のテーブルからプロセスを再開することができます。しかし、それを行うためのより良い方法はありませんか？
  • データがコピーされ、サーバーが正常に再起動したら、各テーブルのダンプを試すだけですか、それともどのような選択肢がありますか？

ありがとう。

更新：後で参照するための追加メモ
-SHOW CREATE PROCEDURE ...およびSHOW CREATE FUNCTION ...を使用してバックアップされたストアドルーチンを再作成する場合、DELIMITER // (create procedure code of procedure 1)// (create procedure code of procedure 2)// DELIMITER ;を使用してインポートする必要があります

mysqlrecoveryrestore
5
Steve06

MySQLエラーログを確認します。テーブル44を読み取ろうとすると、実際にサーバーがクラッシュするようです。

「クエリ中にMySQLサーバーへの接続が失われる」というのは、MySQL DBAにとって心停止時間です（またはそうすべきです）。これは、クエリが実際に行ったことが実際にサーバーをクラッシュさせたことを意味します。

後続のメッセージはこれを明らかにしているようです：

_mysqldump: Got error: 2003: Can't connect to MySQL server on 'localhost' (10061) when
trying to connect
Operation failed with exitcode 2
_

実行されていないMySQLサーバーに対するWindows 7のmysqldumpのクイックテストは、まったく同じエラーを返し、_%ERRORLEVEL%_を2に設定して終了します。エラー10061の性質は the perrorユーティリティ で確認できます。

_C:\>perror 10061
Win32 error code 10061: No connection could be made because the target machine actively refused it.
_

...それで、MySQLエラーログを確認します。発生している可能性が高いのは、_innodb_force_recovery_にもかかわらずMySQLサーバーがクラッシュするほど深刻な破損に遭遇していることです。その後、通常は自動的に再起動しますが、これには時間がかかるため、mysqldumpが後続の接続試行でIP接続を拒否する前に完了しない場合があります。これはすべてエラーログに表示されます。

ダンプによってエラーが発生しない場合、テーブルのデータは破損していないと思います。

誤った仮定。ダンプでエラーが発生しない場合は、サーバーがデータのsomeを取得することを_innodb_force_recovery_が許可したことを意味する場合もあります。テーブルの「成功した」ダンプは、それが深刻に破損していないので、_innodb_force_recovery_はそれを生き残ることができません。

1 (SRV_FORCE_IGNORE_CORRUPT)

破損したページを検出した場合でも、サーバーを実行します。 _SELECT * FROM tbl_name_が破損したインデックスレコードとページを飛び越えられるようにしてください。これはテーブルのダンプに役立ちます。

http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

ここでも、MySQLエラーログにInnoDBからのチャターが表示されます。

最後の提案ですが、ワークベンチは使用しないでください。 mysqlコマンドラインクライアントを使用してサーバースキーマを探索し、コマンドラインから直接mysqldumpを使用して個々のスキーマまたは個々のデータベースを復元してみてください。

更新/追加：

ストアドプロシージャをどのように回復しますか？破損したテーブルにアクセスするため、エラーが発生する

ストアドプロシージャと関数はビューと同じように参照されるテーブルに対して検証されないため（ビューが参照するテーブルをドロップすると、_SHOW CREATE VIEW_が機能しないため）、プロシージャが破損したテーブルにアクセスするためではありません。 -プロシージャや関数の場合も同じです）... MySQLは、ストアドプロシージャや関数によって参照されるテーブルが存在するかどうかを考慮しません（実行時を除く）...ただし、ビュー定義とは異なり、個々のファイル、プロシージャと関数の定義は、MyISAMテーブルであるprocスキーマのmysqlテーブルに保存されます...したがって、参照しているエラーメッセージが表示されると思いますそのテーブルと_CHECK TABLE mysql.proc;_および _REPAIR TABLE mysql.proc;_ を使用すると、もう一度やり直すことができます。リカバリに使用しているMySQLサーバーのバージョンは、同じリリースシリーズ（例：5.5）である必要があります。そうでない場合、_mysql.proc_のテーブル定義は正しくありません...ここでは問題になりません質問を正しく読んだ場合、クラッシュしたサーバーとリカバリサーバーはどちらも5.5.31です。

_SELECT * FROM mysql.proc_が可能であれば、何らかの理由で_SHOW CREATE PROCEDURE_ステートメントが機能しない場合でも、その方法で定義を取得できます。

ダンプでエラーが発生したテーブルには、（部分的な）レスキューのどのオプションがありますか？

発生したエラーの性質と範囲によって異なります。 1つのオプション ここで説明 は、繰り返される_INSERT ... SELECT ... LIMIT ... OFFSET_を含み、読み取り可能なページからMyISAMテーブルに行のブロックを抽出します（_innodb_force_recovery_の間はInnoDBテーブルに書き込めないため）オン）。 Pernoa Data Recovery Tool for InnoDB もありますが、使用する機会は一度もありません。

6
Michael - sqlbot