Docs Menu
Docs Home
/
MongoDBマニュアル
/ /

シャーディングされたクラスター バランサーの管理

項目一覧

  • バランサーの状態の確認
  • バランサーが実行中であることを確認します
  • デフォルトの範囲サイズの構成
  • バランシング ウィンドウのスケジュール
  • バランシング ウィンドウのスケジュールの削除
  • バランサーを無効にする
  • バランサーを有効にする
  • バックアップ中のバランシングの無効化
  • コレクションでのバランシングの無効化
  • コレクションでのバランシングの有効化
  • バランシングが有効か無効かの確認
  • チャンク移行のレプリケーション動作の変更
  • 特定のシャードの最大ストレージサイズの変更

バージョン 6.1 での変更

このページでは、バランシングに関連する一般的な管理手順について説明します。バランシングの概要については、「 シャーディングされたクラスターのバランサー」を参照してください。バランシングに関する下位レベルの情報については、「バランサーの内部」を参照してください。

バランサー プロセスは、mongos インスタンスから構成サーバー レプリカセットのプライマリ メンバーに移動されました。

sh.getBalancerState() は、バランサーが有効かどうか(すなわち、バランサーの実行が許可されているかどうか)を確認します。sh.getBalancerState() は、バランサーがアクティブにデータを移行するかどうかを確認しません。

シャーディングされたクラスターでバランサーが有効になっているかどうかを確認するには、次のコマンドを実行します。このコマンドはブール値を返します。

sh.getBalancerState()

sh.status() を使用して、バランサーが有効かどうかも確認できます。currently-enabled フィールドはバランサーが有効かどうかを示し、currently-running フィールドはバランサーが現在実行中かどうかを示します。

クラスターでバランサーのプロセスがアクティブかどうかを確認する方法は次のとおりです。

  1. mongosh shell を使用して、クラスター内の任意の mongos に接続します。

  2. バランサーが実行中かどうかを確認するには、次の操作を使用します。

    sh.isBalancerRunning()

シャーディングされたクラスターのデフォルトの範囲サイズは 128 メガバイトです。ほとんどの場合、チャンクの分割と移行にはデフォルトのサイズが適切です。範囲サイズが配置に与える影響について、詳細は「範囲サイズ」を参照してください。

デフォルトの範囲サイズを変更すると、移行および自動分割中に処理される範囲に影響しますが、すべての範囲に遡及して影響するわけではありません。

MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。

デフォルトの範囲サイズを構成するには、「シャーディングされたクラスターの範囲サイズの変更」を参照してください。

状況によっては、特にデータセットの増大が遅く、移行がパフォーマンスに影響する可能性がある場合、バランサーを特定の時間のみアクティブにしておくと便利です。次の手順では、バランサーがチャンクを移行できる時間枠である activeWindow を指定します。

1

クラスターのどの mongos にも接続できます。

2

次のコマンドを発行して、コンフィギュレーションデータベースに切り替えます。

use config
3

stopped の状態ではバランサーはアクティブになりません。バランサーが stopped ではないことを確認するには、次のように sh.startBalancer() を使用します。

sh.startBalancer()

activeWindow の時間枠を外れるとバランサーは起動しません。

MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。

MongoDB バージョン 6.0.3 より前では、sh.startBalancer() によってシャーディングされたクラスターの自動分割も有効になります。

4

次のように、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 値には、0023 の範囲の時間の値を使用します。

  • MM 値には、0059 の範囲の分の値を使用します。

オンプレミスまたは自己管理型のシャーディングされたクラスターの場合、MongoDB はコンフィギュレーションサーバーのレプリカセット内のプライマリ ノードのタイムゾーンを基準にして、開始時間と停止時間を評価します。

Atlas クラスターの場合、MongoDB は UTC タイムゾーンに対して開始時間と停止時間を相対的に評価します。

注意

バランサー ウィンドウは、その日に挿入されたすべてのデータの移行を完了するのに十分でなければなりません。

データ挿入率はアクティビティや使用パターンによって変わる可能性があるため、選択したバランシング ウィンドウが配置のニーズをサポートするのに十分であることを確認するのが重要です。

バランシング ウィンドウを設定しており、スケジュールを削除してバランサーが常に実行されるようにする場合は、次のように$unsetを使用してactiveWindowをクリアします。

use config
db.settings.updateOne( { _id : "balancer" }, { $unset : { activeWindow : true } } )

重要

バランサーを長期間無効のままにすると、シャードのバランスが取れず、クラスターのパフォーマンスが低下する可能性があります。 必要な場合のみバランサーを無効にし、メンテナンスが完了した後にバランサーを再度有効にするようにします。

デフォルトでは、バランサーはいつでも実行でき、必要な場合にのみチャンクを移動します。バランサーを短期間無効にしてすべての移行を防ぐ場合は、次の手順に従います。

  1. mongosh shellを使用して、クラスター内の任意の mongos に接続します。

  2. 次の操作を発行して、バランサーを無効にします。

    sh.stopBalancer()

    移行が進行中の場合、システムは進行中の移行を完了してから停止します。

    MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。

    MongoDB バージョン 6.0.3 より前では、sh.stopBalancer() によってシャーディングされたクラスターの自動分割も無効になります。

  3. バランサーが起動しないことを確認するには、次のコマンドを実行します。このコマンドは、バランサーが無効になっている場合はfalseを返します。

    sh.getBalancerState()

    オプションとして、無効化後に移行が進行中でないことを確認するには、mongosh shellで次の操作を実行します。

    use config
    while( sh.isBalancerRunning() ) {
    print("waiting...");
    sleep(1000);
    }

注意

ドライバーからバランサーを無効にするには、次のように admin データベースに対して balancerStop コマンドを使用します。

db.adminCommand( { balancerStop: 1 } )

バランサーを無効にし、再度有効にする準備ができたら、次の手順に従います。

  1. mongosh shellを使用して、クラスター内の任意の mongos に接続します。

  2. 次のいずれかの操作を発行して、バランサーを有効にします。

    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 mongoshsh.enableBalancing()を使用して に接続し、 メソッドを呼び出します。

以下に例を挙げます。

sh.enableBalancing("students.grades")

sh.enableBalancing() メソッドは、コレクションの完全な名前空間をパラメータとして受け入れます。

コレクションのバランシングが有効か無効かを確認するには、コレクション名前空間config データベース内の collections コレクションをクエリし、noBalance フィールドを確認します。以下に例を挙げます。

db.getSiblingDB("config").collections.findOne({_id : "students.grades"}).noBalance;

この操作は null エラー、truefalse を返すか、出力なしになります。

  • 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 を有効にします。

チャンク移行のさまざまなステップにおけるレプリケーション動作の詳細については、「範囲の移行とレプリケーション」を参照してください。

  • コマンド実行中の動作を指定するには、moveRange コマンドの secondaryThrottle および writeConcern オプションを使用します。

  • コマンド実行中の動作を指定するには、moveChunk コマンドの _secondaryThrottle および writeConcern オプションを使用します。

詳細については、moveRangemoveChunk を参照してください。

バランサーの _waitForDelete 設定と moveChunk コマンドは、バランサーがシャードから複数のチャンクを移行する方法に影響します。同様に、バランサーの _waitForDelete 設定と moveRange コマンドも、バランサーがシャードから複数のチャンクを移行する方法に影響します。デフォルトでは、バランサーは進行中の移行の削除フェーズが完了するのを待たずに次のチャンク移行を開始します。削除フェーズで次のチャンク移行の開始をブロックするには、_waitForDelete を true に設定します。

チャンク移行の詳細については、「範囲の移行」を参照してください。チャンク移行キューイングの動作の詳細については、「非同期範囲移行のクリーンアップ」を参照してください。

この _waitForDelete は、通常は内部テスト用です。バランサーの _waitForDelete 値を変更する方法。

  1. mongos インスタンスに接続します。

  2. コンフィギュレーションデータベースsettings コレクション内にある _waitForDelete 値をアップデートします。以下に例を挙げます。

    use config
    db.settings.updateOne(
    { "_id" : "balancer" },
    { $set : { "_waitForDelete" : true } },
    { upsert : true }
    )

true に設定すると、デフォルトの動作に戻ります。

  1. mongos インスタンスに接続します。

  2. コンフィギュレーションデータベースsettings コレクション内にある _waitForDelete フィールドをアップデートまたは設定解除します。

    use config
    db.settings.updateOne(
    { "_id" : "balancer", "_waitForDelete": true },
    { $unset : { "_waitForDelete" : "" } }
    )

デフォルトでは、範囲内のドキュメント数が、構成された範囲サイズを平均ドキュメント サイズで割った結果の 2 倍を超える場合、MongoDB は範囲を移動できません。

バランサー設定attemptToBalanceJumboChunkstrueに指定することで、バランサーは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 または moveChunk を実行すると、コレクションへの書込み (write) 操作が移行中に長時間ブロックされる可能性があります。

注意

シャードの最大ストレージ サイズの変更は非推奨です。MongoDB は、WiredTiger ストレージ エンジンを使用してデータの保存方法を管理します。WiredTiger はデータを圧縮してストレージの使用を最小限に抑えます。詳細については、「圧縮」を参照してください。

MongoDB バージョン 6.1 以前の場合でも、maxSize フィールドを使用して、シャーディングされたクラスター内の特定のシャードの最大ストレージ サイズを設定できます。config.shards コレクションには、シャードに関連する構成データがあります。

バージョン 6.2 以降では、MongoDB は addShard コマンドから maxSize フィールドを削除します。以下はその結果です。

  • maxSize フィールドで addShard を実行すると、InvalidOptions エラーが返されます。

  • shards コレクション内の新しいドキュメントには、maxSize フィールドは含まれなくなりました。

  • 既存の maxSize フィールド エントリはすべて無視されます。

戻る

バランサー