ibdata1、ib_logfile1、ib_logfile0からのMySQLバックアップ
Wordプレスmysql DBを誤って削除しました。以下は、自分のデータの一部を取得できることを期待しているディレクトリにあるログファイルのリストです。 
私は実際に最初のファイル（mysql-bin.000001）をsqlに変換し、wordpressテーブルのcreateステートメントを確認しました。これにより、すべてのデータを回復できる可能性があるという事実に期待しましたしかし、私は以下のmysqlバイナリログファイルですべてのmysqlコマンドを実行し、非常に古いバージョンのwordpressブログしか表示できませんでした。
Ibdata1、ib_logfile1、ib_logfile0ファイルを使用してデータを回復できますか？
同じDBインスタンスのバイナリログファイルでSQLステートメントを再実行しました（これにより、古いバージョンのwordpressテーブル）が得られました）
痛い。リカバリにどの程度の希望があったかは、テーブルがMyISAMを使用しているか、InnoDBストレージエンジンを使用しているかによって異なります。 MyISAMの場合...「なし」、InnoDBの場合「一部」
古いエンジンであるMyISAMは、データをMYD拡張子の付いたテーブルにちなんだ名前のファイルに保存しますが、InnoDBはデータをibd拡張子の付いたテーブルにちなんだ名前のファイルに保存します。構成のibdata1の設定に応じて、システムテーブルスペースを格納するinnodb_file_per_tableファイル内。いずれかのエンジンの各テーブルの定義（列名、データ型、インデックス定義）は、frm拡張子が付いたテーブルにちなんで名付けられたファイルに保存されます。
ibdata1ファイルのサイズが大きいことから、innodb_file_per_tableが有効になっていない可能性があり、実際にinnodb_file_per_tableなしでInnoDBを使用している場合は、次の手順のいくつかのバリエーションが機能する可能性があることが示唆されました。
- すべてのバックアップコピーを作成します。
- 別の新しいMySQLサーバーをセットアップします。
- テーブル定義の.frmファイルを再作成するために、使用しているバイナリログを新しいサーバーに適用し、テーブルを手動で変更して、以前のバイナリログで説明されていない変更を思い出してください。
- 新しいサーバーを停止します。
- データディレクトリ内のディレクトリとその.frmファイルを古いサーバーの適切な場所にコピーします。
- 必要に応じて innodb_force_recovery を使用して古いサーバーを起動し、InnoDBが.frmファイルをibdata1内のテーブルデータとどのようにペアリングして、テーブル定義が同じであるかを確認します。
おそらく同じ名前で新しいテーブルを既存のサーバー上にすでに作成しているので、その計画が成功する可能性は排除されるか、または試してみる価値がないと思われるほど大幅に減少します。試してみれば、現在表示されているもの、つまりバイナリログから作成したテーブルに挿入した古いデータが表示されることを願っています。
では、プランBとは何でしょうか。引用元から適切なフレーズを借りるために、私は引用します：
「InnoDBの内部データストレージ形式、Cプログラミング、およびかなりの直感と経験を理解する必要がある退屈なプロセスです。」
http://www.percona.com/docs/wiki/innodb-data-recovery-tool:start
Percona InnoDB Data Recovery Tool は、同等のツールがあると仮定して、必要な場所に到達できる可能性のある唯一の有意義なアプローチまたは同等のツールです。単純なパスは見当たらない...データを救出するには、「低レベル」にする必要があります。
重要なファイルを削除し、最初の問題から回復するために、mightがサルベージ可能な残りの1つのファイルを変更しました。 InnoDBが内部構造で破棄されたテーブルをどのように処理したかは完全にはわかりません。データはまだ非表示になっている可能性があります。
ただし、楽観的な理由は1つあり、それは stringsユーティリティ にあります。私が提供したリンクは、本物のGNU "strings"ユーティリティへのリンクではありません。これはMicrosoftの類似した半同等のものですが、このツールのポイントは、内部アルゴリズムであるファイルに埋め込まれた文字列を表示することです。人間に意味のある文字列かもしれないと思います。
これには2つの用途があります。1つは、ibdata1ファイルでそれを使用して（読み取りのみで、変更しないでください）、そこにあるものについて眼球が何を示しているかを確認することです。それは本質的にファイルに存在する生のコンテンツへのブルートフォースウィンドウを提供し、そこにbinlogファイルを使用して入力したものよりも新しいテキストを見つけた場合、それはPerconaツールで費やされた時間が良い兆候である可能性があります古いデータは実際にはファイル内にあるため、価値があります。認識できるものがまったく表示されない場合は、メソッドに問題がある可能性があります（ただし、正規のGNU "strings"）のLinuxで動作することを確認しましたが、古い場合新しいコンテンツではなく、新しいコンテンツがなくなっている可能性があります。
もちろん、コンテンツが表示され、主に失われた最も価値のあるコンテンツである場合、構成やカスタマイズではなく、「文字列」のその他の潜在的な使用法は、「文字列」を使用して抽出することができます生のコンテンツを別のファイルにリダイレクトし、新しいwordpressインストールを続行します。ここで、生のテキストを使用して物を再作成できます。
データが「それ」重要である場合、PerconaとSkySQL（私はどちらの会社とも提携していませんが、これらはMySQLの分野で2人の主要企業のようです）および他の会社が有料のリカバリサービスを提供しています。