rs.reconfig()
定義
rs.reconfig( configuration, { options } )
既存のレプリカセットを再構成し、既存のレプリカセット構成を上書きします。メソッドを実行するには、レプリカセットのプライマリに接続する必要があります。
重要
mongosh メソッド
このページでは、
mongosh
メソッドについて説明します。ただし、データベースコマンドや Node.js などの言語固有のドライバーのドキュメントには該当しません。データベースコマンドについては、
replSetReconfig
コマンドを参照してください。MongoDB API ドライバーについては、各言語の MongoDB ドライバー ドキュメントを参照してください。
rs.reconfig()
メソッドの構文は次のとおりです。rs.reconfig( <configuration>, { "force" : <boolean>, "maxTimeMS" : <int> } ) Parameterタイプ説明ドキュメント
レプリカセットの構成を指定するドキュメント。
ブール値
任意
使用可能なレプリカセット ノードに新しい構成を強制的に受け入れさせるには、
true
を指定します。デフォルトはfalse
です。強制的に再構成すると、
"majority"
がコミットした書き込みのロールバックなど、予期しない動作や望ましくない動作が発生する可能性があります。integer
任意
rs.reconfig()
操作を処理するための累積時間制限をミリ秒単位で指定します。デフォルトでは 、rs.reconfig()
はレプリカ構成が過半数のレプリカセットメンバーに反映されるまで無期限に待機します。既存のレプリカセットを再構成するには、まず
rs.conf()
を使用して現在の構成を取得し、必要に応じて構成ドキュメントを変更し、変更されたドキュメントをrs.reconfig()
に渡します。force
パラメーターを使用すると、非プライマリ ノードに対し再構成コマンドを発行できます。
互換性
このメソッドは、次の環境でホストされている配置で使用できます。
MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン
MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン
動作
グローバル書込み保証 (write concern)
MongoDB 5.0 以降では、暗黙的なデフォルトの書込み保証 (write concern) を変更する構成でレプリカセットを再構成する前に、グローバルのデフォルトの書込み保証 (write concern) を明示的に設定する必要があります。グローバルのデフォルトの書込み保証 (write concern) を設定するには、setDefaultRWConcern
コマンドを使用します。
term
レプリカ構成フィールド
term
フィールドはプライマリレプリカセット メンバーによって設定されます。 term
rs.reconfig()
操作で明示的に設定されている場合、プライマリは フィールドを無視します。
再構成により追加または除外できるのは一度に 1 つの投票ノードのみ
rs.reconfig()
では、デフォルトで1
voting
メンバーのみを追加または削除できます。 たとえば、新しい構成では、クラスター に対して次の いずれかmembership
の変更を行うことができます。
新しい投票レプリカセット ノードを追加
既存の投票レプリカセット ノードを排除
既存のレプリカセット ノードの
votes
を変更
複数の投票メンバーを追加または削除するには、一連のrs.reconfig()
操作を発行して、一度に 1 つのメンバーを追加または削除します。
強制再構成を発行すると、複数の投票ノードを追加または削除する場合でも、新しい構成がすぐにインストールされます。 強制的に再構成すると、 "majority"
がコミットした書込み操作のロールバックなど、予期しない動作が発生する可能性があります。
再構成により、過半数のノードをレプリカ構成をインストールするまで待機させる
rs.reconfig()
は、投票権のあるレプリカセット ノードの過半数が新しいレプリカ構成をインストールするまで待機し、その後に成功を返します。 投票ノードとは、 が でmembers[n].votes
ある1
レプリカセットのノード(アービタを含む)です。
レプリカセット ノードは、ハートビートを介してレプリカ構成を伝達します。ノードは、より高い version
および term
を持つ構成を学ぶたびに、新しい構成をインストールします。再構成プロセスには、2 つの異なる「待機」フェーズがあります。
- 1) 新しい構成をインストールする前に、現在の構成がコミットされるまで待機します。
「現在」構成とは、
rs.reconfig()
が発行された時点でプライマリによって使用されているレプリカ構成を指します。構成は、次の場合にコミットされます。
投票権のあるレプリカセット ノードの過半数が、現在の構成をインストールした
以前の構成で
"majority"
でコミットされたすべての書込みが、現在の構成でも過半数に複製された
通常、現在の構成は、投票権のあるレプリカセット ノードの過半数にすでにインストールされています。ただし、以前の構成でコミットされた書込みの過半数が、現在の構成ですべてコミットされるとは限りません。
Delayed
ノードまたはlagging behind
プライマリであるノードは、このフェーズで費やす時間を増やすことができます。操作がmaxTimeMS制限付きで発行され、待機中に操作が制限を超えた場合、操作はエラーを返し、新しい構成を破棄します。 制限は累積であり、次のフェーズに進んでリセットされません。
- 2) 新しい構成の投票ノードの過半数が新しい構成をインストールするまで待機します。
「新しい」構成とは、
rs.reconfig()
に指定されたレプリカ構成を指します。プライマリは、新しいレプリカ構成をインストールして使用を開始し、その後に構成を残りのレプリカセット ノードに伝達します。 この操作は、投票権のあるノードの過半数が新しい構成をインストールすることは待ちますが、新しい構成がコミットされることを待つ必要はありません。
操作がmaxTimeMS制限付きで発行され、待機中に操作が制限を超えた場合、操作はエラーを返しますが、新しい構成の使用と伝達は続行されます。
強制再構成を発行すると、前の構成のコミット ステータスに関係なく、新しい構成がすぐにインストールされます。 強制的に再構成すると、 "majority"
がコミットした書込み操作のロールバックなど、予期しない動作が発生する可能性があります。
現在のレプリカ構成のコミット ステータスを確認するには、レプリカ セットのプライマリで、commitStatus パラメータを指定して replSetGetConfig
を発行します。
アクセス制御
アクセス制御を強制する配置でメソッドを実行するには、ユーザーはクラスター リソースに対する replSetConfigure
特権アクションを持っている必要があります。admin
データベースで使用可能な clusterManager
組み込みロールは、このコマンドに必要な特権を提供します。
ロック動作
rs.reconfig()
は、複数のrs.reconfig()
操作が同時に発生するのを防ぐために特別な相互排他ロックを取得します。
混合バージョンのレプリカセット
警告
MongoDB のバージョンによって検証ルールが異なる可能性があるため、異なるバージョンの MongoDB のノードを含むレプリカセットの再設定は避けてください。
可用性
rs.reconfig()
shellメソッドは、状況によっては現在のプライマリの降格をtriggerできます。 プライマリがステップダウンすると選挙がトリガーされて、新しいプライマリが選出されます。
プライマリが降格すると、進行中のすべての書込みが停止します。 詳細については、「動作 」を参照してください。
デフォルトの replica
configuration settings
を前提とすると、クラスターが新しいプライマリを選択するまでの時間の中央値は、通常 12 秒を超えないはずです。これには、プライマリを利用不可としてマークし、選挙を呼び出して完了するために必要な時間が含まれます。settings.electionTimeoutMillis
レプリケーション構成オプションを変更することで、この期間を調整できます。ネットワーク レイテンシなどの要因により、レプリカセット選挙が完了するまでにかかる時間が長くなる可能性があり、その結果、クラスターがプライマリなしで稼働できる時間にも影響します。これらの要因は、お使いのクラスター アーキテクチャによって異なります。
選挙プロセス中、クラスタは新しいプライマリを選出するまで書込み (write) 操作を受け付けません。
アプリケーション接続ロジックには、自動フェールオーバーとその後の選挙に対する許容範囲が含まれている必要があります。MongoDB ドライバーはプライマリの損失を検出し、自動的に 1 回、特定の書き込み操作を再試行することで、自動フェイルオーバーと選挙の組み込み処理を追加で行います。
互換性のあるドライバでは、デフォルトで再試行可能な書き込みが有効になります
実稼働クラスターへの潜在的な影響をさらに軽減するには、スケジュールされたメンテナンス期間中にのみ再構成してください。
{ force: true }
ノードの優先順位と投票
ノードを除外した後に発信接続を削除する
rs.reconfig()
を使用してレプリカセット ノードを削除しても、削除されたノードへの他のレプリカセット ノードからの開いている送信接続が自動的に削除されることはありません。
デフォルトでは、レプリカセット ノードは 5 分間待機してから、除外されたノードへの接続を削除します。シャーディングされたレプリカセットでは、ShardingTaskExecutorPoolHostTimeoutMS
サーバー パラメーターを使用してこのタイムアウトを変更できます。
レプリカセットから削除されたノードへのすべての送信接続をすぐに削除するには、レプリカセット上の残りの各ノードでdropConnections
管理コマンドを実行します。
db.adminCommand( { "dropConnections" : 1, "hostAndPort" : [ "<hostname>:<port>" ] } )
<hostname>
と <port>
を除外されたノードのものに置き換えます。
新しい投票レプリカセットノードの自動再構成
MongoDB 5.0 以降では、新しく追加されたセカンダリは投票ノードとしてカウントされず、SECONDARY
状態に達するまで選出されません。
新しい投票ノードがレプリカセットに追加されると、replSetReconfig
はノードの構成に newlyAdded
フィールドを内部的に追加します。newlyAdded
フィールドを持つノードは、現在の投票ノードの数にはカウントされません。最初の同期が完了し、ノードがSECONDARY
の状態に達すると、newlyAdded
フィールドは自動的に削除されます。
注意
newlyAdded
という名前のフィールドを追加しようとする構成は、{ force: true }
で実行した場合でもエラーになります。既存のノードに
newlyAdded
フィールドがある場合、rs.reconfig()
を使用して構成を変更してもnewlyAdded
フィールドは削除されません。newlyAdded
フィールドは、ユーザーが提供した構成に追加されます。replSetGetConfig
は、その出力からすべてのnewlyAdded
フィールドを除きます。newlyAdded
フィールドを表示する場合は、local.system.replset
コレクションに直接クエリできます。
例
rs0
という名前のレプリカセットは以下のような構成になっています。
{ "_id" : "rs0", "version" : 1, "protocolVersion" : NumberLong(1), "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : 2000, "getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("58858acc1f5609ed986b641b") } }
レプリカセット ノードの優先順位の変更
次の一連の操作により、2 つ目のメンバーのmembers[n].priority
が更新されます。 操作はプライマリに接続されたmongosh
セッションを通じて発行されます。
cfg = rs.conf(); cfg.members[1].priority = 2; rs.reconfig(cfg);
最初のステートメントは、
rs.conf()
メソッドを使用してレプリカセットの現在の構成を含むドキュメントを検索し、そのドキュメントをローカル変数cfg
に設定します。2 番目のステートメントは、
members[n].priority
値をmembers
配列の 2 番目のドキュメントに設定します。追加設定については、「レプリカセットの構成設定」を参照してください。配列内のノード構成ドキュメントにアクセスするために、ステートメントはレプリカセット ノードの
members[n]._id
フィールドではなく、配列インデックスを使用します。最後のステートメントでは、変更された
cfg
を含むrs.reconfig()
メソッドを呼び出して、この新しい構成を初期化します。 正常に再構成されると、レプリカセットの構成は次のようになります。
{ "_id" : "rs0", "version" : 2, "protocolVersion" : NumberLong(1), "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 2, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : 2000, "getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("58858acc1f5609ed986b641b") } }
レプリカセット設定の変更
クラスター レプリカセット settings
ドキュメントを変更することもできます。settings
ドキュメントには、レプリカセット全体に適用される構成オプションが含まれています。
次の一連の操作により、クラスターの settings.heartbeatTimeoutSecs
が 15
に更新されます。操作はプライマリに接続された mongosh
セッションを通じて発行されます。
cfg = rs.conf(); cfg.settings.heartbeatTimeoutSecs = 15; rs.reconfig(cfg);