シャーディングされたクラスター バランサーの管理
項目一覧
バージョン 6.1 での変更。
このページでは、バランシングに関連する一般的な管理手順について説明します。バランシングの概要については、「 シャーディングされたクラスターのバランサー」を参照してください。バランシングに関する下位レベルの情報については、「バランサーの内部」を参照してください。
バランサー プロセスは、mongos
インスタンスから構成サーバー レプリカセットのプライマリ メンバーに移動されました。
バランサーの状態の確認
sh.getBalancerState()
は、バランサーが有効かどうか(すなわち、バランサーの実行が許可されているかどうか)を確認します。sh.getBalancerState()
は、バランサーがアクティブにデータを移行するかどうかを確認しません。
シャーディングされたクラスターでバランサーが有効になっているかどうかを確認するには、次のコマンドを実行します。このコマンドはブール値を返します。
sh.getBalancerState()
sh.status()
を使用して、バランサーが有効かどうかも確認できます。currently-enabled
フィールドはバランサーが有効かどうかを示し、currently-running
フィールドはバランサーが現在実行中かどうかを示します。
バランサーが実行中であることを確認します
クラスターでバランサーのプロセスがアクティブかどうかを確認する方法は次のとおりです。
デフォルトの範囲サイズの構成
シャーディングされたクラスターのデフォルトの範囲サイズは 128 メガバイトです。ほとんどの場合、チャンクの分割と移行にはデフォルトのサイズが適切です。範囲サイズが配置に与える影響について、詳細は「範囲サイズ」を参照してください。
デフォルトの範囲サイズを変更すると、移行および自動分割中に処理される範囲に影響しますが、すべての範囲に遡及して影響するわけではありません。
MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。
デフォルトの範囲サイズを構成するには、「シャーディングされたクラスターの範囲サイズの変更」を参照してください。
バランシング ウィンドウのスケジュール
状況によっては、特にデータセットの増大が遅く、移行がパフォーマンスに影響する可能性がある場合、バランサーを特定の時間のみアクティブにしておくと便利です。 デフォルトでは、バランサー プロセスは常に有効になっており、チャンクを移行しています。 次の手順では、バランサーがチャンクを移行できる時間枠であるactiveWindow
を指定します。
コンフィギュレーションデータベース に切り替えます。
次のコマンドを発行して、コンフィギュレーションデータベースに切り替えます。
use config
バランサーがstopped
でないことを確認します。
stopped
の状態ではバランサーはアクティブになりません。バランサーが stopped
ではないことを確認するには、次のように sh.startBalancer()
を使用します。
sh.startBalancer()
activeWindow
の時間枠を外れるとバランサーは起動しません。
MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。
MongoDB バージョン 6.0.3 より前では、sh.startBalancer()
によってシャーディングされたクラスターの自動分割も有効になります。
バランサーのウィンドウを変更します。
次のように、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() 移行が進行中の場合、システムは進行中の移行を完了してから停止します。
MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。
MongoDB バージョン 6.0.3 より前では、
sh.stopBalancer()
によってシャーディングされたクラスターの自動分割も無効になります。バランサーが起動しないことを確認するには、次のコマンドを実行します。このコマンドは、バランサーが無効になっている場合は
false
を返します。sh.getBalancerState() オプションとして、無効化後に移行が進行中でないことを確認するには、
mongosh
shellで次の操作を実行します。use config while( sh.isBalancerRunning() ) { print("waiting..."); sleep(1000); }
注意
ドライバーからバランサーを無効にするには、次のように admin
データベースに対して balancerStop コマンドを使用します。
db.adminCommand( { balancerStop: 1 } )
バランサーを有効にする
バランサーを無効にし、再度有効にする準備ができたら、次の手順に従います。
次のいずれかの操作を発行して、バランサーを有効にします。
mongosh
shell から次を発行します。sh.startBalancer() 注意
ドライバーからバランサーを有効にするには、次のように
admin
データベースに対して balancerStart コマンドを使用します。db.adminCommand( { balancerStart: 1 } ) MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。
MongoDB バージョン 6.0.3 より前では、
sh.startBalancer()
によってシャーディングされたクラスターの自動分割も有効になります。
バックアップ中のバランシングの無効化
注意
バランサーを無効にするのは、 を呼び出すか、特定の時間に呼び出すタスクをスケジュールして、バックアップを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
mongosh
sh.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
は、通常は内部テスト用です。バランサーの _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) 操作が移行中に長時間ブロックされる可能性があります。
特定のシャードの最大ストレージサイズの変更
注意
シャードの最大ストレージ サイズの変更は非推奨です。MongoDB は、WiredTiger ストレージ エンジンを使用してデータの保存方法を管理します。WiredTiger はデータを圧縮してストレージの使用を最小限に抑えます。詳細については、「圧縮」を参照してください。
MongoDB バージョン 6.1 以前の場合でも、maxSize
フィールドを使用して、シャーディングされたクラスター内の特定のシャードの最大ストレージ サイズを設定できます。config.shards
コレクションには、シャードに関連する構成データがあります。
バージョン 6.2 以降では、MongoDB は addShard
コマンドから maxSize
フィールドを削除します。以下はその結果です。