13

mysqldumpとMySQL5.1を使用して、約40のInnoDBテーブルと約1.5GBのデータを含むデータベースのコピーを作成したいと思います。

データのダンプとロードを最速にする最良のパラメーター(つまり、-single-transaction)は何ですか?

同様に、データを2番目のDBにロードする場合、次のことを行う方が迅速です。

1)結果を2番目のMySQLサーバーインスタンスに直接パイプし、-compressオプションを使用します

また

2)テキストファイルからロードします(例:mysql <my_sql_dump.sql)

4

5 に答える 5

22

静止データベースをすばやくダンプする:

mysqldump で「-T」オプションを使用すると、指定したディレクトリに多数の .sql および .txt ファイルが作成されます。これは、大きなテーブルをダンプする場合、INSERT ステートメントを含む単一の .sql ファイルよりも最大 50% 高速です (実時間で 1/3 短縮されます)。

さらに、複数のテーブルを並行してロードし、複数のコアを飽和させることができれば、復元時に大きなメリットがあります。8 コアのボックスでは、"-T" による効率の向上に加えて、ダンプを復元するための実時間で 8 倍もの差が生じる可能性があります。「-T」を使用すると、各テーブルが個別のファイルに格納されるため、大量の .sql ファイルを分割するよりも、それらを並列にロードする方が簡単です。

上記の戦略を論理的に極端に考えると、データベースを広範囲に並行してダンプするスクリプトを作成できます。まあ、それはまさに Maakit の mk-parallel-dump ( http://www.maatkit.org/doc/mk-parallel-dump.htmlを参照) と mk-parallel-restore ツールです。基礎となる mysqldump プログラムを複数回呼び出す perl スクリプト。ただし、これらを使用しようとすると、バニラ ダンプでは発生しなかった重複キー エラーなしで復元を完了するのに苦労したため、マイレージが異なる場合があることに注意してください。

LIVE データベースからのデータのダンプ (サービスの中断なし):

--single-transaction スイッチは、ライブ データベースのダンプを静止せずに取得したり、スレーブ データベースのダンプをスレーブ化を停止せずに取得したりするのに非常に便利です。

悲しいことに、-T は --single-transaction と互換性がないため、取得できるのは 1 つだけです。

通常、ダンプを取得する方が、復元するよりもはるかに高速です。着信モノリシック ダンプ ファイルを取得し、それを複数の断片に分割して並行してロードするツールの余地はまだあります。私の知る限り、そのようなツールはまだ存在しません。


ネットワーク経由でダンプを転送すると、通常は有利です

1 つのホストで受信ダンプをリッスンするには、次のコマンドを実行します。

nc -l 7878 > mysql-dump.sql

次に、DB ホストで実行します。

mysqldump $OPTS | nc myhost.mydomain.com 7878

これにより、ダンプをディスクに書き込むことによるマスター上のディスク スピンドルの競合が減少し、ダンプがわずかに高速化されます (ネットワークが追いつくのに十分な速さであると仮定すると、同じデータセンター内の 2 つのホストにとってかなり安全な仮定です)。さらに、新しいスレーブを構築する場合、これにより、終了後にダンプ ファイルを転送する必要がなくなります。

警告 - 明らかに、耐えられないほど速度が低下しないように十分なネットワーク帯域幅が必要です。TCP セッションが中断した場合は、最初からやり直す必要がありますが、ほとんどのダンプでは、これは大きな問題ではありません。


最後に、よくある混乱のポイントを 1 つ明確にしたいと思います。

mysqldump の例やチュートリアルでこれらのフラグを頻繁に目にするにもかかわらず、それらはデフォルトでオンになっているため不要です。

  • --opt
  • --add-drop-table
  • --add-locks
  • --create-options
  • --disable-keys
  • --extended-insert
  • --lock-tables
  • --quick
  • --set-charset.

http://dev.mysql.com/doc/refman/5.1/en/mysqldump.htmlから:

--opt の使用は、--add-drop-table、--add-locks、--create-options、--disable-keys、--extended-insert、--lock-tables、-- を指定するのと同じです。クイック、および --set-charset。--opt がデフォルトでオンになっているため、 --opt が表すすべてのオプションもデフォルトでオンになっています。

これらの動作の中で、「--quick」は最も重要なものの 1 つであり (最初の行を送信する前に mysqld に結果セット全体をキャッシュすることをスキップします)、「mysql」を使用できます (デフォルトでは --quick はオンになりません)。大きな結果セットを返すクエリを劇的に高速化します (大きなテーブルのすべての行をダンプするなど)。

于 2010-12-08T02:17:34.610 に答える
7

ディスクのオーバーヘッドを回避するために、別のインスタンスに直接パイプします。--compress高速LANまたはループバックではネットワークのオーバーヘッドは問題にならないため、低速のネットワークで実行している場合を除いて、気にしないでください。

于 2008-09-25T02:10:17.597 に答える
2

mysqldump を使用するのではなく、データベースの複製を試みた場合、はるかに高速になり、ディスク容量を節約できると思います。個人的には、本当に重いものを持ち上げるためにsqlyog Enterpriseを使用していますが、同じサービスを提供できるツールは他にもたくさんあります。もちろん、mysqldump だけを使用したい場合を除きます。

于 2008-09-25T12:53:05.383 に答える
2

innodb の場合、通常、 --order-by-primary --extended-insert が最適な組み合わせです。パフォーマンスが最後まで残っていて、ターゲット ボックスに多くの CPU コアがある場合は、結果のダンプ ファイルを分割し、innodb_thread_concurrency/2 までの多くのスレッドで並列挿入を行うことができます。

また、ターゲットの innodb_buffer_pool_size を余裕のある最大値に調整し、innodb_log_file_size を 128 または 256 MB に増やします (これには注意してください。mysql デーモンを再起動する前に古いログファイルを削除する必要があります。そうしないと再起動しません)。

于 2010-01-08T22:02:17.513 に答える
0

Maatkit の mk-parallel-dump ツールを使用します。

少なくともその方が早いだろう。私は mysqldump をもっと信頼します。

どのくらいの頻度でこれを行っていますか? それは本当にアプリケーションのパフォーマンスの問題ですか? おそらく、データ全体をダンプする必要のないこれを行う方法を設計する必要があります(レプリケーション?)

一方、1.5G は非常に小さいデータベースなので、おそらくそれほど問題にはなりません。

于 2010-01-08T22:18:13.497 に答える