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のドキュメント--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
を使用してテーブルの構造を表示できます以下は、mysqldumpとInnoDBのブレーンストーミングです。
InnoDBテーブルに対するmysqldumpの動作について考えてください。ダンプするテーブルに属するInnoDBバッファープールにダーティページがある場合、SELECT /* SQL_NO_CACHE */
を実行する前に、そのテーブルのダーティページをディスクにフラッシュする必要があります。
Amazon RDSを使用しているので、私の直感は、データベースがマルチテナントインフラストラクチャにあるということです(これを単純化しすぎている場合は、このステートメントを自由に修正してください)。他のデータベースは、共有InnoDBバッファープール、共有メタデータファイル(ibdata1)、および共有テーブルスペース(ibdata1 if innodb_file_per_table が無効)を使用している可能性があります。
また、データベースの冗長性が発生している可能性もあります。これは、データベースに対して [〜#〜] mvcc [〜#〜] に影響を与える可能性があります。小さなデータセットですが。
Mysqldumpセッションで innodb_lock_wait_timeout(default 50 seconds) を増やして、これがAmazon RDSに影響するかどうかを確認する(またはAmazonにこれを増やす)制限)。また、個々のテーブルをダンプしてみてください。
UPDATE 2011-11-14 17:58 EDT
これをDBセッション内で実行してみてください(2分に設定):
SET innodb_lock_wait_timeout = 120;