web-dev-qa-db-ja.com

InnoDBログシーケンス番号は将来のものです

130711 23:03:40 InnoDB: Error: page 23 log sequence number 3336825872455
InnoDB: is in the future! Current system log sequence number 235089.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files.

これまでにこのエラーを見たことがない、または経験したことがありません。クライアントにはバックアップがないため、リカバリを実行する必要があります。

以前にMySAIMのリカバリを行ったことがありますが、InnoDBは行っていません。正しく行うためのヒントはありますか？

私が読んだものから、ib_logfile0とib_logfile1のヘッダーのどこかに格納されている単一のカウンター（「ログシーケンス番号」）を増やす必要がありますか？

linuxmysqlinnodbrecovery
6
Tiffany Walker

唯一の正しい解決策は、再インストールしてバックアップから復元することです。あなたはバックアップがないと言いますが、ここでのポイントは、InnoDBリカバリを強制する背後にある考えは、サーバーを十分に安定させることができるということですmakeバックアップ。次に、それを使用して、新しいセットアップで復元します。

明らかに、何かを行う前にすべてのファイルのコピーを作成します。

取得できなかったメモがない限り、ログシーケンス番号を増やしてInnoDBを平準化しようとは思わないでしょう。たとえそれを管理できたとしても、未知の場所にデータ破損のあるサーバーがまだあるからです。 LSNを修正すれば、実際に達成したことはInnoDBが破損を認識しないようにすることです。 LSNを強制することは、ほとんどばかげた用事です。

あなたは何かを試しましたか...

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

1から6までの異なるレベルは、InnoDBの一部を累積的に無効にします。十分な機能を無効にすると、テーブルからmysqldumpまたは少なくともSELECT ... INTO OUTFILEを正常に取得できる可能性があるという考えです。

データを正常にダンプできる最小の番号を使用するという考え方ですが、起動時にこのエラーが発生する可能性があると思われる場合は、6から始めてください。サーバーが起動した場合は、次に、テーブルから選択してみてください。再びクラッシュする可能性があり、クラッシュした場合は、そのテーブルを一時的に書き込み、次のテーブルに移動します。

破損していないテーブルからデータを取得したら、機能していないものに戻って、SELECT ... LIMIT ... OFFSETを使用して小さなチャックでデータを取得できる可能性があります。

その他のアイデアについては、私の この同様の質問への回答 を参照してください。

また、Perconaの InnoDBデータリカバリツール を潜在的なリソースとして確認することもできますが、バックアップや実行中のレプリケーションスレーブなしで（フィンガーが交差して）捕捉されることはないので、必要はありませんそれ。

2
Michael - sqlbot