replSetReconfig

グローバル書込み保証 (write concern)

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

term レプリカ構成フィールド

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

再構成により追加または除外できるのは一度に 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フィールドは自動的に削除されます。

アクセス制御

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

ロック動作

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

混合バージョンのレプリカセット

可用性

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

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> を除外されたノードのものに置き換えます。

ノードの優先順位と投票

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

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