MySQLにインポートする必要があるこの32 GBの巨大なSQLダンプがあります。以前は、そのような巨大なSQLダンプをインポートする必要がありませんでした。私はいつものことをしました:
mysql -uroot dbname < dbname.sql
時間がかかりすぎています。約3億行のテーブルがあり、約3時間で150万行に達しています。したがって、全体で600時間(24日)かかり、実用的ではないようです。だから私の質問は、これを行うより速い方法はありますか?
innodb_flush_log_at_trx_commit = 2
提案通り ここ は(明確に見える/指数関数的な)改善を行わないようです。PerconaのVadim Tkachenkoは、InnoDBのこの優れた絵画表現を作成しました
あなたは間違いなく以下を変更する必要があります
innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16
innodb_flush_log_at_trx_commit = 0
なぜこれらの設定なのか?
.ibd
ファイルへのサービス書き込み操作。 MySQL Documentation on Configuring the Number of Background InnoDB I/O Threads
によると、各スレッドは最大256個の保留中のI/O要求を処理できます。 MySQLのデフォルトは4、8はPercona Serverです。最大は64です。このようにmysqlを再起動します
service mysql restart --innodb-doublewrite=0
これにより、InnoDB二重書き込みバッファが無効になります
データをインポートします。完了したら、mysqlを通常どおり再起動します
service mysql restart
これにより、InnoDBの二重書き込みバッファが再び有効になります
試してみる !!!
サイドノート: 最新のセキュリティパッチについては5.6.21にアップグレードする必要があります 。
データベース全体を復元する必要がありますか?そうでない場合、私の2c:
特定のテーブルを抽出して、「チャンク」で復元を実行できます。このようなもの:
zcat your-dump.gz.sql | sed -n -e '/DROP TABLE.*`TABLE_NAME`/,/UNLOCK TABLES/p' > table_name-dump.sql
私は1回実行しましたが、必要なテーブルを抽出するのに10分ほどかかりました。完全な復元には、13〜14時間かかり、35 GB(gzip圧縮)ダンプが必要でした。
/pattern/,/pattern/p
と-n
パラメータを使用すると、「パターン間」のスライスが作成されます。
とにかく、35 GBを復元するために、AWS EC2マシン(c3.8xlarge)を使用し、yum(Centos)を介してPerconaをインストールし、my.cnf
に次の行を追加/変更しました:
max_allowed_packet=256M
wait_timeout=30000
数は多すぎると思いますが、私のセットアップではうまくいきました。
データベースをインポートする最も速い方法は、MyISAMの場合は(.frm、.MYD、.MYI)ファイルを/ var/lib/mysql/"データベース名"に直接コピーすることです。
そうでなければあなたは試すことができます:mysql > use database_name; \. /path/to/file.sql
これは、データをインポートする別の方法です。
インポートを高速化する1つの方法は、インポート中にテーブルをロックすることです。 mysqldumpに--add-locksオプションを使用します。
mysqldump --add-drop-table --add-locks --database db > db.sql
または、 -opt を使用していくつかの有用なパラメーターをオンにすることもできます。これにより、ダンプに役立つ多くのものがオンになります。
mysqldump --opt --database db > db.sql
サーバーに別のストレージデバイスがある場合は、それを使用します。あるデバイスから別のデバイスにコピーすることで、転送を高速化できます。
-ignore-table で不要なテーブルを除外することもできます