特定のテーブルに 4 ペタバイトのデータが含まれていると認識される状況があります。 すごい話に聞こえるかもしれませんが、60 GB のパーティションにのみ存在するのです。
このテーブルには 9 つのフィールドがあります。そのうちの 1 つはフィールドですdomain_id。行の数はおよそ 6,300 しかないため、行を識別するのに最適なフィールドです。一致させる唯一の他のフィールド オプションには 200 万を超えるレコードがあり、これはさらに困難です。
4PB のデータすべてを出力しようとして、それに近づく前にドライブがいっぱいになってしまうため、単純な mysqldump は実行できません。そのため、必要なデータを外科的に削除し、データベースを破壊して再作成する必要があります。
各レコードのダンプができればdomain_id、そこから使用可能なデータのほとんどを取得できると思います。私が使用しようとしているのは次のものです。
mysqldump -u root --skip-opt -q --no-create-info --skip-add-drop-table \
--max_allowed_packet=1000000000 database table --where="domain_id=10" \
> domains10.sql
これを使用すると、 のすべての行domain_id 10がエクスポートされることを期待します。
しかし、エクスポートを確認すると、1 行しか取得されませんが、DB を見ると、多数の行があります。演算子が 1 行だけを見つけて、その後諦めるかのようです。
さまざまな演算子を試しました。 または を使用すると、<より>多くのデータを取得できますが、データが侵害された特定の行でエクスポートが停止します。 6000 を超える行を調べる必要があるため、エクスポートで影響を受ける行を簡単に絞り込むことができません。
したがって、必要なのは、基本的に私が考えていたとおりのことを実行し=、特定のフィールドに一致するすべてのレコードをエクスポートするだけの演算子です。
また、この DB にアクセスできるようにする唯一の方法は、InnoDB 強制リカバリ 3 を使用することです。この操作を実行した後、MySQL を再び機能させるために DB を削除する必要があるため、これを正しく実行する必要があります。
役に立つ回答をお待ちしております。
答え1
あなたの書き込みから判断すると、データベースが破損しているようです (60 GB ではなく 4 PB と考えると、それが何となくわかります)。
最初に DB を修復しない限り、取得した情報の信頼性を保証できるとは思えません。これを試しましたか?
それ以外の場合、エラーが発生しても続行するために「-f」キーを実行するとどうなりますか?
答え2
テーブルは実際どれくらいの大きさであるべきだと思いますか?
これを myisam に変換してみることもできます:
alter table ggg engine=myisam;
ただし、データベースが破損しているようです。
最善の策は、サポートのために innodb の担当者に連絡することかもしれません。
答え3
私はデータベース管理者ではないので、この考えは完全に間違っているかもしれませんが、ダンプには、すべてのレコードでテキスト文字列と一貫性があるはずのデータがありますか? 「4 ペタバイト」のデータベースをダンプして、grep/文字列フィルターを介してリダイレクトし、破損したデータが有効な文字列でない場合はディスクに書き込まれないようにすることは可能でしょうか。ただし、破損したデータが理解不能なゴミであるかどうかによって異なります...
そうしないと、他の誰かがデータベースを修復するための修復ツールを提案する必要があります。
答え4
を追加してみてください--skip-extended-insert。ファイルに書き込むときに内容が壊れてしまう可能性があります。