大規模なMySQLデータベースのダンプ/復元
非常に興味深いタスクを得ました。AWSからmysqlデータベースをダンプし、プライベートクラウドに復元する必要があります。データベースは非常に大きく、各db.sqlダンプは160GB、120GB、21GBです。同じオーロラrdsインスタンス内の3つすべて、AWSのインスタンススナップショットは700GBです。 MySQLバージョン5.6、innodbを使用。現時点では20時間のサイエンスリストアが実行されていますが、4〜6時間で完了すると推定されているため、完全なリストアは約24時間であり、本番環境ではダウンタイムが長すぎます。私の質問：復元を高速化するためにmysqlを調整する方法は？前もって感謝します。
P.Sダンプは3時間半で完了しました。
インポートでボトルネックとなっているものを確立しましたか？ CPUボトルネックが発生している場合、シングルスレッドパフォーマンスの高いCPUをプライベートクラウドインスタンスに配置する以外に、実行できる量は非常に限られています。
役立ついくつかのこと：
innodb_doublewrite=0
innodb_flush_logs_on_trx_commit=0
innodb_io_capacity=<approximate amount of IOPS your storage can provide when using 16KB random writes>
innodb_log_file_size=1G
innodb_log_files_in_group=24 # you will want to change this later!
performance_schema=0
slow_query_log=0
general_log=0
注：インポートが完了したら、これらのオプションをすべて削除してください。これらのオプションは危険であり、通常のランタイム操作には適していません。これらは、ロールケージとシートベルトを外すことによる軽量化により、レースカーの速度を上げるのと同じです。
ドライバーがそのようなものをサポートしている場合、インポートマシンの仮想ディスクでディスク書き込みキャッシュを有効にしました。
インポート中に十分なRAM=を取得できる場合は、ib_logfile *ファイルが作成されたら、mysqldを停止し、それらのファイルとibdata1をtmpfsに配置して、シンボリックリンクします。完了したら、mysqldを停止します。それらを元に戻します。
ZFSがオプションの場合は、/ var/lib/mysqlを次の設定のボリューム上のZFSに配置します。
compression=lz4
logbias=throughput
recordsize=16k
sync=disabled
xattr=sa
これにより、圧縮とsync = disabled機能により、他のファイルシステムと比べて書き込みスループットが約2倍になります。インポートが完了したら、必ずsync = standardを設定してください。
上記のすべてを組み合わせてディスクI/Oを制限すると、倍数のパフォーマンスが向上します。 CPUが限られている場合は、上記により2桁の改善％ポイントが得られます。