Mysqldumpファイルから30GBのデータベースを新しいサーバーの空のデータベースに復元しています。ダンプファイルからSQLを実行すると、復元は非常に速く開始され、その後、徐々に遅くなります。個々の挿入に15秒以上かかります。テーブルはほとんどが1つの小さなInnoDBを持つMyISAMです。サーバーには他にアクティブな接続がありません。 SHOW PROCESSLIST;
は、復元からの挿入(およびshow processlist自体)のみを表示します。
誰かが劇的な減速を引き起こしている可能性があるアイデアを持っていますか?
進行中の復元を高速化するために変更できるMySQL変数はありますか?
プロセスを遅くしている可能性のあるものの1つは key_buffer_size です。これは、インデックスブロックに使用されるバッファのサイズです。 RAM=の30%以上になるように調整してください。そうしないと、インデックスの再作成プロセスが遅くなる可能性があります。
参考までに、InnoDBと外部キーを使用していた場合は、外部キーチェックを無効にして、最後に再度有効にすることもできます(SET FOREIGN_KEY_CHECKS=0
およびSET FOREIGN_KEY_CHECKS=1
を使用)。
このリンクは、復元プロセスをスピードアップするために何ができるかを示しています。
http://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-bulk-data-loading.html
ダンプファイルの先頭にコマンドを置くことができます
SET @OLD_AUTOCOMMIT=@@AUTOCOMMIT, AUTOCOMMIT = 0;
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS = 0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS = 0;
そして、これらのステートメントをダンプファイルの最後に置きます
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
SET AUTOCOMMIT = @OLD_AUTOCOMMIT;
COMMIT;
これでうまくいきました。ハッピー復元:-)
ダンプファイル(DBディレクトリ)の物理コピーがある場合、新しいサーバーのMySQLバージョンが同じで問題なく動作する場合は、それを新しいサーバーにコピーできます。これはMyISAMでうまく機能し、私にとっては、論理SQLダンプファイルに基づいてデータを復元するよりも良いと思います。
復元が徐々に遅くなる理由をイメージできる唯一の理由は、インデックス作成です。インデックス作成を最後までオフにして、一度にすべてを実行することを検討してください。
これは行います:
mysql --init-command = "SET SESSION FOREIGN_KEY_CHECKS = 0; SET UNIQUE_CHECKS = 0;" -u root -p <Backup_Database.mysql
複数のテーブルがある場合は、 mk-parallel-restore の恩恵を受ける可能性があります。