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> } )
コマンドフィールド
コマンドは、次の任意フィールドがあります。
フィールド | 説明 |
---|---|
デフォルトは 強制的に再構成すると、 | |
任意。 replSetReconfig を処理するための累積時間制限をミリ秒単位で指定します。 デフォルトでは、 replSetReconfig はレプリカ構成が大多数のレプリカセット メンバーに伝達されるまで、無期限に待機します。 maxTimeMS を設定すると、新しい構成を適用する前に操作が失敗する可能性があります。 詳細については、「再構成により、過半数のノードがレプリカ構成をインストールするまで待機する」を参照してください。 |
replSetReconfig
shell の メソッドを使用してrs.reconfig()
を実行することもできます。
動作
グローバル書込み保証 (write concern)
MongoDB 5.0 以降では、暗黙的なデフォルトの書込み保証 (write concern) を変更する構成でレプリカセットを再構成する前に、グローバルのデフォルトの書込み保証 (write concern) を明示的に設定する必要があります。グローバルのデフォルトの書込み保証 (write concern) を設定するには、setDefaultRWConcern
コマンドを使用します。
term
レプリカ構成フィールド
term
フィールドはプライマリレプリカセット メンバーによって設定されます。 term
replSetReconfig
操作で明示的に設定されている場合、プライマリは フィールドを無視します。
再構成により追加または除外できるのは一度に 1 つの投票ノードのみ
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 回、特定の書き込み操作を再試行することで、自動フェイルオーバーと選挙の組み込み処理を追加で行います。
互換性のあるドライバでは、デフォルトで再試行可能な書き込みが有効になります
実稼働クラスターへの潜在的な影響をさらに軽減するには、スケジュールされたメンテナンス期間中にのみ再構成してください。
{ force: true }
ノードを除外した後に発信接続を削除する
replSetReconfig
を使用してレプリカセット ノードを削除しても、削除されたノードへの他のレプリカセット ノードからの開いている送信接続が自動的に削除されることはありません。
デフォルトでは、レプリカセット ノードは 5 分間待機してから、除外されたノードへの接続を削除します。シャーディングされたレプリカセットでは、ShardingTaskExecutorPoolHostTimeoutMS
サーバー パラメーターを使用してこのタイムアウトを変更できます。
レプリカセットから削除されたノードへのすべての送信接続をすぐに削除するには、レプリカセット上の残りの各ノードでdropConnections
管理コマンドを実行します。
db.adminCommand( { "dropConnections" : 1, "hostAndPort" : [ "<hostname>:<port>" ] } )
<hostname>
と <port>
を除外されたノードのものに置き換えます。
警告
MongDB5.0 以降、 スプリットホライズンDNS IP アドレスのみが設定されているノードは起動時の検証に失敗し、エラーを報告します。詳しくはdisableSplitHorizonIPCheck
を参照してください。