mysql インポートの速度を向上させる

説明されている方法でダンプと復元を行うと、MySQL はデータのインポート時にインデックスを完全に再構築する必要があります。また、毎回データを解析する必要があります。

MySQL が既に理解している形式でデータファイルをコピーできれば、はるかに効率的です。これを行う良い方法は、Percona の innobackupex を使用することです

(オープンソースであり、ここからダウンロードできる XtraBackup の一部として配布されます)。

これにより、MyISAM テーブルのスナップショットが作成され、InnoDB テーブルの場合は基になるファイルがコピーされ、それらに対してトランザクションログが再生され、一貫した状態が保証されます。これは、稼働中のサーバーからダウンタイムなしで実行できます (それが要件かどうかはわかりません)。

ドキュメントを読むことをお勧めしますが、最も簡単な形式でバックアップを取るには:

$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
$ innobackupex --apply-log /path/to/BACKUP-DIR/

データが同じマシン上にある場合、innobackupex には単純な復元コマンドもあります:

$ innobackupex --copy-back /path/to/BACKUP-DIR

実際にバックアップを行うには、さらに多くのオプションとさまざまな方法があるため、開始する前にドキュメントをよく読むことをお勧めします。

速度の参考として、約 600 IOPS を実行する低速のテストサーバーは、この方法を使用して約 4 時間で 500 GB のバックアップを復元できます。

最後に：インポートを高速化するために何ができるかについて言及しました。ほとんどの場合、ボトルネックが何であるかに依存します。通常、インポート操作は I/O バウンドであり (io 待機をチェックすることでこれをテストできます)、それを高速化する方法は、より高速なディスクスループットを使用することです。つまり、ディスク自体を高速化するか、より多くのディスクを同時に処理します。

「max_allowed_packet」を増やしてください "変数を十分なサイズに変更します。これは、大量のテキストデータがある場合に非常に役立ちます。高性能ハードウェアを使用すると、データのインポート速度が確実に向上します。

mysql --max_allowed_packet=256M -u root -p < "database-file.sql"

できることの 1 つは、

SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS=0

また、値で遊ぶこともできます

innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_flush_method

my.cnf でしかし、一般的には、残りの innodb パラメーターも見て、自分に最適なものを確認する必要があります。

これは私が過去に抱えていた問題であり、完全に取り組んだとは感じていませんが、最初からこの方向に向けていたと思います.かなりの時間を節約できたはずです。

問題の理由を完全に理解するために、不足しているパラメーターが多数あります。など:

<オール>

MySQL のバージョン

ディスクの種類と速度

MySQL サーバーを起動する前にサーバーのメモリを解放する

mysqldump の前後の iostat 出力。

最初にダンプファイルを作成するために使用するパラメータは何ですか。

そこで、問題はディスクにあると推測してみます。なぜなら、私は 1 つのインスタンスで 3 TB のデータを管理している MySQL のインスタンスを 150 個持っており、通常はディスクに問題があるからです

では、解決策を見てみましょう:

まず、MySQL が最高のパフォーマンスを発揮するように構成されていません。

構成する最も重要な設定については、Percona ブログの投稿で読むことができます:http://www.percona.com/blog/2014/01/28/10-mysql-settings-to-tune-after-installation/

特にパラメータを確認してください:

innodb_buffer_pool_size 
innodb_flush_log_at_trx_commit
innodb_flush_method

問題がディスクにある場合 (同じドライブからファイルを読み取っている場合)、問題が悪化しています。

また、利用可能な RAM が不足しているために MySQL サーバーがスワップを開始した場合、問題はさらに大きくなります。

それを把握するには、復元手順の前と実行時にマシンで診断を実行する必要があります。

さらに、別の手法を使用して再構築タスクを実行することをお勧めします。これは、mysqldump よりも高速に機能します。

Percona Xtrabackup です - http://www.percona.com/doc/percona-xtrabackup/2.2/

それを使用してバックアップを作成し、そこから復元するか、ストリーミングオプションを使用して実行中のサーバーから直接再構築する必要があります。

また、5.5 以降の MySQL バージョン - InnoDB は MyISAM よりも高速に実行されます。すべてのテーブルをそれに変更することを検討してください。