バージョン3.4での変更: バランサー プロセスは、 mongos
インスタンスからコンフィギュレーションサーバー レプリカセットのプライマリ ノードに移動されました。
このページでは、バランシングに関連する一般的な管理手順について説明します。 バランシングの概要については、「 シャーディングされたクラスターのバランサー」を参照してください。 バランシングに関する下位レベルの情報については、「クラスター バランサー 」を参照してください。
バランサーの状態の確認
sh.getBalancerState()
は、バランサーが有効かどうか(すなわち、バランサーの実行が許可されているかどうか)を確認します。 sh.getBalancerState()
は、バランサーがアクティブにチャンクをバランシングしているかどうかを確認しません。
シャーディングされたクラスターでバランサーが有効になっているかどうかを確認するには、次のコマンドを実行します。このコマンドはブール値を返します。
sh.getBalancerState()
sh.status()
を使用して、バランサーが有効かどうかも確認できます。currently-enabled
フィールドはバランサーが有効かどうかを示し、currently-running
フィールドはバランサーが現在実行中かどうかを示します。
バランサーが実行中であることを確認します
クラスターでバランサーのプロセスがアクティブかどうかを確認する方法は次のとおりです。
デフォルトのチャンク サイズの構成
シャーディングされたクラスターのデフォルトのチャンク サイズは64メガバイトです。 ほとんどの場合、チャンクの分割と移行にはデフォルトのサイズが適切です。 チャンクのサイズが配置に与える影響について、詳細は「チャンク サイズ 」を参照してください。
デフォルトのチャンク サイズを変更すると、移行および自動分割中に処理されるチャンクに影響しますが、すべてのチャンクには遡及して影響するわけではありません。
デフォルトのチャンクサイズを構成するには、「シャーディングされたクラスターのチャンクサイズの変更 」を参照してください。
バランシング ウィンドウのスケジュール
状況によっては、特にデータセットの増大が遅く、移行がパフォーマンスに影響する可能性がある場合、バランサーを特定の時間のみアクティブにしておくと便利です。次の手順では、バランサーがチャンクを移行できる時間枠である activeWindow
を指定します。
コンフィギュレーションデータベース に切り替えます。
次のコマンドを発行して、コンフィギュレーションデータベースに切り替えます。
use config
バランサーがstopped
でないことを確認します。
stopped
の状態ではバランサーはアクティブになりません。バランサーが stopped
ではないことを確認するには、次のように sh.startBalancer()
を使用します。
sh.startBalancer()
activeWindow
の時間枠を外れるとバランサーは起動しません。
MongoDB 4.2 以降では、 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 タイムゾーンに対して開始時間と停止時間を相対的に評価します。
注意
バランサー ウィンドウは、その日に挿入されたすべてのデータの移行を完了するのに十分でなければなりません。
データ挿入率はアクティビティや使用パターンによって変わる可能性があるため、選択したバランシング ウィンドウが配置のニーズをサポートするのに十分であることを確認するのが重要です。
バランシング ウィンドウのスケジュールの削除
バランシング ウィンドウを設定しており、スケジュールを削除してバランサーが常に実行されるようにする場合は、次のように$unset
を使用してactiveWindow
をクリアします。
use config db.settings.updateOne( { _id : "balancer" }, { $unset : { activeWindow : true } } )
バランサーを無効にする
重要
デフォルトでは、バランサーはいつでも実行でき、必要な場合にのみチャンクを移動します。バランサーを短期間無効にしてすべての移行を防ぐ場合は、次の手順に従います。
次の操作を発行して、バランサーを無効にします。
sh.stopBalancer() 移行が進行中の場合、システムは進行中の移行を完了してから停止します。
MongoDB 4.2 以降では、
sh.stopBalancer()
もシャーディングされたクラスターの自動分割を無効にします。バランサーが起動しないことを確認するには、次のコマンドを実行します。このコマンドは、バランサーが無効になっている場合は
false
を返します。sh.getBalancerState() オプションとして、無効化後に移行が進行中でないことを確認するには、
mongo
shell で次の操作を実行します。use config while( sh.isBalancerRunning() ) { print("waiting..."); sleep(1000); }
注意
ドライバーからバランサーを無効にするには、次のように admin
データベースに対して balancerStop コマンドを使用します。
db.adminCommand( { balancerStop: 1 } )
バランサーを有効にする
バランサーを無効にし、再度有効にする準備ができたら、次の手順に従います。
次のいずれかの操作を発行して、バランサーを有効にします。
mongo
shell から次を発行します。sh.startBalancer() 注意
ドライバーからバランサーを有効にするには、次のように
admin
データベースに対して balancerStart コマンドを使用します。db.adminCommand( { balancerStart: 1 } ) MongoDB 4.2 以降では、
sh.startBalancer()
によるシャーディングされたクラスターの自動分割も有効になります。
バックアップ中のバランシングの無効化
注意
バランサーを無効にするのは、 を呼び出すか、特定の時間に呼び出すタスクをスケジュールして、バックアップをmongodump
手動でmongodump
取得する場合にのみ必要です。
協調したバックアップと復元のプロセスを使用する場合、バランサーを無効にする必要はありません。
MongoDB がバックアップ中にチャンクを移行すると、シャーディングされたクラスターのスナップショットが不整合になる可能性があります。バランサーがアクティブな間はバックアップを実行しないでください。バックアップ操作中にバランサーが非アクティブであることを確認する方法。
バランシング ウィンドウを設定して、バックアップ中にバランサーが非アクティブになるようにします。 バランサーを無効にした状態でバックアップが完了することを確認します。
バックアップ手順の実行中にバランサーを手動で無効にする。
バランサー ラウンドの最中にバランサーの電源を切ると、瞬時にはシャットダウンされません。バランサーは進行中のチャンクの移動を完了し、それ以降のバランサー ラウンドをすべて中止します。
バックアップ操作を開始する前に、バランサーがアクティブでないことを確認してください。次のコマンドを使用して、バランサーがアクティブかどうかを確認できます。
!sh.getBalancerState() && !sh.isBalancerRunning()
バックアップ手順が完了したら、バランサー プロセスを再度有効化できます。
コレクションでのバランシングの無効化
sh.disableBalancing()
メソッドを使用して、特定のコレクションのバランシングを無効にできます。データの取り込みやデータのエクスポートなどの最中に、メンテナンス操作や非定型のワークロードをサポートするために、特定のコレクションのバランサーを無効にしたい場合があります。
コレクションのバランシングを無効にすると、MongoDB は進行中の移行を中断しません。
コレクションのバランシングを無効にするには、 shellmongos
mongo
sh.disableBalancing()
を使用して に接続し、 メソッドを呼び出します。
以下に例を挙げます。
sh.disableBalancing("students.grades")
sh.disableBalancing()
メソッドは、コレクションの完全な名前空間をパラメータとして受け入れます。
コレクションでのバランシングの有効化
sh.enableBalancing()
メソッドを使用して、特定のコレクションのバランシングを有効にできます。
コレクションのバランシングを有効にしても、MongoDB はデータのバランシングをすぐには開始しません。しかし、シャーディングされたコレクションのデータがバランシングされていない場合、MongoDB はデータのより均等な分散を始めることができます。
コレクションのバランシングを有効にするには、 shellmongos
mongo
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
インスタンスに接続し、_secondaryThrottle
構成 データベース のsettings
コレクション内の 値を直接更新します。たとえば、 に接続されたmongo
shellmongos
から、次のコマンドを発行します。
use config db.settings.updateOne( { "_id" : "balancer" }, { $set : { "_secondaryThrottle" : { "w": "majority" } } }, { upsert : true } )
_secondaryThrottle
設定を変更しても、その効果はすぐには現れない場合があります。すぐに効果を得るには、バランサーを停止して再起動し、選択した値 _secondaryThrottle
を有効にします。
チャンク移行のさまざまなステップにおけるレプリケーション動作の詳細については、「チャンクの移行とレプリケーション 」を参照してください。
moveChunk
コマンドの場合、コマンド実行中の動作を指定するには、 コマンドの_secondaryThrottle
オプションとwriteConcern
オプションを使用できます。詳しくは、 moveChunk
コマンドを参照してください。
削除を待つ
バランサーの_waitForDelete
設定とmoveChunk
コマンドは、バランサーがシャードから複数のチャンクを移行する方法に影響します。 デフォルトでは、バランサーは進行中の移行の削除フェーズが完了するのを待たずに、次のチャンクの移行を開始します。 削除フェーズで次のチャンク移行の開始をブロックする には、 _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" : "" } } )
サイズ制限を超えるチャンクの調整
デフォルトでは、チャンク内のドキュメント数が、構成されたチャンク サイズを平均ドキュメント サイズで割った結果の1.3倍を超える場合、MongoDB はチャンクを移動できません。
バランサー設定attemptToBalanceJumboChunks
をtrue
に指定することで、バランサーはjumbo というラベルが付いていない限り、これらの大きな範囲を移行できます。
バランサーのattemptToBalanceJumboChunks
設定を行うには、 mongos
インスタンスに接続し、 config.settings
コレクションを直接更新します。 たとえば、 インスタンスに接続されたmongo
shellmongos
から、次のコマンドを発行します。
db.getSiblingDB("config").settings.updateOne( { _id: "balancer" }, { $set: { attemptToBalanceJumboChunks : true } }, { upsert: true } )
移動したいチャンクにjumbo
というラベルがある場合は、 ジャンボ フラグを手動でクリアして バランサーにチャンクの移行を試行させることができます。
あるいは、moveChunk
forceJumbo: true jumbo
とともに コマンドを使用して、サイズ制限を超えるチャンク( ラベルの有無にかかわらず)を手動で移行することもできます。wただし、moveChunk
forceJumbo: true とともに実行すると、コレクションへの書き込み (write) 操作が移行中に長時間ブロックされる可能性があります。
特定のシャードの最大ストレージサイズの変更
デフォルトでは、シャードにはストレージ サイズの制約はありません。 ただし、シャーディングされたクラスター内の特定のシャードの最大ストレージ サイズを設定できます。 潜在的な宛先シャードを選択する場合、バランサーは移行が設定された最大ストレージサイズを超えるシャードを無視します。
コンフィギュレーションshards
データベース の コレクションには、シャードに関連する構成データが保存されています。
{ "_id" : "shard0000", "host" : "shard1.example.com:27100" } { "_id" : "shard0001", "host" : "shard2.example.com:27200" }
特定のシャードのストレージ サイズを制限するには、 演算子を使用してdb.collection.updateOne()
$set
メソッドを使用してmaxSize
フィールドを作成し、そのフィールドにinteger
値を割り当てます。maxSize
フィールドは、 megabytes
内のシャードの最大ストレージ サイズを表します。
次の操作では、シャードの最大サイズを1024 megabytes
に設定します。
config = db.getSiblingDB("config") config.shards.updateOne( { "_id" : "<shard>"}, { $set : { "maxSize" : 1024 } } )
この値には、 データベースと データベースを含む、シャード上のlocal
すべてのadmin
データファイルのマッピングされたサイズが含まれます。
デフォルトでは、 maxSize
は指定されていないため、シャードは必要に応じてマシン上の利用可能なスペースの合計量を消費することができます。
シャードを追加するときにmaxSize
を設定することもできます。
シャードを追加するときにmaxSize
を設定するには、 addShard
コマンドのmaxSize
パラメータをmegabytes
の最大サイズに設定します。 mongo
shell で実行される次のコマンドは、最大サイズが125メガバイトのシャードを追加します。
config = db.getSiblingDB("config") config.runCommand( { addshard : "example.net:34008", maxSize : 125 } )