前のパートでは、さまざまなバックアップ圧縮レベルと方法について、バックアップ時間と圧縮の有効性をテストしました。このブログでは、引き続き取り組みを進め、おそらくほとんどのユーザーが実際には変更しないが、バックアッププロセスに目に見える影響を与える可能性のある設定について説明します。
セットアップは前の部分と同じです。ProxySQLとKeepalivedでMariaDBマスタースレーブレプリケーションクラスターを使用します。
sysbenchを使用して7.6GBのデータを生成しました：
sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.111 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=6033 --tables=32 --table-size=1000000 preparePIGZの使用
今回は、バックアップの並列gzipにPIGZを使用を有効にします。以前と同様に、すべての圧縮レベルをテストして、そのパフォーマンスを確認します。
バックアップをインスタンスにローカルに保存しています。インスタンスは、次のように構成されています。 4つのvCPU。
結果は予想通りです。バックアッププロセスは、単一のCPUコアのみを使用した場合よりも大幅に高速でした。バックアップのサイズはほとんど同じであり、大幅に変更する本当の理由はありません。 pigzを使用するとバックアップ時間が改善されることは明らかです。ただし、並列gzipを使用することには欠点があり、それはCPU使用率です：
ご覧のとおり、CPU使用率は急上昇し、ほぼ100％に達します。より高い圧縮レベルの場合。通常、データベースでCPUを使用できるようにする必要があるため、データベースサーバーでCPU使用率を上げることが必ずしも最善のアイデアとは限りません。一方、バックアップの作成専用のレプリカがあり、たとえば、より重いクエリ（OLTPタイプのトラフィックの処理に使用されないノード）がある場合は、並列gzipを有効にしてバックアップを大幅に削減できます。時間。はっきりとわかるように、これはすべての人にとっての選択肢ではありませんが、特定のシナリオで役立つことは間違いありません。 CPU使用率は、クエリのレイテンシに影響を与え、ユーザーエクスペリエンスにも影響を与えるため、追跡する必要があることを覚えておいてください。これは、データベースを操作するときに常に考慮する必要があります。
強調したいもう1つの設定は、Xtrabackup ParallelCopyThreadsです。それが何であるかを理解するために、Xtrabackup（またはMariaBackup）がどのように機能するかについて少し話しましょう。つまり、これらのツールは2つのアクションを同時に実行します。 InnoDB REDOログで更新を監視しながら、データ、物理ファイルをデータベースサーバーからバックアップ場所にコピーします。バックアップは、バックアッププロセス中に発生したInnoDBへのすべての変更のファイルと記録で構成されます。これにより、バックアップロックまたは読み取りロック付きのフラッシュテーブルを使用して、データ転送が終了した時点で一貫性のあるバックアップを作成できます。 Xtrabackup Parallel Copy Threadsは、データ転送を実行するスレッドの数を定義します。 1に設定すると、1つのファイルが同時にコピーされます。 8に設定すると、理論的には一度に最大8つのファイルを転送できます。もちろん、そのような設定から実際に恩恵を受けるには、十分に高速なストレージが必要です。 Xtrabackup Parallel Copy Threadsを1から2および4から8に変更して、いくつかのテストを実行します。並列gzipを有効にした場合と無効にした場合で、圧縮レベル6（デフォルトは1）でテストを実行します。
最初の4つのバックアップ（27〜30）は、並列gzipなしで作成されています。 1から2、4、および8の並列コピースレッドから開始します。次に、バックアップ31から34に対して同じプロセスを繰り返しましたが、今回は並列gzipを使用しました。ご覧のとおり、この場合、並列コピースレッド間にほとんど違いはありません。データセットのサイズを大きくすると、これはおそらくより影響力があります。また、より高速で信頼性の高いストレージを使用すると、バックアップのパフォーマンスが向上します。いつものように、マイレージはさまざまであり、環境によっては、この設定がここに表示されているものよりもバックアッププロセスに影響を与える可能性があります。
最後に、短いシリーズのこのパートでは、ネットワークの使用を抑制する機能について説明します。
ご覧のとおり、バックアップはノードまたはコントローラホストにストリーミングすることもできます。これはネットワーク経由で発生し、デフォルトでは「可能な限り高速」に実行されます。
ネットワークスループットが制限されている場合（クラウドインスタンスなど）、ネットワーク転送に制限を設定することで、MariaBackupによって引き起こされるネットワーク使用量を減らしたい場合があります。これを行うと、ClusterControlは「pv」ツールを使用してプロセスで使用可能な帯域幅を制限します。
ご覧のとおり、最初のバックアップには約3分かかりましたが、ネットワークスループットを抑制し、バックアップには13分37秒かかりました。
どちらの場合も、pigzと圧縮レベル1を使用しました。上のグラフは、ネットワークのスロットリングによってCPU使用率も低下したことを示しています。ネットワークがデータを転送するのをpigzが待機する必要がある場合、ほとんどの場合アイドル状態である必要があるため、CPUを強く押す必要はありません。
この短いブログがおもしろいと思ったことを願っています。おそらく、MariaBackupのあまり一般的に使用されていない機能やオプションのいくつかを試してみることをお勧めします。あなたの経験の一部を共有したい場合は、以下のコメントであなたから聞いてみたいです。