mysqldump を使用して MySQL InnoDB データベースをダンプしてロードする最も簡単な方法は何ですか?

StackOverflow https://stackoverflow.com/questions/131085

  •  02-07-2019
  •  | 
  •  

質問

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

最適なパラメータは何ですか (例:--single-transaction) を使用すると、データのダンプとロードが最速になりますか?

また、データを 2 番目の DB にロードするときは、次の方が速いですか?

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

または

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

役に立ちましたか？

解決

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

他のヒント

静止したデータベースを素早くダンプします。

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 はオンになりません)。大きな結果セットを返すクエリ (大きなテーブルのすべての行をダンプするなど) を劇的に高速化します。

試してみると、はるかに高速になり、ディスクスペースを節約できると思います データベースのレプリケーション mysqldump を使用するのとは対照的に。個人的に私は使っています スクリョグエンタープライズ 私の本当に力仕事のおかげですが、他にもたくさんのことがあります その他のツール 同じサービスを提供できるもの。もちろん、mysqldump のみを使用したい場合は別です。

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

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

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

少なくともその方が速いでしょう。私は mysqldump をもっと信頼します。

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

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top