このページでは、バランシングに関連する一般的な管理手順について説明します。バランシングの概要については、「 シャーディングされたクラスターのバランサー」を参照してください。バランシングに関する下位レベルの情報については、「バランサーの内部」を参照してください。
バランサー プロセスは、mongos インスタンスから構成サーバー レプリカセットのプライマリ メンバーに移動されました。
バランサーの状態の確認
sh.getBalancerState() は、バランサーが有効かどうか(すなわち、バランサーの実行が許可されているかどうか)を確認します。sh.getBalancerState() は、バランサーがアクティブにデータを移行するかどうかを確認しません。
シャーディングされたクラスターでバランサーが有効になっているかどうかを確認するには、次のコマンドを実行します。このコマンドはブール値を返します。
sh.getBalancerState()
sh.status() を使用して、バランサーが有効かどうかも確認できます。currently-enabled フィールドはバランサーが有効かどうかを示し、currently-running フィールドはバランサーが現在実行中かどうかを示します。
バランサーが実行中であることを確認します
クラスターでバランサーのプロセスがアクティブかどうかを確認する方法は次のとおりです。
デフォルトの範囲サイズの構成
シャーディングされたクラスターのデフォルトの範囲サイズは 128 メガバイトです。ほとんどの場合、チャンクの分割と移行にはデフォルトのサイズが適切です。範囲サイズが配置に与える影響について、詳細は「範囲サイズ」を参照してください。
デフォルトの範囲サイズを変更すると、移行および自動分割中に処理される範囲に影響しますが、すべての範囲に遡及して影響するわけではありません。
デフォルトの範囲サイズを構成するには、「シャーディングされたクラスターの範囲サイズの変更」を参照してください。
バランシング ウィンドウのスケジュール
状況によっては、特にデータセットの増大が遅く、移行がパフォーマンスに影響する可能性がある場合、バランサーを特定の時間のみアクティブにしておくと便利です。 デフォルトでは、バランサー プロセスは常に有効になっており、チャンクを移行しています。 次の手順では、バランサーがチャンクを移行できる時間枠であるactiveWindowを指定します。
コンフィギュレーションデータベース に切り替えます。
次のコマンドを発行して、コンフィギュレーションデータベースに切り替えます。
use config
バランサーがstopped でないことを確認します。
stopped の状態ではバランサーはアクティブになりません。バランサーが stopped ではないことを確認するには、次のように sh.startBalancer() を使用します。
sh.startBalancer()
activeWindow の時間枠を外れるとバランサーは起動しません。
バランサーのウィンドウを変更します。
次のように、updateOne() を使用して activeWindow を設定します。
db.settings.updateOne( { _id: "balancer" }, { $set: { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } }, { upsert: true } )
<start-time> と <end-time> を置き換えた 2 桁の時間と分の値を使った時間の値(つまり HH:MM)は、バランシング ウィンドウの開始境界と終了境界を指定します。
HH値には、00~23の範囲の時間の値を使用します。MM値には、00~59の範囲の分の値を使用します。
オンプレミスまたは自己管理型のシャーディングされたクラスターの場合、MongoDB はコンフィギュレーションサーバーのレプリカセット内のプライマリ ノードのタイムゾーンを基準にして、開始時間と停止時間を評価します。
Atlas クラスターの場合、MongoDB は UTC タイムゾーンに対して開始時間と停止時間を相対的に評価します。
注意
バランサー ウィンドウは、その日に挿入されたすべてのデータの移行を完了するのに十分でなければなりません。
データ挿入率はアクティビティや使用パターンによって変わる可能性があるため、選択したバランシング ウィンドウが配置のニーズをサポートするのに十分であることを確認するのが重要です。
バランシング ウィンドウの確認
現在のバランシング ウィンドウを確認するには、次のコマンドを実行します。
use config db.settings.find( { _id: "balancer" } )
バランシング ウィンドウのスケジュールの削除
バランシング ウィンドウを設定しており、スケジュールを削除してバランサーが常に実行されるようにする場合は、次のように$unsetを使用してactiveWindowをクリアします。
use config db.settings.updateOne( { _id : "balancer" }, { $unset : { activeWindow : true } } )
バランサーを無効にする
重要
デフォルトでは、バランサーはいつでも実行でき、必要な場合にのみチャンクを移動します。バランサーを短期間無効にしてすべての移行を防ぐ場合は、次の手順に従います。
次の操作を発行して、バランサーを無効にします。
sh.stopBalancer() 移行が進行中の場合、システムは進行中の移行を完了してから停止します。
バランサーが起動しないことを確認するには、次のコマンドを実行します。このコマンドは、バランサーが無効になっている場合は
falseを返します。sh.getBalancerState() オプションとして、無効化後に移行が進行中でないことを確認するには、
mongoshshellで次の操作を実行します。use config while( sh.isBalancerRunning() ) { print("waiting..."); sleep(1000); }
注意
ドライバーからバランサーを無効にするには、次のように admin データベースに対して balancerStop コマンドを使用します。
db.adminCommand( { balancerStop: 1 } )
MongoDB7.0 以降では、バランサーを停止すると、 シャーディングされたクラスターの AutoMerger も無効になります。
バランサーを有効にする
バランサーを無効にし、再度有効にする準備ができたら、次の手順に従います。
次のいずれかの操作を発行して、バランサーを有効にします。
mongoshshell から次を発行します。sh.startBalancer() 注意
ドライバーからバランサーを有効にするには、次のように
adminデータベースに対して balancerStart コマンドを使用します。db.adminCommand( { balancerStart: 1 } )
MongoDB7.0 以降では、バランサーを起動すると、シャーディングされたクラスターの AutoMerger も有効になります。
バックアップ中のバランシングの無効化
注意
バランサーを無効にするのは、 を呼び出すか、特定の時間に呼び出すタスクをスケジュールして、バックアップをmongodump 手動でmongodump 取得する場合にのみ必要です。
協調したバックアップと復元のプロセスを使用する場合、バランサーを無効にする必要はありません。
MongoDB がバックアップ中にチャンクを移行すると、シャーディングされたクラスターのスナップショットが不整合になる可能性があります。バランサーがアクティブな間はバックアップを実行しないでください。バックアップ操作中にバランサーが非アクティブであることを確認する方法。
バランシング ウィンドウを設定して、バックアップ中にバランサーが非アクティブになるようにします。 バランサーを無効にした状態でバックアップが完了することを確認します。
バックアップ手順の実行中にバランサーを手動で無効にする。
バランサー ラウンドの最中にバランサーの電源を切ると、瞬時にはシャットダウンされません。バランサーは進行中のチャンクの移動を完了し、それ以降のバランサー ラウンドをすべて中止します。
バックアップ操作を開始する前に、バランサーがアクティブでないことを確認してください。次のコマンドを使用して、バランサーがアクティブかどうかを確認できます。
!sh.getBalancerState() && !sh.isBalancerRunning()
バックアップ手順が完了したら、バランサー プロセスを再度有効化できます。
コレクションでのバランシングの無効化
sh.disableBalancing() メソッドを使用して、特定のコレクションのバランシングを無効にできます。データの取り込みやデータのエクスポートなどの最中に、メンテナンス操作や非定型のワークロードをサポートするために、特定のコレクションのバランサーを無効にしたい場合があります。
コレクションのバランシングを無効にすると、MongoDB は進行中の移行を中断しません。
コレクションのバランシングを無効にするには mongosh shellを使用して mongos に接続し、sh.disableBalancing() メソッドを呼び出します。
以下に例を挙げます。
sh.disableBalancing("students.grades")
sh.disableBalancing() メソッドは、コレクションの完全な名前空間をパラメータとして受け入れます。
コレクションでのバランシングの有効化
sh.enableBalancing() メソッドを使用して、特定のコレクションのバランシングを有効にできます。
コレクションのバランシングを有効にしても、MongoDB はデータのバランシングをすぐには開始しません。しかし、シャーディングされたコレクションのデータがバランシングされていない場合、MongoDB はデータのより均等な分散を始めることができます。
コレクションのバランシングを有効にするには、 shellmongos mongoshsh.enableBalancing()を使用して に接続し、 メソッドを呼び出します。
以下に例を挙げます。
sh.enableBalancing("students.grades")
sh.enableBalancing() メソッドは、コレクションの完全な名前空間をパラメータとして受け入れます。
バランシングが有効か無効かの確認
コレクションのバランシングが有効か無効かを確認するには、コレクション名前空間の config データベース内の collections コレクションをクエリし、noBalance フィールドを確認します。以下に例を挙げます。
db.getSiblingDB("config").collections.findOne({_id : "students.grades"}).noBalance;
この操作は null エラー、true、false を返すか、出力なしになります。
null エラーは、コレクションの名前空間が正しくないことを示します。
結果が
trueの場合、バランシングは無効になります。結果が
falseの場合、コレクションのバランシングは現在は有効ですが、過去には無効になっていました。このコレクションのバランシングは、バランサーが次に実行するときに開始します。操作で出力が返されない場合は、バランシングは現在有効で、このコレクションで過去に無効になったことはありません。このコレクションのバランシングは、バランサーが次に実行するときに開始します。
sh.status() を使用して、バランサーが有効かどうかも確認できます。currently-enabled フィールドは、バランサーが有効かどうかを示します。
チャンク移行のレプリケーション動作の変更
セカンダリ スロットル
チャンクの移行中、チャンク内の次のドキュメントへの移行が進むタイミングを _secondaryThrottle 値が決めます。
config.settings コレクション内:
バランサーの
_secondaryThrottle設定が 書込み保証 ( write concern ) に設定されている場合、チャンクの移行中に移動された各ドキュメントは、次のドキュメントに進む前に要求された確認応答を受ける必要があります。移行プロセスでは、
_secondaryThrottleが未設定の場合、セカンダリへのレプリケーションを待たずに次のドキュメントに進みます。これは WiredTiger のデフォルトの動作です。
_secondaryThrottle 設定を変更するには、mongos インスタンスに接続し、構成データベースの settings コレクション内の _secondaryThrottle 値を直接更新します。たとえば、mongos に接続されたmongosh shell から、次のコマンドを実行します。
use config db.settings.updateOne( { "_id" : "balancer" }, { $set : { "_secondaryThrottle" : { "w": "majority" } } }, { upsert : true } )
_secondaryThrottle 設定を変更しても、その効果はすぐには現れない場合があります。すぐに効果を得るには、バランサーを停止して再起動し、選択した値 _secondaryThrottle を有効にします。
チャンク移行のさまざまなステップにおけるレプリケーション動作の詳細については、「範囲の移行とレプリケーション」を参照してください。
削除を待つ
バランサーの _waitForDelete 設定と moveChunk コマンドは、バランサーがシャードから複数のチャンクを移行する方法に影響します。同様に、バランサーの _waitForDelete 設定と moveRange コマンドも、バランサーがシャードから複数のチャンクを移行する方法に影響します。デフォルトでは、バランサーは進行中の移行の削除フェーズが完了するのを待たずに次のチャンク移行を開始します。削除フェーズで次のチャンク移行の開始をブロックするには、_waitForDelete を true に設定します。
チャンク移行の詳細については、「範囲の移行」を参照してください。チャンク移行キューイングの動作の詳細については、「非同期範囲移行のクリーンアップ」を参照してください。
重要
_waitForDeleteフィールドが設定されている場合、 MongoDB は範囲削除を実行する前に orphanCleanupDelaySecs 遅延を待たなくなります。_waitForDelete パラメーターを使用しており、セカンダリで読み取り操作が発生している場合、移行の削除フェーズによって読み取りが終了する可能性があります。詳しくは、terminateSecondaryReadsOnOrphanCleanup を参照してください。
バランサーの _waitForDelete 値を変更する方法。
mongosインスタンスに接続します。コンフィギュレーションデータベース の
settingsコレクション内にある_waitForDelete値をアップデートします。以下に例を挙げます。use config db.settings.updateOne( { "_id" : "balancer" }, { $set : { "_waitForDelete" : true } }, { upsert : true } )
true に設定すると、デフォルトの動作に戻ります。
mongosインスタンスに接続します。コンフィギュレーションデータベースの
settingsコレクション内にある_waitForDeleteフィールドをアップデートまたは設定解除します。use config db.settings.updateOne( { "_id" : "balancer", "_waitForDelete": true }, { $unset : { "_waitForDelete" : "" } } )
サイズ制限を超える残余範囲
デフォルトでは、範囲内のドキュメント数が、構成された範囲サイズを平均ドキュメント サイズで割った結果の 2 倍を超える場合、MongoDB は範囲を移動できません。
バランサー設定attemptToBalanceJumboChunksをtrueに指定することで、バランサーはjumbo というラベルが付いていない限り、これらの大きな範囲を移行できます。
バランサーの attemptToBalanceJumboChunks 設定を行うには、mongos インスタンスに接続し、config.settings コレクションを直接更新します。たとえば、mongos インスタンスに接続された mongosh shellから、次のコマンドを実行します。
db.getSiblingDB("config").settings.updateOne( { _id: "balancer" }, { $set: { attemptToBalanceJumboChunks : true } }, { upsert: true } )
移動したい範囲に jumbo というラベルがある場合は、ジャンボ フラグを手動でクリアしてバランサーに範囲の移行を試行させることができます。
次のいずれかを使用して、サイズ制限を超える範囲(jumbo ラベルの有無にかかわらず)を手動で移行することもできます。
forceJumbo: true オプションを指定した
moveRangeコマンドforceJumbo: true オプションを指定した
moveChunkコマンド
ただし、forceJumbo: true とともに moveRange または moveChunk を実行すると、コレクションへの書込み (write) 操作が移行中に長時間ブロックされる可能性があります。