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

replSetReconfig

項目一覧

  • 定義
  • 互換性
  • 構文
  • コマンドフィールド
  • 動作
  • 詳細情報
replSetReconfig

replSetReconfig管理コマンドは、既存のレプリカセットの構成を変更します。 このコマンドを使用して、ノードを追加および削除したり、既存のノードに設定されているオプションを変更したりできます。 このコマンドは、 プライマリレプリカセット ノードのadminデータベースで実行する必要があります。

Tip

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

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

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

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

重要

このコマンドは、M 0 、M 2 、M 5 、M 10 + クラスターではサポートされていません。 詳細については、「サポートされていないコマンド 」を参照してください。

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

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

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

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

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

フィールド
説明

デフォルトはfalseです。 使用可能なレプリカセット ノードに新しい構成を強制的に受け入れさせるには、 trueを指定します。

強制的に再構成すると、"majority" がコミットした書き込みのロールバックなど、予期しない動作や望ましくない動作が発生する可能性があります。

任意。 replSetReconfigを処理するための累積時間制限をミリ秒単位で指定します。 デフォルトでは、 replSetReconfigはレプリカ構成が大多数のレプリカセット メンバーに伝達されるまで、無期限に待機します。 maxTimeMSを設定すると、新しい構成を適用するに操作が失敗する可能性があります。 詳細については、「再構成により、過半数のノードがレプリカ構成をインストールするまで待機する」を参照してください。

replSetReconfigshell の メソッドを使用してrs.reconfig() を実行することもできます。

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 状態に達するまで選出されません。

新しい投票ノードがレプリカセットに追加されると、 replSetReconfigはノードの構成にnewlyAddedフィールドを内部的に追加します。 newlyAddedフィールドを持つノードは、現在の投票ノードの数にはカウントされません。 最初の同期が完了し、ノードがSECONDARY状態に達すると、 newlyAddedフィールドは自動的に削除されます。

注意

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

  • 既存のノードに newlyAdded フィールドがある場合、rs.reconfig() を使用して構成を変更しても newlyAdded フィールドは削除されません。newlyAdded フィールドは、ユーザーが提供した構成に追加されます。

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

アクセス制御を強制する配置で コマンドを実行するには、ユーザーはクラスター リソースに対するreplSetConfigure特権アクションを持っている必要があります。 adminデータベースで使用可能なclusterManager組み込みロールは、このコマンドに必要な特権を提供します。

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

警告

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

変更が正しく伝達されるようにするには、セットのノードの過半数が稼働中である必要があります。

replSetReconfigは、状況によっては、現在のプライマリの降格をtriggerできます。 プライマリがステップダウンすると選挙がトリガーされて、新しいプライマリが選出されます。

  • 新しいプライマリが選出されると、 termフィールドが増加して、新しいプライマリで行われた構成の変更と前のプライマリで行われた変更を区別します。

  • プライマリが降格しても、すべてのクライアント接続は閉じられなくなります。ただし、進行中の書込みは強制終了されます。 詳細については、「動作 」を参照してください。

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

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

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

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

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

警告

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

replSetReconfigを使用してレプリカセット ノードを削除しても、削除されたノードへの他のレプリカセット ノードからの開いている送信接続が自動的に削除されることはありません。

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

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

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

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

警告

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

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

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

戻る

replSetmaintenance