4

TableName＃P＃pname.ibdの形式の.ibdファイルだけからパーティション化されたmysql InnoDBテーブルを復元するにはどうすればよいですか？Chris Calendarの記事 http://www.chriscalender.com/?p=28 は、単一の.ibdファイルを持つパーティション化されていないテーブルで機能しますが、「破棄」と「インポート」の手順では、「ストレージエンジンは機能しません。パーティションテーブルの場合、「このオプションがあります」というエラーが発生します。

上記のリンクのコメントの1つにあるWesSmithは、一度に1つのパーティションをインポートする手動の手順を提案していますが、それは私にはうまくいきませんでした。パーティション化されていないテーブルを作成し、TableName.ibdという名前に変更された最初の.ibdファイルを移動してインポートを実行することで彼のアプローチに従おうとすると、インポートは成功しますが、テーブルに行がありません。「パーティションに追加し直す」という次の提案された手順は"alter table TableName partition by range ... (partition pname1 values less than (...) ENGINE=InnoDB)"、TableName.ibdファイル（最初のパーティションに対応）を簡単なサイズの新しいTableName＃P＃pname1.ibdに衝撃的に置き換えてみました。これを試してみると、1つのパーティションに相当するデータが失われました。リカバリするパーティションが約150あります。

.ibdファイルからデータを回復する方法について何かアドバイスはありますか？ありがとう。

4

1 に答える 1

1

したがって、元の投稿のリンクにあるコメントで提案されているアプローチは、結局は機能することがわかります。上記の「altertable...」の手順で説明したパーティションの削除は、ibdataファイルとログファイルが失われる前に元のテーブルで意図的に削除されていたため、正当でした（ただし、mysqlは.ibdファイルを削除せずに残します） 。回復プロセスは非常に遅いですが、私はそれをスクリプト化することができ、次の数日で完了するまで実行できるようにしたいと思っています。

リカバリするパーティションが多数ある同様の状況に陥った場合のヒントを次に示します。100個のパーティションを持つテーブルTableNameがあるとします。通常、100個のパーティションは「createtable」ステートメントを介して作成された場合、連続したinnodb IDを持ちますが、作成後にパーティションが追加された可能性があるため、通常はそうではありません。したがって、手順は次のとおりです。

1）上記のブログでCalendarの方法を使用して、各パーティションに対応するinnodbIDを次のように見つけます。この手順では、mysqlサーバーを再起動する必要がないことに注意してください。TableNameのようなテーブルをパーティションなしで作成し、そのテーブルスペースを破棄するだけです。次に、最初のパーティションの.ibdファイル（TableName＃P＃pname1.ibdなどの名前）をTableName.ibdという名前のデータベースディレクトリに移動し、インポートしてみます。mysql error.log（通常は/var/log/mysql/error.log）を調べて、そのパーティションのinnodbIDが何であるかを確認します。ファイル内のすべてのパーティションに2タプル（innodb_ID_i、partition_boundary_i）ができるまで、パーティションごとに（または必要に応じて）この手順を繰り返します。

2）空のinnodb状態で開始します（サーバーを停止し、ibdataとib_logfile *を削除し、サーバーを再起動します）。上記の手順1のファイルのinnodb_IDエントリごとに、TableNameのようなテーブルTableName_iを作成します。たとえば、100個のパーティションがID 321、322、...、370、415、416、... 464（それぞれ50個の連続したIDの2つのブロック）に対応する場合、320個のダミーテーブル、50個のテーブルを作成するスクリプトを記述します。 TableNameのように、45個のダミーテーブル、TableNameのように50個のテーブル。

3）上記で作成したTableName_iテーブルごとに、

--do 

     (i) rename table TableName_i to TableName

     (ii) alter table TableName discard tablespace // important to do this step before the next one

     (iii) mv TableName#P#pname_i.ibd TableName.ibd // with the appropriate directory prefixes

     (iv) alter table TableName import tablespace

     (v) alter table partition by range (partition_field) (partition pname_i values less than (partition_boundary_i))   // This is the most and only time consuming step

     (vi) rename table TableName to TableName_i // or some other name or just dump it to a file

--repeat

上記のすべてのステップはスクリプト可能であり、空のinnodb状態で開始するために、ステップ2の開始時を除いて、どの時点でもサーバーを再起動する必要がないことに注意してください。次のステップに進む前に、ステップ3の各サブステップの成功のチェックを導入するように注意してください。そうしないと、後続のステップが失敗したり、.ibdファイルが上書きされたりする可能性があります。可能であれば、mvの代わりにステップ3（iii）のコピーを使用します。

最後の注意：16進編集を使用するperconaのリカバリツールキットを使用する方が少し簡単な方法があるかもしれませんが、これはパーティションテーブルの私の場合には機能しませんでした。http://www.mysqlperformanceblog.com/2011/05/13/connecting-located-ibd-files/のコメントの1つに記載されているように、パーティション化されたテーブルで、同じ、一見未解決の問題が発生しました。ただし、マイレージは異なる場合があります。（上記のステップ3（v）のように）パーティションの再作成を回避する方法があれば、それは本当に素晴らしく迅速ですが、パーティションがあるかどうかはわかりません。

于 2012-09-03T05:27:11.193 に答える