mysqlデータベースの復元に時間がかかる
Ubuntuサーバーをrhel6サーバーに再インストールしています。私はかなり巨大なデータベースを持っています。 mysqlデータディレクトリのサイズを確認したところ、約54 GBでした。ただし、mysqldumpコマンドを使用してデータベース全体をダンプしました。
マシンを再インストールした後、mysqlコマンドを使用してデータベースの復元を開始しました。 3日前に復元プロセスを開始しました。この新しくインストールされたマシンのmysqlデータディレクトリを確認すると、サイズは1 GBです。実際にmysqlコマンドがデータベースを復元しているのかどうか混乱しています。コマンドがまだ実行されているのがわかり、プロセスはlinux topコマンドから表示されます。プロセスをスピードアップするために何か他にできることはありますか？
主にinnodbテーブルを使用している場合は、innodb_buffer_pool_sizeを可能な限り大きくします（mysqldだけが実際にRAMを消費していると仮定して、システムの80〜90％まで）。ただし、これにはmysqldの再起動が必要です
リロードの前に、innodb_flush_log_at_trx_commit = 2を設定して高速化することもできます。これにより、コミットごとにディスクへのフラッシュが無効になります（ACIDのDが壊れます）が、復元には問題ありません。このプロセス中に致命的な障害が発生した場合は、とにかくゼロから始めます。復元後は必ず1に戻してください。
これはバウンスなしで動的に変更できます
Cnfでinnodb_flush_method = O_DIRECTが設定されていることを確認します。これには再起動が必要です
上部のCPUにペグされていますか？本質的に低速になる圧縮テーブルデータが大量にある場合。より高速なコアを得ることを除いて、これについてできることはあまりありません。とにかくロードが連続して行われるので、マルチコアはここでは役に立ちません。
回転ディスクを使用している場合は、可能であれば、.sqlソースファイルが別のHDDセットから読み取られていることを確認してください。同様に、リロード中（リロードを複製させようとしている場合を除く）は、バイナリロギングと一般ロギングがオフになっていることを確認してください。
5.6を実行している場合は、パフォーマンススキーマがnotが有効になっていることを確認してください。
Mysqldumpからの復元はバックアップを取るよりも時間がかかるため、これは予想されたものです。
プロセスを高速化するには、他のバックアップツールを検討してください。
xtrabackup。 InnoDBのノンブロッキング、ファイルコピーとほぼ同じ速さ。バイナリバックアップを取得します（= InnoDBテーブルスペースをコピーします）。
mydumper。論理バックアップをとりますが、複数のスレッドで実行できるため、mysqldumpよりも高速です。
mylvmbackup。また、非常に高速ですが、LVMを必要とし、スナップショットの作成時にパフォーマンスに影響を与えます。
オプション＃1を使用します。
通常、mysqldumpはバックアップにxtrabackupと同じくらいの時間がかかりますが、復元する場合ははるかに遅くなります。 mysqldumpによってエクスポートされたsqlファイルが1つずつ実行される必要がある間、xtrabackupはブロックごとにコピーを戻すためです。
いくつかの方法でインポート速度を改善できると確信していますが、特にこのような巨大なデータベースでは、非常に長い時間がかかります。
そのため、xtrabackupをインストールし、完全バックアップを実行してから、新しいサーバーに復元することをお勧めします。
またはもっと簡単な方法として、コールドバックアップを実行できるようにするには、mysqlサーバーをオフにし、ibdata1、ib_logfile*、mysqlフォルダーなどを含むすべてのファイルを新しい場所にコピーし、変更します。 my.cnf変更された場合は新しい場所。まだ試していませんが、問題はありませんでした。
最初の方法は絶対に最善です。
これがお役に立てば幸いです。