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"` がコミットした書き込みのロールバックなど、予期しない動作や望ましくない動作が発生する可能性があります。
maxTimeMS	integer	任意 `rs.reconfig()`操作を処理するための累積時間制限をミリ秒単位で指定します。デフォルトでは、 `rs.reconfig()`はレプリカ構成が大多数のレプリカセットメンバーに伝達されるまで、無期限に待機します。

既存のレプリカセットを再構成するには、まずrs.conf()を使用して現在の構成を取得し、必要に応じて構成ドキュメントを変更し、変更されたドキュメントをrs.reconfig()に渡します。

force パラメーターを使用すると、非プライマリノードに対し再構成コマンドを発行できます。

動作

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

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

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

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

再構成により追加または除外できるのは一度に 1 つの投票ノードのみ

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

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

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

`{ force: true }`

警告

rs.reconfig()と{ force: true }を併用すると、過半数がコミットした書込みのロールバックにつながる可能性があります。このオプションを使用する場合は、十分に注意を払ってください。

ノードの優先順位と投票

優先度が priority より大きいノードは、投票数も votes ではありません。
投票権のない（すなわち votes が 0 の）ノードの 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);

最初のステートメントは、rs.conf() メソッドを使用してレプリカセットの現在の構成を含むドキュメントを検索し、そのドキュメントをローカル変数 cfg に設定します。
2 番目のステートメントは、members[n].priority 値を members 配列の 2 番目のドキュメントに設定します。追加設定については、「レプリカセットの構成設定」を参照してください。
配列内のノード構成ドキュメントにアクセスするために、ステートメントはレプリカセットノードの members[n]._id フィールドではなく、配列インデックスを使用します。
最後のステートメントでは、変更された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.heartbeatTimeoutSecs が 15 に更新されます。操作はプライマリに接続された mongosh セッションを通じて発行されます。

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

Tip

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

戻る

rs.printSlaveReplicationInfo

rs.reconfigForPSASet

rs.reconfig().leafygreen-ui-m0pgrr{-webkit-align-self:center;-ms-flex-item-align:center;align-self:center;padding:0 10px;visibility:hidden;}.leafygreen-ui-a30zj9{color:#889397;vertical-align:middle;margin-top:-2px;}.css-fmznk8{margin-top:-85px;position:absolute;padding-bottom:2px;}

定義

重要