MySQL Shell の dumpInstance() 帯域制限オプション活用法

この記事は最終更新から2年以上経過しています。内容が古くなっている可能性があります。

はじめに

MySQL Shell 8.0.21MySQLインスタンスのダンプ機能 が実装されてから1年以上が経過しました。こちらは従来の mysqldump と違って、処理の並列化(効率UP)や細かな制御が可能ということもあり、弊社でも徐々に実際の業務で使用するケースが増えています。

また、過去に本技術ブログでも何度か取り上げています。

MySQL Shell で バックアップとリストアをパラレルで実行する
MySQL Shell の dumpInstance() を使ってMySQL5.6をバージョンアップする

そんな MySQL Shell のdump機能ですが、今回はこれまで取り上げてこなかった帯域制限オプションについて紹介したいと思います。

帯域制御オプションとは

MySQLインスタンスを丸ごとダンプ(バックアップ)をする場合、取得したダンプファイルは他のサーバに転送して保管するケースも多いかと思います。また、ダンプファイルを別のサーバに転送・リストアすることで、新規にMySQLを構築するケースもあるでしょう。

この時、専用のNWセグメントが存在するのであれば問題ないのですが、セグメントが1つしかなかったり、他のサービスと共有していたりすると、ダンプの転送時の負荷が問題になってしまう可能性があります。特にデータサイズが大きければ大きいほど、帯域の使用量は多くなりますし、転送時間も長期化してしまいます。

そこで役に立つのが、今回紹介する帯域制御オプションです。

MySQL Shell のdump機能(本稿では主に dumpInstance() を想定)には、様々なオプションが存在します。その中で、ダンプ処理中の帯域を制御するためのオプションは以下の2つです。

オプション名 デフォルト 説明
maxRate 0 (= 上限なし) dumpを実行する1スレッド当たりの最大使用帯域。100M を設定した場合、1スレッド当たりの上限が 100MB / s になる。
threads 4 dumpを実行する並列スレッド数。スレッド数を増やすと実行時間が短くなる可能性があるが、MaxRate による合計の帯域上限も引き上がる。

それでは、実際にこのオプションを使って、dumpInstance() の帯域制限を検証してみましょう。

テスト環境

今回は OCI の Compute を使って、以下のテスト用インスタンスを2台(Aサーバ、Bサーバ)用意しました。サーバスペックは両方とも同じです。

  • Aサーバ … MySQLサーバ(MySQL 8.0.27)
  • Bサーバ … MySQL Shell の dumpInstance() をAサーバに対して実行するサーバ
Shape Name VM.Standard.E4.Flex
CPU 8 コア
MEMORY 64 GB
Disk 500 GB (※)
NW 8 Gbps network bandwidth
OS CentOS 8.4

マニュアルによれば、このボリュームサイズの場合は、最大スループットが「240 MB/s OR 200 MB/s」になり、最大IOPSは「25,000」になります

※ OCI の CentOS8 インスタンスではルートボリューム(/)の初期状態は LVM で割り当てられた30GBしかありません。そのため、インスタンス起動後に PV / LV / Filesystem を拡張する必要があります。

サーバインスタンスが立ち上がったら、以下の手順で環境を構築しています。

【Aサーバ】

【Bサーバ】

テストデータのロード

今回は、tpcc-mysql を使って、テストデータを用意します。以下のコマンドはAサーバで実施します。

[NOTE]
今回はサイズがバラバラのデータベースを用意するために、-w オプションをデータベースごとに調整しています。詳しい仕様については、過去のブログ記事を参照してください。

また、MySQL Shell用のユーザも用意しておきます。

帯域制限オプションの検証

目次

(1) デフォルト設定

テスト環境が用意できたので、帯域制限オプションの検証をしていきましょう。

まずは、デフォルトの設定で dumpInstance() を実行してみます。なお、これ以降はBサーバで作業を行います。

※ SELinux、iptables(firewalld) は無効にしてあります

ダンプ取得中に dstat コマンドでネットワーク負荷を確認すると、以下のように合計 150M~200MB/s 程度が使われていました。

OCIコンソールでBサーバのメトリクスを見ると、以下のような負荷状況でした。

(2) 帯域制限 10MB/s & 4threads

それでは、MaxRateオプションを付けて dumpInstance() を実行してみましょう。まずは、1スレッドあたり 10MB/s にしてみます。スレッド数は変わらずデフォルトの4スレッドです。

ダンプ取得中の dstat のログおよびメトリクスを見ると、MaxRate 未指定(=制限なし)の時と比べると、明確に負荷が下がっていることが分かります。その代わり、ダンプの実行時間は長くなります。

(3) 帯域制限 10MB/s & 8threads

次に、上のパターンからスレッド数を 4 から 8 に増やして実行してみます。

実行時間は短くなりますが、MaxRateはスレッド当たりの帯域を制限するオプションのため、トータルのネットワーク負荷は増大しました。

(4) 帯域制限 20MB/s & 2threads

次に MaxRate:20MB かつ threads:2 のパターンを計測してみます。これは 20MB * 2 = 40MB なので、(2) の 10MB * 4 の時と同じ制限量になります。

結果としては、(2) のパターンよりも実行時間は伸び、スループットの値も低くなりました。

(5) 帯域制限 5MB/s & 8threads

最後に MaxRate:5MB かつ threads:8 のパターンを計測してみます。これも 5MB * 8 = 40MB なので、(2) の 10MB * 4 の時と同じ制限量になります。

こちらは、(2) / (4)のパターンよりも若干結果が良くなりました。今回のケースでは、「帯域を広く使って、少ないスレッド数でダンプ」よりも「帯域は狭くても、多くのスレッド数でダンプ」を行う方が効率が良くなるようです。

検証結果

No MaxRate: Threads: 実行時間 スループット(非圧縮) スループット(圧縮)
1 0 (no limit) 4 00:21:18s 159.75 MB/s 94.58 MB/s
2 10M 4 00:58:12s 58.47 MB/s 34.61 MB/s
3 10M 8 00:29:29s 115.41 MB/s 68.33 MB/s
4 20M 2 01:07:00s 50.79 MB/s 30.07 MB/s
5 5M 8 00:55:13s 61.63 MB/s 36.49 MB/s

上記の結果から以下のことが分かります。

  • 帯域制限オプションを使用しない場合、最も早くdumpInstance()は完了するが、ネットワーク負荷は高くなる
  • MaxRateオプションを設定するとネットワーク負荷は軽減されるが、dumpInstance()の実行時間は長くなる
  • MaxRateオプションを設定した状態でも、Threads オプションを引き上げることで実行時間は短くできる(ネットワーク負荷は増大)
  • MaxRate * Threads の合計値が同じになる設定値の組み合わせであっても、実行時間やスループットに差異は発生する
  • MaxRate * Threads の値を実際のスループットの値が超えているケースもあることから、MaxRate:による制限を超えてダンプ処理が行われる可能性もある

ただし、上記は今回のテスト環境、テストデータで実施した結果なので、サーバスペックやデータの内容・サイズが変われば結果や傾向が変わる可能性がある点にはご留意ください。

まとめ

MySQL Shell のダンプ機能は非常に便利ですが、デフォルトの設定ではネットワーク帯域を無制限に使用する仕様になっています。もし、ネットワーク負荷を気にされる方がいれば、MaxRate / Threads オプションを活用してみてください。

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃MySQLのサポート業務に従事している有資格者で構成された技術サポートチームがMySQLに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次