不完全なmysqldump

mysqldumpを実行してデータベーススナップショットを作成しようとしていますが、エラーを報告せずに途中でランダムに停止します。私のデータベースは比較的小さく（約100MB）、InnoDBを使用しています。

私はそれを次のように実行しています：

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

終了コードを確認すると0が報告されます。

私のバージョン：mysqldump Ver 10.13 Distrib 5.1.52、redhat-linux-gnu（i386）

同様の投稿や公式のバグレポートもいくつか見ましたが、どちらのソリューションも当てはまらないようです。

mysqldumpで完全なデータベーススナップショットを取得するにはどうすればよいですか？

編集：私のデータベースは現在AmazonのRDSにあります。

max_allowed_packetクライアント（つまり、mysqldump）とサーバー（つまり、Amazon RDS）の両方で十分に高く設定されていないことが問題であった可能性があります。両方で500Mに設定しましたが、問題は修正されたようです。

InnoDBの情報スキーマテーブルは行数の見積もりしか提供しないため、スナップショットにRDSのすべてが本当に含まれているかどうかを判断するのは困難です。すべてのテーブルは存在しますが、行数は異なります。より完全な分析をスクリプト化する時間があるときに、より明確な回答で更新します。

やってみました？

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

これは私がいつも問題なく行う方法と同じです。基本的にこの方法でダンプを行うと、コミットされていないトランザクションを無視して、特定の瞬間に持っているすべてのもの（データ、オブジェクト、そして時には貴重なコメント）を取得できます。

私が理解している限り、mysql docs --single-transactionは、ダンプ中にテーブルで読み取りが実行されると失敗します。「--force --single-transaction --quick」なしで実行した場合の結果は何ですか？

テーブルが破損している可能性があります。データやインデックスページが破損しているという意味ではありません。壊れている非常にシンプルなものがあるかもしれません。

最近、mysqldumpで複数のデータベースを並列処理したときに、スレーブサーバーでバックアップスクリプトの問題が発生しました。いずれかのデータベースでmysqldumpを実行すると、非常に小さなmysqldumpが発生しました。DBには80以上のテーブルがありました。ただし、mysqldumpはDBの5番目のテーブルで停止しました。SHOW CREATE TABLE tblname\Gスレーブのテーブルで実行すると、「テーブルが見つかりません」というエラーが発生しました。私が走ったときにSHOW CREATE TABLE tblname\Gマスターで期待どおりに、テーブルの説明が表示しました。

起こったのは少しおかしなことでした。クライアントがテーブルの復元を要求し、エンジニアがInnoDBテーブルの.ibdファイルをディスクバックアップから復元しました。.ibdファイルのテーブルスペースID（25）は、ibdata1に登録されたテーブルスペースID（28）と一致しませんでした。

スレーブをホスティングし、mysqldumpをマスターし、レプリケーションを最初からセットアップして、問題を修正しました。幸い、データとインデックスの合計は7GBでした。したがって、rstoreプロセスは大した問題ではありませんでした。

この話の教訓

基本的な問題は、テーブルスペースIDが正しくない場合、mysqldumpがInnoDBでエラーを報告しないことです。mysqldumpが終了し、すべてのテーブルをアルファベット順にダンプしない場合、それはエラーによって終了し、エラーメッセージを出力せずに終了したことを示しています。

確認してください

• あなたはを使用してテーブルの構造を表示することができます SHOW CREATE TABLE
• INFORMATION_SCHEMA.TABLESからテーブルに関するすべてをクエリできます

以下は、mysqldumpとInnoDBのブレインストーミングです。

InnoDBテーブルに対するmysqldumpの動作について考えてください。ダンプしているテーブルに属するInnoDBバッファープールにダーティページがある場合、そのテーブルのダーティページは、SELECT /* SQL_NO_CACHE */に対して実行する前にディスクにフラッシュする必要があります。

Amazon RDSを使用しているので、私の直感は、データベースがマルチテナントインフラストラクチャにあることです（これを単純化しすぎている場合は、このステートメントを自由に修正してください）。他のデータベースは、共有InnoDBバッファープール、共有メタデータファイル（ibdata1）、および共有テーブルスペース（innodb_file_per_tableが無効の場合はibdata1）を使用している可能性があります。

小さなデータセットであっても、データベースに冗長性があり、データベースに対するMVCCに影響を与える可能性があります。

mysqldumpセッションでinnodb_lock_wait_timeout（デフォルトは50秒）を増やして、これがAmazon RDSに影響するかどうかを確認する（またはAmazonにこの制限を増やす）ことができます。また、個々のテーブルをダンプしてみてください。

UPDATE 2011-11-14 17:58 EDT

これをDBセッション内で実行してみてください（2分に設定）：

SET innodb_lock_wait_timeout = 120;