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

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 のバージョン

MongoDB 5.0 以降では、暗黙的なデフォルトの書込み保証 (write concern) を変更する構成レプリカセットを再構成する前に、グローバルのデフォルトの書込み保証 (write concern) を明示的に設定する必要があります。グローバルのデフォルトの書込み保証 (write concern) を設定するには、setDefaultRWConcern コマンドを使用します。

termフィールドはプライマリレプリカセット メンバーによって設定されます。 termrs.reconfig()操作で明示的に設定されている場合、プライマリは フィールドを無視します。

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 回、特定の書き込み操作を再試行することで、自動フェイルオーバーと選挙の組み込み処理を追加で行います。

互換性のあるドライバでは、デフォルトで再試行可能な書き込みが有効になります

実稼働クラスターへの潜在的な影響をさらに軽減するには、スケジュールされたメンテナンス期間中にのみ再構成してください。

警告

MongoDBでは、クラスター内のレプリカセット間で強制的なレプリカセットの再構成を同期しません。 { force: true }を使用すると、 過半数がコミットした書込み のロールバックと シャーディングされたシャーディングされたクラスターが一貫性を失う可能性があります。このオプションを使用する場合は、十分に注意を払ってください。

  • 優先度が priority より大きいノードは、投票数も votes ではありません。

  • 投票権のない(すなわち votes0 の)ノードの priority は 0 である必要があります。

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);
  1. 最初のステートメントは、rs.conf() メソッドを使用してレプリカセットの現在の構成を含むドキュメントを検索し、そのドキュメントをローカル変数 cfg に設定します。

  2. 2 番目のステートメントは、members[n].priority 値を members 配列の 2 番目のドキュメントに設定します。追加設定については、「レプリカセットの構成設定」を参照してください。

    配列内のノード構成ドキュメントにアクセスするために、ステートメントはレプリカセット ノードの members[n]._id フィールドではなく、配列インデックスを使用します。

  3. 最後のステートメントでは、変更された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.heartbeatTimeoutSecs15 に更新されます。操作はプライマリに接続された mongosh セッションを通じて発行されます。

cfg = rs.conf();
cfg.settings.heartbeatTimeoutSecs = 15;
rs.reconfig(cfg);

Tip

以下も参照してください。

戻る

rs.printSecondaryReplicationInfo