Docs Menu

replSetReconfig

replSetReconfig

The replSetReconfig administrative command modifies the configuration of an existing replica set. You can use this command to add and remove members, and to alter the options set on existing members. You must run this command on the admin database of the プライマリ replica set member.

Tip

mongoshでは、このコマンドはrs.reconfig()ヘルパー メソッドを通じて実行することもできます。

ヘルパー メソッドはmongoshユーザーには便利ですが、データベースコマンドと同じレベルの情報は返されない可能性があります。 便宜上必要ない場合、または追加の戻りフィールドが必要な場合は、 データベースコマンドを使用します。

このコマンドは、次の環境でホストされている配置で使用できます。

  • MongoDB Atlas はクラウドでの MongoDB 配置のためのフルマネージド サービスです

重要

このコマンドは、M0、M2、M5、M10+、および Flex クラスターではサポートされていません。詳細については、「 サポートされていないコマンド 」を参照してください。

  • MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン

  • MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン

このコマンドの構文は、次のとおりです。

db.adminCommand(
{
replSetReconfig: <new_config_document>,
force: <boolean>,
maxTimeMS: <int>
}
)

コマンドは、次の任意フィールドがあります。

フィールド
説明

Defaults to false. Specify true to force the available replica set members to accept the new configuration.

Force reconfiguration can result in unexpected or undesired behavior, including rollback of "majority" committed writes.

Optional. Specifies a cumulative time limit in milliseconds for processing the replSetReconfig. By default, replSetReconfig waits indefinitely for the replica configuration to propagate to a majority of replica set members. Setting maxTimeMS may result in the operation failing before it can apply the new configuration. See 再構成により、過半数のノードをレプリカ構成をインストールするまで待機させる for more information.

You may also run replSetReconfig with the shell's rs.reconfig() method.

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

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

replSetReconfigでは、デフォルトで1 votingメンバーのみを追加または削除できます。 たとえば、新しい構成では、クラスター に対して次の いずれかmembership の変更を行うことができます。

  • 新しい投票レプリカセット ノードを追加

  • 既存の投票レプリカセット ノードを排除

  • 既存のレプリカセット ノードの votes を変更

複数の投票メンバーを追加または削除するには、一連のreplSetReconfig操作を発行して、一度に 1 つのメンバーを追加または削除します。

強制再構成を発行すると、複数の投票ノードを追加または削除する場合でも、新しい構成がすぐにインストールされます。 強制的に再構成すると、 "majority"がコミットした書込み操作のロールバックなど、予期しない動作が発生する可能性があります。

replSetReconfigは、投票権のあるレプリカセット ノードの過半数が新しいレプリカ構成をインストールするまで待機し、その後に成功を返します。 投票ノードとは、 が でmembers[n].votes ある1 レプリカセットのノード(アービタを含む)です。

レプリカセット ノードは、ハートビートを介してレプリカ構成を伝達します。ノードは、より高い version および term を持つ構成を学ぶたびに、新しい構成をインストールします。再構成プロセスには、2 つの異なる「待機」フェーズがあります。

1) 新しい構成をインストールする前に、現在の構成がコミットされるまで待機します。

「現在」構成とは、 replSetReconfigが発行された時点でプライマリによって使用されているレプリカ構成を指します。

構成は、次の場合にコミットされます。

  • 投票権のあるレプリカセット ノードの過半数が、現在の構成をインストールした

  • 以前の構成で "majority" でコミットされたすべての書込みが、現在の構成でも過半数に複製された

通常、現在の構成は、投票権のあるレプリカセット ノードの過半数にすでにインストールされています。ただし、以前の構成でコミットされた書込みの過半数が、現在の構成ですべてコミットされるとは限りません。Delayed ノードまたはlagging behind プライマリであるノードは、このフェーズで費やす時間を増やすことができます。

操作がmaxTimeMS制限付きで発行され、待機中操作が制限を超えた場合、操作はエラーを返し、新しい構成を破棄します。 制限は累積であり、次のフェーズに進んでリセットされません。

2) 新しい構成の投票ノードの過半数が新しい構成をインストールするまで待機します。

「新しい」構成とは、 replSetReconfigに指定されたレプリカ構成を指します。

プライマリは、新しいレプリカ構成をインストールして使用を開始し、その後に構成を残りのレプリカセット ノードに伝達します。 この操作は、投票権のあるノードの過半数が新しい構成をインストールすることは待ちますが、新しい構成がコミットされることを待つ必要はありません。

操作がmaxTimeMS制限付きで発行され、待機中操作が制限を超えた場合、操作はエラーを返します、新しい構成の使用と伝達は続行されます。

強制再構成を発行すると、前の構成のコミット ステータスに関係なく、新しい構成がすぐにインストールされます。 強制的に再構成すると、 "majority"がコミットした書込み操作のロールバックなど、予期しない動作が発生する可能性があります。

現在のレプリカ構成のコミット ステータスを確認するには、レプリカ セットのプライマリで、commitStatus パラメータを指定して replSetGetConfig を発行します。

MongoDB 5.0 以降では、新しく追加されたセカンダリは投票ノードとしてカウントされず、SECONDARY 状態に達するまで選出されません。

When a new voting node is added to a replica set, replSetReconfig will internally add a newlyAdded field to the node's configuration. Nodes with the newlyAdded field do not count towards the current number of voting nodes. When initial sync completes and the node reaches SECONDARY state, the newlyAdded field is automatically removed.

注意

  • newlyAdded という名前のフィールドを追加しようとする構成は、{ force: true } で実行した場合でもエラーになります。

  • If an existing node has a newlyAdded field, using rs.reconfig() to change the configuration will not remove the newlyAdded field. The newlyAdded field will be appended to the user provided configuration.

  • replSetGetConfig は、その出力からすべての newlyAdded フィールドを除きます。newlyAdded フィールドを表示する場合は、local.system.replset コレクションに直接クエリできます。

To run the command on deployments that enforce access control, the user must have replSetConfigure privilege action on the cluster resource. The clusterManager built-in role, available in the admin database, provides the required privileges for this command.

replSetReconfigは、複数のreplSetReconfig操作が同時に発生するのを防ぐために特別な相互排他ロックを取得します。

警告

MongoDB のバージョンによって検証ルールが異なる可能性があるため、異なるバージョンの MongoDB のノードを含むレプリカセットの再設定は避けてください。

A majority of the set's members must be operational for the changes to propagate properly.

replSetReconfig can trigger the current primary to step down in some situations. Primary step-down triggers an 選挙 to select a new プライマリ:

  • When the new primary steps up, it increments the term field to distinguish configuration changes made on the new primary from changes made on the previous primary.

  • When the primary steps down, it no longer closes all client connections; however, writes that were in progress are killed. For details, see 動作.

デフォルトの replica configuration settings を前提とすると、クラスターが新しいプライマリを選択するまでの時間の中央値は、通常 12 秒を超えないはずです。これには、プライマリを利用不可としてマークし、選挙を呼び出して完了するために必要な時間が含まれます。settings.electionTimeoutMillis レプリケーション構成オプションを変更することで、この期間を調整できます。ネットワーク レイテンシなどの要因により、レプリカセット選挙が完了するまでにかかる時間が長くなる可能性があり、その結果、クラスターがプライマリなしで稼働できる時間にも影響します。これらの要因は、お使いのクラスター アーキテクチャによって異なります。

選挙プロセス中、クラスタは新しいプライマリを選出するまで書込み (write) 操作を受け付けません。

アプリケーション接続ロジックには、自動フェールオーバーとその後の選挙に対する許容範囲が含まれている必要があります。MongoDB ドライバーはプライマリの損失を検出し、自動的に 1 回、特定の書き込み操作を再試行することで、自動フェイルオーバーと選挙の組み込み処理を追加で行います。

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

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

警告

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

Using replSetReconfig to remove a replica set member does not automatically drop open outgoing connections from other replica set members to the removed member.

デフォルトでは、レプリカセット ノードは 5 分間待機してから、除外されたノードへの接続を削除します。シャーディングされたレプリカセットでは、ShardingTaskExecutorPoolHostTimeoutMS サーバー パラメーターを使用してこのタイムアウトを変更できます。

レプリカセットから削除されたノードへのすべての送信接続をすぐに削除するには、レプリカセット上の残りの各ノードでdropConnections管理コマンドを実行します。

db.adminCommand(
{
"dropConnections" : 1,
"hostAndPort" : [
"<hostname>:<port>"
]
}
)

<hostname><port> を除外されたノードのものに置き換えます。

警告

MongDB 5.0 以降、IP アドレスのみが設定されているスプリット ホライゾン DNS ノードは起動時の検証に失敗し、エラーを報告します。disableSplitHorizonIPCheck を参照してください。

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

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

レプリカセット構成フィールド, 自己管理型レプリカセットの構成, rs.reconfig(), and rs.conf().