MySQL の復元が遅いと思われるものがあり、チューニングのアドバイスを探しています (私は PostgreSQL と SQL Server の専門家です)。
開発サーバーには、48 GB の RAM、8 コア、Centos 6.2 64 ビットおよび MySQL 5.1.61 (本番環境の MySQL と同じ) を実行し、ソフトウェア管理 RAID-10 / XFS の 4 x 7200 RPM SAS ドライブがあります。唯一の MySQL クライアント プロセスは復元です。ダンプは、本番サーバー上のすべてのデータベースのプレーンな mysqldump で取得されました。
FOREIGN_KEY_CHECKS と UNIQUE_CHECKS をゼロに設定するなど、 http://derwiki.tumblr.com/post/24490758395/loading-half-a-billion-rows-into-mysqlからいくつかのオプションを適用しました。以下に my.cnf を含めました。
mytop と pv (pv backup.sql | mysql -u root -p) を使用して復元を監視すると、INSERT INTO ステートメントが徐々に遅くなり始めているように見えます。mytop で表示される qps は 3 から始まり、ダンプ ファイルによって 60% で 0 に低下します。この場合、3 つの挿入 (値を含む) はまだ遅いように見えるため、mytop がどれほど正確かはわかりません。htop は、MySQL が使用する CPU の CPU 使用率が 10% 未満であり、48 GB の RAM のうち 8 GB 未満しか使用されていないことを示しています。
データベースは異なりますが、復元手法は似ていますが、PostgreSQL を使用すると、同じサーバー上で約 5 ～ 10 倍高速に実行されます。
アイデア？
[mysqld]
# my.cnf
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
slow-query-log
long_query_time = 60
log-slow-admin-statements
slow_query_log_file = /var/log/mysql_slow.log
innodb_buffer_pool_size = 2G
max_allowed_packet = 1G
key_buffer_size = 1G
concurrent_insert = 1
innodb_flush_log_at_trx_commit = 2
bulk_insert_buffer_size = 1G
innodb_flush_method = O_DIRECT