私はこの記事を参照したいすべての最初に、あなたがそれを使用する機会を持っていることはありません...
それはあなた自身のグーグルでのMySQLの他のエンジンまたは他のデータベースである場合は、この記事では、回復のMySQLのInnoDBデータベースエンジンのデータを参照し...
1日あなたは手が誤って、データベース内の公式データを削除し、あるいはライブラリ全体がオフにドロップし、瞬時に黒い目を感じるように落ちた場合は私の世界がそこに木を持っていたようにあなたは、データベースのバックアップを持っている場合は、そこに木が、私は、感じました幸いなことに、あなたはデータのバックアップを返信することができ、またはあなたは、MySQLバイナリログを内側から回復しているように見えるが、木材・木材オープンバイナリログを開始することができませんでし強制するのは難しい感じていないのバックアップがある場合は、以下のオープン内容はこのような状況のために、いくつかの回避策を提供します...
1.まず、あなたができるだけ早くmysqlのように停止してサービスする必要があり、データのフォルダのコピーのMySQLデータベースの内容すべてのアウト、削除されたデータを防止するための操作をカバーしました。
2.私はUbuntuの12.04使用のLinuxシステムを準備します。
3. perconaデータリカバリ・ツールのための-のInnoDBに、データベースの回復ツールperconaデータリカバリ・ツールのための-のInnoDBを準備します。
3.1。このツールは、唯一のInnoDB / XtraDBテーブルが有効である、とMyISAMテーブルを復元することはできません。
3.2。このツールは、MySQLサーバの実行せずに、MySQLのデータファイルの復旧に保存されます。
3.3。データは必ず回収しなければならないことを保証します。例えば、書き換えられたデータを復元することはできません。
3.4。このツールを使用すると、手動でいくつかの作業が自動ではありません行う必要があります。
3.5。回復プロセスはデータ損失の理解のあなたのレベルに依存し、リカバリ処理中にデータの異なるバージョン間で選択する必要があるかもしれません。あなたは自分のデータをより認識している場合は、回復の見込みので、大きいです。
4.ダウンロードperconaデータリカバリ・ツールのため、InnoDBテーブルおよびエキス、ターミナルを開き、次のように入力します。
wget https://launchpad.net/percona-data-recovery-tool-for-innodb/trunk/release-0.5/+download/percona-data-recovery-tool-for-innodb-0.5.tar.gz
tar -zxvf percona-data-recovery-tool-for-innodb-0.5.tar.gz4.1コンフィギュレーションコマンドを実行して、MySQLのソースのサブディレクトリのアンパックディレクトリに移動します。
cd percona-data-recovery-tool-for-innodb-0.5/mysql-source
./configure 4.2 コンパイル、makeコマンドを実行し、解凍後に戻ってルートディレクトリに、設定手順を完了した後page_parserとconstraints_parser工具(如果编译过程中出现问题，诸如包依赖之类的，请根据错误提示自行补全)：
cd ..
make
5.データの抽出
デフォルトのページサイズInnoDBは16K、特定のインデックスのために特定のテーブルに属するページのそれぞれです。page_parserツールはページヘッダインデックスIDに応じて、データファイルを読み取り、各ページは別々のファイルにコピーされます。
MySQLサーバが設定されている場合innodb_file_per_table=1、システムは、あなたが上記の手順を達成するために役立っています。すべての必要なページはの.ibdファイルであり、通常、あなたはそれをスライスする必要はありません。しかし、ファイルが複数のインデックスが含まれていてもよいの.ibd場合は、個々のページを分離するために切断が必要です。MySQLサーバが設定されていない場合innodb_file_per_table、データがグローバルテーブルの名前空間に格納され、その後、（ibdata1と名前の通常のファイルを、本論文では、これはそうである）、この時間は、私たちは、ページファイルのセグメンテーションを押す必要があります。
5.1カットページネーション - 解凍したフォルダのルートディレクトリに新しいdbfileにファイルやフォルダへのデータディレクトリのあなたのibdata1とコピーのファイルをコピーします。
MySQLはバージョン5.0の前に、InnoDBは冗長形式を取っている場合は5.1.1は、ターミナルで次のコマンドを実行します。
./page_parser -4 -f ./dbfile/ibdata15.1.2 MySQLの5.0以降、InnoDBのテイクは、ターミナルで次のコマンドを実行し、コンパクトな形式である場合：
./page_parser -5 -f ./dbfile/ibdata15.2。実行した後、page_parserツールは、UNIXシステムのTIMESTAMPのタイムスタンプであるpages- <TIMESTAMP>ディレクトリを作成します。このディレクトリには、インデックスIDページに各インデックスID用のサブディレクトリを作成します。図：
5.3。インデックスIDが必要を選択
あなただけのテーブルを削除せずにテーブル内のデータを削除した場合5.3.1。、あなたはInnoDBのテーブルスペースモニターは、MySQLサーバのエラー・ログ・ファイルへのすべてのテーブルとインデックスは、インデックスIDの出力を開始することができます。InnoDBストレージエンジンのテーブルとインデックスを収集innodb_table_monitor格納するテーブルを作成します。
mysql> CREATE TABLE innodb_table_monitor (id int) ENGINE=InnoDB;innodb_table_monitorがすでに存在する場合は、テーブルをドロップし、テーブルを再作成します。MySQLのエラーログ出力すると、より多くの監視をプリントアウト停止するには、このテーブルからドロップすることがあります。次のように出力の例を示します。
TABLE: name sakila/customer, id 0 142, columns 13, indexes 4, appr.rows 0
COLUMNS: customer_id: DATA_INT len 2 prec 0; store_id: DATA_INT len 1 prec 0; first_name: type 12 len 135 prec 0; last_name: type 12 len 135 prec 0; email:
type 12 len 150 prec 0; address_id: DATA_INT len 2 prec 0; active: DATA_INT len 1 prec 0; create_date: DATA_INT len 8 prec 0; last_update: DATA_INT len 4 pr
ec 0; DB_ROW_ID: DATA_SYS prtype 256 len 6 prec 0; DB_TRX_ID: DATA_SYS prtype 257 len 6 prec 0; DB_ROLL_PTR: DATA_SYS prtype 258 len 7 prec 0;
INDEX: name PRIMARY, id 0 286, fields 1/11, type 3
root page 50, appr.key vals 0, leaf pages 1, size pages 1
FIELDS: customer_id DB_TRX_ID DB_ROLL_PTR store_id first_name last_name email address_id active create_date last_update
INDEX: name idx_fk_store_id, id 0 287, fields 1/2, type 0
root page 56, appr.key vals 0, leaf pages 1, size pages 1
FIELDS: store_id customer_id
INDEX: name idx_fk_address_id, id 0 288, fields 1/2, type 0
root page 63, appr.key vals 0, leaf pages 1, size pages 1
FIELDS: address_id customer_id
INDEX: name idx_last_name, id 0 289, fields 1/2, type 0
root page 1493, appr.key vals 0, leaf pages 1, size pages 1
FIELDS: last_name customer_idここで、我々はてSakilaライブラリの下で顧客テーブルを復元している、あなたは上から、その主キー情報を取得することができます。
INDEX: name PRIMARY, id 0 286, fields 1/11, type 35.3.2データベース全体脱落した場合、それはあなたが必要なインデックスのIDを取得する方法のいくつかを使用することができ、必要なインデックスIDを見つけるために、上記の方法に従う方法はありません。
：あなたはいくつかのフィールドに必要なテーブルを識別することができた場合は持っている特別な値のみを使用すると、以下のコマンドを使用して、分割後のすべてのページを検索することができ、このテーブルに記録されます。
grep -r "CP201310090001" pages-1384167811 示すように、検索結果（インデックスID 0から968が必要とされている参照してください）。
B：あなたは特別な値を見つけることができない場合、公式のチュートリアルでは、フィールド名で分割表の後にすべてのページを検索することができるようですが、それは私が成功せず、長い時間のためにテストされ、非常に一般的言うので、必要の参照リンクがある：HTTP：// www.percona.com/docs/wiki/innodb-data-recovery-tool:mysql-data-recovery:advanced_techniques#finding_index_ids
C：最後の方法、ブルートフォース、私はメソッド内の特別な値に加えて、他のテーブルに返信したいので、Bの方法は、まずあなたが5.4を実行する必要があり、比較するために、すべてのスクリプトファイルを通じて、周期だけをアップして来ませんでした、5.5ステップ、検索の定義のための良いテーブルを生成し、constraints_parserツールをコンパイルした後、解凍したルートディレクトリにシェルスクリプトを作成して、私の名前はtest.sh、スクリプトの内容です：
#!/bin/bash
function ergodic(){
for file in ` ls $1`
do
if [ -d $1"/"$file ]
then
ergodic $1"/"$file
else
echo $1"/"$file #输出文件的完整的路径
./constraints_parser -5 -f $1"/"$file #提取数据
echo $1"/"$file #输出文件的完整的路径
sleep 1 #暂停一秒
fi
done
}
INIT_PATH="pages-1384167811/FIL_PAGE_INDEX" #这里是分页后页面文件所在的文件夹
ergodic $INIT_PATH その後、端末は、データ、および文字化けではないがあるまで出力端子を見つめ、スクリプトを実行./test.sh端末に入力し、その後、あなたはインデックスID探しているものの名前を抽出し、現在のフォルダ内のファイルは、その後、5.6,5.7を実行しますプロセスは次のように、ショットがあることができます。
5.4。あなたは、テーブルの構造、さまざまなを作成する最も簡単な方法を復元するために知っていて、テストサーバー上のデータベースにデータベースを復元することが必要で、テーブル定義、および、端末に入力します（あなたがテーブル構造を知っていない場合は、テーブル定義からも可能です詳細に.FRMファイルの返信を参照してください。http://www.percona.com/docs/wiki/innodb-data-recovery-tool:mysql-data-recovery:advanced_techniques#getting_create_table_from_frm_files）：
./create_defs.pl --host=服务器地址 --user=用户名 --password=密码 --db=数据库名 --table=表名 > include/table_defs.hあなたは上記のデータベースやテーブルの名前を間違えてその後、サブディレクトリオープンtable_defs.hファイルを含めるルートディレクトリを解凍し、生成正しいかどうかを確認し、ビルド定義ファイルを防ぐために行くことは、空であります：
5.5 constraints_parserツール（テーブル定義を再コンパイルする必要があり、各時間）をコンパイルします。
make
gcc -DHAVE_OFFSET64_T -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE_SOURCE=1 -g -I include -I mysql-source/include -I mysql-source/innobase/include -c tables_dict.c -o lib/tables_dict.o
gcc -DHAVE_OFFSET64_T -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE_SOURCE=1 -g -I include -I mysql-source/include -I mysql-source/innobase/include -o constraints_parser constraints_parser.c lib/tables_dict.o lib/print_data.o lib/check_data.o lib/libut.a lib/libmystrings.a
gcc -DHAVE_OFFSET64_T -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE_SOURCE=1 -g -I include -I mysql-source/include -I mysql-source/innobase/include -o page_parser page_parser.c lib/tables_dict.o lib/libut.a5.6あなたが最初に一つのファイルにファイルをマージする必要がある最初のレコードを抽出し、次のようにたくさんのファイルになりますフォルダのページングインデックス番号を切断した後に生成されたページをマージ：
find pages-1384167811/FIL_PAGE_INDEX/0-968/ -type f -name '*.page' | sort -n | xargs cat > pages-1384167811/FIL_PAGE_INDEX/0-968/customer_pages_concatenated組み合わせフィギュア：
統合されたデータを抽出した後5.7：
./constraints_parser -5 -f pages-1384167811/FIL_PAGE_INDEX/0-968/customer_pages_concatenated > pages-1384167811/FIL_PAGE_INDEX/0-968/customer_data.tsvファイルが抽出された後に示すように：
コンテンツファイルがテーブルに記録され、データベースにコンテンツTSVファイルに直接アクセスすることができ、また、あなたがインポートするために使用されている方法でスプレッドシートをエクセルにコンテンツをコピーするためにTSVファイルを開くことができます。
ます。https：//my.oschina.net/secyaher/blog/274474で再現