何らかの理由で、.frm
および.ibd
ファイル(MySQLまたはphpmyadminのいずれか)に保存されているテーブルを開こうとすると、構文エラーが表示されるか、存在しないと表示されます。
これと同様の問題があった他の投稿を読みましたが、innodb_file_per_table
が有効になっているかどうかを確認する方法がわからず、全体的に混乱しています。また、mysql-bin.000002
ファイルのコピーをtxtファイルに変換したので、データベースのデータが完全に失われていないことがわかります。
データベースは昨年作成されました。私はそれらのmysql-bin.00000
ファイルを6つ持っていますが、何らかの理由で.000002
が最大です。現在、すべてのデータベースに.ibd
ファイルと.frm
ファイルがありますが、MySQLに、または少なくとも読み取り可能なものに復元する方法に困っています。
Windows 2003 ServerでWampServer 2.4とMySQL 5.6.12を使用しています。また、InnoDBでプラグインをダウンロードする必要がありますか?
ようやく何度も試行錯誤して問題を解決しました。元のibdata1ファイルがなく、.frmファイルと.ibdファイルしかない場合は、次のようにしてデータを復元しました。
これがお役に立てば幸いです。質問やコメントがありましたらお知らせください。また、その他の詳細については http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file を確認してください。
MySQLが.ibdファイルを理解できるようにするには、メインのInnoDBデータファイル(通常はibdata
という名前)が不可欠です。
バイナリファイルを使用してサーバー間でデータを移動する必要がある場合は、MySQLを完全に停止してから、ibdataファイルを含むすべてのデータファイルを移動する必要があります 、ディレクトリ間。
Windows上のサーバー間でデータを移動するより信頼性の高いメカニズムは、( mysqldump
)またはPHPMyAdmin(または同様のツール)からのデータベースエクスポートを使用することです。
サーバーが実行されている間ずっとバイナリログが有効になっている場合(コメントに基づくと、そうではない場合があります)、mysqlbinlog
を使用して、mysql-binからサーバーで実行したすべてのSQLステートメントを回復することもできますファイル、そしてその方法でデータベースを再作成します。 mysql-binファイルに nix timestamps が含まれているはずです。これは、それらがどれだけ遡っているかを判断するのに役立ちます。
元のデータベースファイルを失い、残っているのが個々の.ibdファイルだけの場合は、コメントでのakuzminskyの提案に従ってデータを回復する必要があるかもしれません。
MySQL 5.6には、InnoDB .ibdデータファイル( トランスポータブルテーブルスペース )を移動するためのいくつかの新機能がありますが、これらにはいくつかの作業が必要であり、十分に小さいデータベースの場合、mysqldump
を使用してデータを転送する方がはるかに簡単です。
akuzminskyによって質問のコメントから生成されたWiki回答
*.ibd
ファイルがある場合、innodb_file_per_table
はON
です。それ以外の場合、すべてのテーブルはibdata1
にあります。
テーブルが存在しないことが通知された場合、そのテーブルはInnoDB辞書にありません。すべてのテーブルを別々のSQLダンプにダンプしてみてください(1つのテーブル-1つのファイル)。 TwinDBリカバリツールキット で復元できるダンプできないテーブル。
バイナリパッケージはまだありません。 GitHubからソースコードを取得してコンパイルする必要があります。 Recover InnoDB dictionary の説明を参照してください。とても簡単です:
git clone [email protected]:twindb/undrop-for-innodb.git
その後
make all