Percona Xtrabackupでは、以前から以下の2つの圧縮方式が選択できました。
- quicklz
- lz4
まだtech preview ではありますが、v8.0.30では第三の圧縮方式としてZSTDを選択できるようになりました。
今回は、以下の観点で今までの圧縮方式とZSTDを比較してみようと思います。
- 圧縮効率
- バックアップ速度
- 解凍速度
テストデータについて
今回テストデータについては、TPC-Hのデータを利用しました。
また、テーブル定義の作成については、MySQL HeatWave 用の公開ベンチマークのDDLスクリプトを利用させて頂きました。
./dbgen -s 100 として 約100GB のデータセットを作成し、TPC-Hで使用するテーブルセットのそれぞれのテーブルを5つずつ作成しました(LINEITEM_1, LINEITEM_2…のように)
そして、100GBのデータセットをそれぞれのテーブルセットにインポートしましたので、最終的には 672 GB となりました。
|
1 2 |
# du -sh /var/lib/mysql/tpch 672G /var/lib/mysql/tpch |
前述のDDLスクリプトでは、 LINEITEMテーブルがKEYパーティションとなっているため、複数のテーブルスペースファイルに分割されており、テーブルスペースファイル数としては tpch データベースに 675ファイル 存在するという結果になりました。
|
1 2 |
# ls /var/lib/mysql/tpch/*.ibd | wc -l 675 |
検証環境について
今回は、Oracle Cloud上に構築したインスタンスを利用しました。
スペックは以下のようにしました。
| リソース | 値 |
|---|---|
| Shape | VM.Standard.E4.Flex |
| OCPU | 8(=16core) |
| ネットワーク帯域幅(Gbps) | 8 |
| MEMORY | 32GB |
| OSイメージ | Oracle-Linux-8.6-2022.12.15-0 |
| Boot Volume | Size: 1TB/VCPU: 20(50,000 IOPS, Throughput 614.4MB/s) |
| Block Volume | Size: 1TB/VCPU: 40(75,000 IOPS, Throughput 860.16MB/s) |
MySQLのdatadirはBoot Volumeに、バックアップはBlock Volumeにあるという構成です。
実行前準備について
圧縮・解凍を行うために各圧縮ソフトをインストールしておく必要があります。
|
1 2 |
yum install zstd lz4 yum install https://repo.percona.com/yum/release/8/RPMS/x86_64/qpress-11-3.el8.x86_64.rpm |
Percona Xtrabackupは以下のようにインストールを行うことができます。
|
1 |
yum install https://downloads.percona.com/downloads/Percona-XtraBackup-LATEST/Percona-XtraBackup-8.0.30-23/binary/redhat/8/x86_64/percona-xtrabackup-80-8.0.30-23.1.el8.x86_64.rpm |
実行コマンドについて
以下のコマンドを実行し、それぞれの結果を比較しました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# backup no compress xtrabackup --backup --target-dir=/data/bk --parallel=16 # backup zstd level 1 xtrabackup --backup --target-dir=/data/bk --parallel=16 --compress-threads=16 --compress=zstd --compress-zstd-level=1 # backup zstd level 5 xtrabackup --backup --target-dir=/data/bk --parallel=16 --compress-threads=16 --compress=zstd --compress-zstd-level=5 # backup zstd level 10 xtrabackup --backup --target-dir=/data/bk --parallel=16 --compress-threads=16 --compress=zstd --compress-zstd-level=10 # backup zstd max level xtrabackup --backup --target-dir=/data/bk --parallel=16 --compress-threads=16 --compress=zstd --compress-zstd-level=19 # backup quicklz xtrabackup --backup --target-dir=/data/bk --parallel=16 --compress-threads=16 --compress=quicklz # backup lz4 xtrabackup --backup --target-dir=/data/bk --parallel=16 --compress-threads=16 --compress=lz4 # decompress xtrabackup --decompress --decompress-threads=16 --target-dir=/data/bk --remove-original |
--parallel(ファイルコピー時の並列スレッド数)、 --compress-threads(圧縮時の並列スレッド数)、--decompress-threads(解凍時の並列スレッド数) はCPUコア数と同数にしています。
補足として、解凍(--decompress)の際は、Percona Xtrabackupは拡張子から適切なメソッドを判断するロジックとなっているため、解凍コマンドはすべてケースで同一です。
ディスクスペースの都合上、解凍の際には--remove-originalオプションを付与して解凍後に圧縮ファイルを削除しています。
実行結果
バックアップサイズ
圧縮率
バックアップ実行時間
バックアップ解凍時間
これまでのquicklz/lz4でもバックアップのサイズをかなり減らす事ができますが、zstdのlevel 1でもquicklz/lz4と比較して約20%のサイズダウンを実現できることがわかりました。
バックアップの実行時間としても、それなりにCPUを使用できる環境であれば、非圧縮の実行時間と遜色ない速度が実現できることも確認できました。
一方で以下は、 mpstat -P ALL を zstd level 19の実行中に確認したものです。
すべてのコアでCPUビジーになっており、%iowaitはそれほど無い様子が確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
02:26:45 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 02:26:46 all 99.31 0.00 0.31 0.06 0.00 0.06 0.19 0.00 0.00 0.06 02:26:46 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 2 99.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 3 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 4 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 5 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 6 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 7 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 8 99.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 02:26:46 9 98.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 10 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 11 99.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 02:26:46 12 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 13 99.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 02:26:46 14 96.08 0.00 0.98 0.98 0.00 0.00 0.98 0.00 0.00 0.98 02:26:46 15 98.99 0.00 0.00 0.00 0.00 0.00 1.01 0.00 0.00 0.00 |
以下は、 mpstat -P ALL を zstd level 5の実行中に確認したものです。
CPUの仕事量がlevel 19に比較して少ないため、ディスク性能がボトルネックになっている様子が確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
08:45:39 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 08:45:40 all 51.18 0.00 3.18 24.03 0.00 0.56 0.87 0.00 0.00 20.17 08:45:40 0 56.44 0.00 2.97 24.75 0.00 0.99 0.00 0.00 0.00 14.85 08:45:40 1 46.00 0.00 5.00 21.00 0.00 1.00 0.00 0.00 0.00 27.00 08:45:40 2 80.61 0.00 2.04 8.16 0.00 0.00 0.00 0.00 0.00 9.18 08:45:40 3 14.56 0.00 9.71 60.19 0.00 2.91 3.88 0.00 0.00 8.74 08:45:40 4 51.96 0.00 5.88 22.55 0.00 0.00 1.96 0.00 0.00 17.65 08:45:40 5 36.73 0.00 2.04 41.84 0.00 0.00 1.02 0.00 0.00 18.37 08:45:40 6 44.55 0.00 5.94 34.65 0.00 0.00 1.98 0.00 0.00 12.87 08:45:40 7 55.00 0.00 2.00 31.00 0.00 0.00 0.00 0.00 0.00 12.00 08:45:40 8 68.32 0.00 0.99 8.91 0.00 0.00 0.00 0.00 0.00 21.78 08:45:40 9 42.00 0.00 3.00 19.00 0.00 2.00 2.00 0.00 0.00 32.00 08:45:40 10 48.04 0.00 0.98 28.43 0.00 0.00 1.96 0.00 0.00 20.59 08:45:40 11 51.00 0.00 2.00 15.00 0.00 0.00 0.00 0.00 0.00 32.00 08:45:40 12 70.00 0.00 1.00 8.00 0.00 0.00 0.00 0.00 0.00 21.00 08:45:40 13 39.00 0.00 4.00 35.00 0.00 1.00 1.00 0.00 0.00 20.00 08:45:40 14 55.45 0.00 0.99 4.95 0.00 0.00 0.00 0.00 0.00 38.61 08:45:40 15 60.61 0.00 2.02 20.20 0.00 1.01 0.00 0.00 0.00 16.16 |
これらの事から、I/Oが非常に高速でCPUビジーになる状況では、もっと顕著に非圧縮の実行時間よりもzstdの実行時間が増加することになるでしょう。
zstdの最大レベルの圧縮では、もとのバックアップサイズの1/5という素晴らしい結果になりましたが、「実行速度を犠牲にしてもバックアップのサイズを減らしたい」というようなケース以外では、levelを上げることについては慎重になったほうが実用性が高そうです。
バックアップの実行時間(圧縮時の実行時間)と比較して、解凍時の実行時間は zstdのlevelを増やしたとしても顕著な増加は無いというのは実用上嬉しいポイントです。
まとめ
バックアップのサイズが大きすぎて問題となっている運用者様は多いのでは無いでしょうか。
zstdを活用して、バックアップディスクの空きを増やす、これまでは保持できなくて諦めていた複数世代のバックアップを持つなど、ご検討頂けると幸いです。
