web-dev-qa-db-ja.com

MYSQLバックアップの復元は非常に遅い

私は16GBの26GBのmysqlダンプファイルを復元していますRAM MacOSで実行されているMySQL。

最初に私はこのようにmysqlバックアップを復元しようとしました

mysql -ufoo -pbar foo < foo.dump

これはmySQLをクラッシュさせました。これは、foo.dumpに非常に面白い国際文字が多数含まれており、上記のコマンドがエンコーディングを処理していなかったためです。

だから私は試しました

mysql -uroot -p --default-character-set=utf8 foo
mysql> SET names 'utf8'
mysql> SOURCE foo.dump

これは機能し、面白い国際文字が正しく処理されたと思うので、復元プロセスはクラッシュしませんでした。

しかし、現在、復元プロセスは非常に遅いです。 26 GBのファイルの場合、それは一晩中実行されています（4000万行の1つのテーブルが原因です）。 15秒ごとに約3000行を復元していることがわかります。しかし、この速度では、復元プロセスは永遠にかかります。

それで、ダンプファイルを速く復元し、エンコーディングを台無しにしない方法はありますか？

backupmysqlrestore
1
Knows Not Much

SQL操作のディスクI/Oアクティビティが重いため、プロセスが遅くなります。集中的な操作のためにinnodbを最適化する必要があります。次の行を持つようにmysql構成ファイルを変更します。

innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16

innodb_buffer_pool_size： InnoDBがテーブルとインデックスデータをキャッシュするメモリ領域。テーブルデータがInnoDBバッファープールにキャッシュされている場合、ディスクI/Oを必要とせずに、クエリによって繰り返しアクセスできます。データの変更は、すぐにディスクに書き込まれるのではなく、キャッシュされます。

バッファプールが大きいほど、同じテーブルデータに複数回アクセスするために必要なディスクI/Oが少なくなります。専用データベースサーバーでは、バッファプールサイズをマシンの物理メモリの80％に設定するか、システムメモリの50 to 75パーセントを使用する場合があります。デフォルトのバッファプールサイズは128MBです

innodb_log_buffer_size： InnoDBがディスク上のログファイルへの書き込みに使用するバッファーのサイズ（バイト単位）。

大きなログバッファを使用すると、トランザクションをコミットする前にログをディスクに書き込むことなく、大きなトランザクションを実行できます。したがって、多くの行を更新、挿入、または削除するトランザクションがある場合、ログバッファーを大きくすると、ディスクI/Oが節約されます。

innodb_log_file_size：ロググループ内の各ログファイルのバイト単位のサイズ。サイズが大きいと、サーバーはワークロードアクティビティの山と谷を滑らかにすることができます。これは、多くの場合、1時間以上の書き込みアクティビティを処理するのに十分なREDOログスペースがあることを意味します。値が大きいほど、バッファープールで必要なチェックポイントフラッシュアクティビティが少なくなり、ディスクI/Oが節約されます。

Innodb_write_io_threads： InnoDBでの書き込み操作のI/Oスレッドの数。デフォルト値は4です。InnoDBはバックグラウンドスレッドを使用して、さまざまなタイプのI/O要求を処理します。 。 innodb_read_io_threadsおよびinnodb_write_io_threads構成パラメーターを使用して、データページで読み取りおよび書き込みI/Oを処理するバックグラウンドスレッドの数を構成できます。

これらのパラメーターは、それぞれ読み取り要求と書き込み要求に使用されるバックグラウンドスレッドの数を示します。各バックグラウンドスレッドは、最大256の保留中のI/O要求を処理できます。

4
Ben Njeri