シャーディングされたクラスター バランサー
MongoDB バランサーは、各 シャード 上の チャンク の数を監視するバックグラウンド プロセスです。任意のシャード上のチャンク数が特定の移行しきい値に達すると、バランサーはシャード間でチャンクを自動的に移行し、シャードあたりのチャンク数が等しくなるようにします。
シャーディングされたクラスターのバランシング手順は、ユーザー層とアプリケーション層には完全に透過的ですが、処理中にパフォーマンスにいくらか影響が出る可能性があります。
バランサーは、コンフィギュレーションサーバー レプリカセット（CSRS）のプライマリ上で実行されます。
クラスター バランサー
バランサープロセスは、シャーディングされたコレクションのチャンクを、シャーディングされたコレクションごとのシャード間で均等に再分配します。 デフォルトでは、バランサー プロセスは常に有効になっています。
シャーディングされたコレクションの 不均一な チャンク分散に対処するために、バランサーは チャンク を、チャンクの数が多いシャードから、チャンク数の少ないシャードに移行します。 バランサーは、コレクションの チャンク がシャード全体に均等に分散されるまで、チャンクを移行します。 チャンク移行の詳細については、「チャンク移行手順 」を参照してください。
チャンクの移行はディスク容量に影響を与える可能性があり、ソースシャードは移行されたドキュメントをデフォルトで自動的にアーカイブします。 詳細については、 moveChunkディレクトリを参照してください。
チャンクの移行には、帯域幅とワークロードの面でいくらかのオーバーヘッドが伴い、どちらもデータベースのパフォーマンスに影響を与える可能性があります。 [ 1 ]バランサーは次の方法で影響を最小限に抑えようとします。
シャードを一度に最大で 1 つの移行に制限する。つまり、シャードは同時に複数のチャンク移行に参加することはできません。 シャードから複数のチャンクを移行するために、バランサーは一度に 1 つずつチャンクを移行します。
バージョン3.4での変更: MongoDB 3.4以降、 MongoDB can perform parallel chunk migrations. シャードが一度に参加できる移行は最大 1 つだけであるという制限がある限り、 n 個のシャードを持つシャーディングされたクラスターの場合、MongoDB は最大n/ 2 （切り捨て）の同時チャンク移行を実行できます。
バランシング ラウンドは、シャーディングされたコレクションのチャンク数が最も多いシャードと、そのコレクションのチャンク数が最も少ないシャードとの間のチャンク数の差が 移行しきい値 に達した場合に のみ 開始されます。
メンテナンスのために一時的にバランサーを無効にすることはできますが、バランサーを長期間無効のままにするとクラスターのパフォーマンスが低下する可能性があります。 詳細については、「 バランサーを無効にする 」を参照してください。
また、バランサーの実行時間を制限して、本番環境のトラフィックに影響を与えないようにすることもできます。詳細については、「バランシング ウィンドウのスケジュール」を参照してください。
注意
バランシング ウィンドウの仕様は、コンフィギュレーションサーバー レプリカセットのプライマリのローカル タイム ゾーンを基準にしています。
| [1] | コレクションにゾーンとゾーン範囲が定義されている場合、シャード コレクション操作では、空のコレクションまたは存在しないコレクションに対して、初期チャンクの作成と分散を実行できます。 チャンクの最初の作成と分散により、ゾーン シャーディングの設定を迅速に行うことができます。 初期分散後、バランサーは通常どおりに今後のチャンク分散を管理します。MongoDB は複合ハッシュインデックスでのコレクションのシャーディングをサポートしています。 複合ハッシュされたシャードキーを使用して、空のコレクションまたは存在しないコレクションをシャーディングする場合、MongoDB が初期チャンクの作成と分散を実行するために追加の要件が適用されます。例については、「 空または存在しないコレクションのゾーンとゾーン範囲の事前定義 」を参照してください。 |
クラスターからのシャードの追加と削除
クラスターにシャードを追加すると、新しいシャードにはチャンクがないため、不均衡が生じます。 MongoDB は新しいシャードへのデータの移行をすぐに開始しますが、クラスターのバランスがとれるまでに時間がかかる場合があります。 クラスターにシャードを追加する手順については、「 クラスターへのシャードの追加 」のチュートリアルを参照してください。
クラスターからシャードを削除すると、そのシャードに存在するチャンクはクラスター全体に再分散する必要があるため、同様の不均衡が生じます。 MongoDBは削除されたシャードをすぐにドレインし始めますが、クラスターのバランスがとれるまでに時間がかかる場合があります。 このプロセス中は、削除されたシャードに関連付けられているサーバーをシャットダウンしないでください。
チャンクの分布が不均一なクラスター内のシャードを削除すると、バランサーはまずドレイン シャードからチャンクを削除し、次に残りの不均一なチャンクの分布のバランスをとります。
クラスターからシャードを安全に削除する方法については、「 既存のシャーディングされたクラスターからのシャードの削除」チュートリアルを参照してください。
チャンク移行手順
すべてのチャンク移行では、次の手順を使用します。
バランサーは
moveChunkコマンドをソース シャードに送信します。ソースは内部
moveChunkコマンドで移動を開始します。 移行プロセス中、チャンクに対する操作はソース シャードにルーティングされます。 ソース シャードは、チャンクの受信書込み (write) 操作に責任を負います。宛先のシャードは、ソースに必要なインデックスのうち、宛先に存在しないインデックスを構築します。
宛先シャードは、チャンク内のドキュメントのリクエストを開始し、データのコピーの受信を開始します。 「チャンクの移行とレプリケーション 」も参照してください。
ターゲット シャードは、チャンク内の最終ドキュメントを受け取った後、同期プロセスを開始して、移行中に発生した移行済みドキュメントへの変更が確実に反映されるようにします。
完全に同期されると、ソースシャードは コンフィギュレーションデータベースに接続し、チャンクの新しいロケーションでクラスター メタデータを更新します。
ソース シャードがメタデータの更新を完了し、チャンク内で開いているカーソルがなくなると、ソース シャードはドキュメントのコピーを削除します。
注意
バランサーがソース シャードから追加のチャンク移行を実行する必要がある場合、バランサーは現在の移行プロセスがこの削除ステップを完了するのを待たずに、次のチャンク移行を開始することがあります。 「非同期チャンク移行クリーンアップ 」を参照してください。
移行プロセスにより、整合性が確保され、バランシング中にチャンクの可用性が最大化されます。
移行しきい値
クラスターへのバランシングの影響を最小限に抑えるため、バランサーは、シャーディングされたコレクションのデータ分布が、クラスターのバランスが取れていない移行しきい値に達した後にのみ、バランシングを開始します。 最もロードされたシャードのチャンク数が、シャードあたりの最適なチャンク数を1チャンク以上超えると、コレクションのバランスは解除され、バランサーはチャンクの移行を開始します。 シャードあたりの最適なチャンク数とは、シャーディングされたコレクション内のチャンクの合計数をシャードの数で割った値を、最も近い整数に切り上げた値です。 ゾーンが存在する場合、MongoDB はゾーンごとに最適なチャンク数を計算します。
たとえば、ユーザーがそれぞれ20チャンクを持つ10シャードのコレクションに新しいシャードを追加した場合、バランサーはデータを移行しません。 各シャードに最適なチャンク数は、 200を11で割った値、または18.18であり、MongoDB はこれを19に切り上げます。 19と20の差は1であるため、クラスターはバランス調整され、バランサーはチャンクを新しいシャードに移行しません。
非同期チャンク移行クリーンアップ
シャードから複数のチャンクを移行するために、バランサーは一度に 1 つずつチャンクを移行します。 ただし、バランサーは現在の移行の削除フェーズが完了するのを待たずに、次のチャンクの移行を開始します。 チャンク移行プロセスと削除フェーズについては、「 チャンクの移行を参照してください。
このキューイング動作により、事前分割せずに初期データロードを実行したり、新しいシャードを追加したりする場合など、クラスターのバランスが大幅に崩れている場合に、シャードはより迅速にチャンクをアンロードできます。
この動作は moveChunk コマンドにも影響し、moveChunk コマンドを使用する移行スクリプトはより迅速に進行する可能性があります。
場合によっては、削除フェーズがさらに長く続くことがあります。 MongoDB 4.4以降では、削除フェーズ中にフェイルオーバーが発生した場合の回復力が高まるように、チャンクの移行が強化されます。 このフェーズ中にレプリカセットのプライマリがクラッシュしたり再起動したりしても、孤立したドキュメントはクリーンアップされます。
バランサーの設定として使用可能な_waitForDelete 、およびmoveChunkコマンドは、現在の移行の削除フェーズが、次のチャンク移行の開始をブロックする可能性があります。 この_waitForDeleteは、通常、内部テスト用です。 詳細については、「削除の待機 」を参照してください。
チャンクの移行とレプリケーション
バージョン 3.4 で変更。
チャンクの移行中、チャンク内の次のドキュメントへの移行が進むタイミングを _secondaryThrottle 値が決めます。
config.settings コレクション内:
バランサーの
_secondaryThrottle設定が書込み保証 (write concern)に設定されている場合、範囲の移行中に移動された各ドキュメントは、次のドキュメントに進む前に要求された確認応答を受ける必要があります。移行プロセスでは、
_secondaryThrottleが未設定の場合、セカンダリへのレプリケーションを待たずに次のドキュメントに進みます。
バランサーの _secondaryThrottle パラメーターを更新するには、「セカンダリ スロットル」を例として参照してください。
_secondaryThrottleの設定とは別に、チャンク移行の特定のフェーズには次のレプリケーションポリシーが適用されます。
MongoDB は、チャンクの新しい場所でコンフィギュレーションサーバーを更新する前に、ソース シャードで移行されているコレクションへのすべてのアプリケーションの読み取りと書き込みを一時的に一時停止し、更新後にアプリケーションの読み取りと書込みを再開します。 チャンクの移動では、コンフィギュレーションサーバーにチャンクの移動をコミットする前後で、レプリカ セットのメンバーの過半数がすべての書き込みを確認する必要があります。
外向きの チャンクの移行が終了してクリーンアップが行われたら、（他の外向きの移行による）クリーンアップまたは新しい内向きの移行を続行する前に、すべての書き込みを大多数のサーバーに複製する必要があります。
config.settings コレクションの _secondaryThrottle 設定を更新する際の例については、「セカンダリ スロットル」をご覧ください。
移行するチャンクあたりのドキュメントの最大数
デフォルトでは、チャンク内のドキュメント数が、構成されたチャンク サイズを平均ドキュメント サイズで割った結果の1.3倍を超える場合、MongoDB はチャンクを移動できません。 db.collection.stats()には、コレクション内の平均ドキュメント サイズを表すavgObjSizeフィールドが含まれます。
移行するには大きすぎるチャンクの場合（MongoDB 4.4以降）
新しいバランサー設定を
attemptToBalanceJumboChunksに設定すると、チャンクにjumboというラベルが付いていない限り、バランサーが大きすぎて移動できないチャンクを移行できます。 詳細については 、「サイズ制限を超えるバランス チャンク」を参照してください。moveChunkコマンドで新しいオプションforceJumboを指定すると、移動できないほど大きいチャンクの移行が可能になります。 そのチャンクにはジャンボ というラベルが付いている場合と付いていない場合があります。
範囲削除によるパフォーマンスへの影響の調整
rangeDeleterBatchSizeとrangeDeleterBatchDelayMSパラメーターを使用して、範囲削除によるパフォーマンスへの影響を調整できます。 例:
バッチごとに削除されるドキュメントの数を制限するには、
rangeDeleterBatchSizeを32などの小さな値に設定します。バッチ削除の合間の時間を延ばすには、現在のデフォルト設定である
20ミリ秒より大きな値をrangeDeleterBatchDelayMSに設定します。
注意
削除対象のコレクションで読み取り操作が進行中であったり、カーソルが開いていると、範囲削除プロセスが続行されないことがあります。
シャードサイズ
MongoDB は、デフォルト設定により、データセットが大きくなるにつれて、利用可能なディスク スペースすべてをシャードのデータで埋めようとします。データの増加に対応できる容量をクラスターで常に確保するには、ディスク使用量やその他のパフォーマンス メトリクスをモニターしてください。
シャードの最大サイズを設定する方法については、「任意のシャードの最大ストレージ サイズを変更する」をご覧ください。