- 削除前にクラスターへ容量が追加されるため、break-first アプローチとは異なり、クラスター全体の容量は低下しません。もちろん、ノード障害やディスク障害などの予期しない事象は、クラウド環境では引き続き発生し得ます。
- このアプローチは、クラスターに高い負荷がかかっている状況で特に有効です。break-first アプローチで起こり得るような、既存のレプリカへの過負荷を防げるためです。
- 先にレプリカを削除するのを待たずに新しいレプリカをすばやく追加できるため、このアプローチではより高速で応答性の高いスケーリングを実現できます。
- MBB 操作では、現在のレプリカ上で実行中の既存のワークロードが完了するのを待ってから、そのレプリカを終了します。 この待機期間は現在 1 時間に設定されています。つまり、スケーリングやアップグレードの際には、レプリカを削除する前に、そのレプリカ上で長時間実行されているクエリの完了を最大 1 時間待つ場合があります。 また、レプリカ上でバックアップ処理が実行中の場合は、その処理が完了してからレプリカを終了します。
- レプリカが終了されるまでに待機時間があるため、クラスターのレプリカ数が、設定されている最大レプリカ数を一時的に上回ることがあります。 たとえば、合計 6 個のレプリカを持つサービスで MBB 操作が進行中の場合、追加で 3 個のレプリカがクラスターに加わり、古いレプリカが引き続きクエリを処理している間は、合計 9 個のレプリカになる可能性があります。 つまり、一定期間は、クラスターのレプリカ数が想定される数を上回ることになります。 さらに、複数の MBB 操作が重なることで、レプリカが蓄積される場合もあります。これは、たとえば API 経由でクラスターに複数の垂直スケーリング要求が送信された場合に発生し得ます。 ClickHouse Cloud には、クラスターに蓄積されるレプリカ数を制限するためのチェック機構があります。
- MBB 操作では、system table のデータが 30 日間保持されます。つまり、クラスターで MBB 操作が発生するたびに、30 日分の system table データが古いレプリカから新しいレプリカへ複製されます。