自己管理型レプリカセットの構成
rs.conf()
メソッドまたは replSetGetConfig
コマンドを使用して、 レプリカセットの構成にアクセスできます。
レプリカセットの構成を変更するには、rs.reconfig()
メソッドを使用して、構成ドキュメントをメソッドに渡します。詳しくは rs.reconfig()
を参照してください。
警告
MongoDB のバージョンによって検証ルールが異なる可能性があるため、異なるバージョンの MongoDB のノードを含むレプリカセットの再設定は避けてください。
レプリカセット構成ドキュメントの例
次のドキュメントは、レプリカセット構成ドキュメントの表現を示しています。お使いのレプリカセットの構成には、以下の設定の一部しか含まれていない場合があります。
{ _id: <string>, version: <int>, term: <int>, protocolVersion: <number>, writeConcernMajorityJournalDefault: <boolean>, configsvr: <boolean>, members: [ { _id: <int>, host: <string>, arbiterOnly: <boolean>, buildIndexes: <boolean>, hidden: <boolean>, priority: <number>, tags: <document>, secondaryDelaySecs: <int>, votes: <number> }, ... ], settings: { chainingAllowed : <boolean>, heartbeatIntervalMillis : <int>, heartbeatTimeoutSecs: <int>, electionTimeoutMillis : <int>, catchUpTimeoutMillis : <int>, getLastErrorModes : <document>, getLastErrorDefaults : <document>, replicaSetId: <ObjectId> } }
レプリカセット構成フィールド
_id
型: string
レプリカセットの名前です。
_id
は、replication.replSetName
またはコマンドラインでmongod
に指定された--replSet
の値と同一である必要があります。
version
タイプ: int
レプリカセット構成ドキュメントの改訂版を前の構成と区別するため、数字を 1 つずつ増やします。
レプリカセット ノードは、
term
とversion
を使用して「最新」レプリカ構成でコンテキストを実現します。 メンバーがレプリカ構成ドキュメントを比較する場合、term
が大きい構成ドキュメントが「最新」と見なされます。term
が同じか存在しない場合、より大きいversion
を含む構成ドキュメントが「最新」と見なされます。
term
タイプ: int
featureCompatibilityVersion (fCV) "4.4" またはそれ以降でのみ使用可能です。
レプリカセット構成ドキュメントの改訂版を前の構成と区別するため、数字を 1 つずつ増やします。構成ドキュメントの
term
は、再構成を実行したプライマリのレプリカセットのタームと一致します。プライマリは、選挙で選出されるたびにタームが増加します。replSetReconfig
オペレーターで明示的に設定されている場合、プライマリはterm
フィールドを無視します。強制再構成を発行すると、
term
フィールドが削除されます。 プライマリが次にreplSetReconfig
を強制なしで発行すると、term
は 独自のターム に設定されます。レプリカセット ノードは、
term
とversion
を使用して「最新」レプリカ構成でコンテキストを実現します。 メンバーがレプリカ構成ドキュメントを比較する場合、term
が大きい構成ドキュメントが「最新」と見なされます。term
が同じか存在しない場合、より大きいversion
を含む構成ドキュメントが「最新」と見なされます。
configsvr
タイプ: ブール値
デフォルト: false
レプリカセットがシャーディングされたクラスターのコンフィギュレーションサーバーに使用されるかどうかを示します。レプリカセットがシャーディングされたクラスターのコンフィギュレーションサーバー用である場合は、
true
に設定します。
protocolVersion
タイプ: 数値
デフォルト: 1
MongoDB は
protocolVersion: 1
のみをサポートし、protocolVersion: 0
はサポートしなくなりました。
writeConcernMajorityJournalDefault
タイプ: ブール値
デフォルト: true
書込み保証 (write concern) でジャーナル オプション j が明示的に指定されていない場合の、
{ w: "majority" }
書込み保証 (write concern) の動作を決定します。次の表に、
writeConcernMajorityJournalDefault
の値と、それに対応する{ w: "majority" }
の動作を示します。値{ w: "majority" }
動作true
MongoDB は、投票権を持つノードの過半数がディスク上のジャーナルに書込んだ後、書込み (write) 操作に確認応答を返します。
重要:
writeConcernMajorityJournalDefault
がtrue
の場合、投票権を持つレプリカセットの全ノードはジャーナリングを実行する必要があります。レプリカセットのいずれかの投票ノードが、インメモリ ストレージエンジンを使用している場合は、
writeConcernMajorityJournalDefault
からfalse
まで設定する必要があります。レプリカセットの投票ノードのいずれかが インメモリストレージエンジンを使用し、かつ
writeConcernMajorityJournalDefault
がtrue
である場合、"majority"
書込み操作が失敗する可能性があります。失敗する可能性がある操作には、"majority"
コマンドなど 書込み保証( 書込み保証 (write concern))replSetStepDown
を本質的に使用する操作や、 user management メソッドやmongosh
role management"majority"
メソッドなど、デフォルトで 書込み保証( 書込み保証 (write concern)) を使用するさまざまな メソッドがあります。バージョン 4.2(および 4.0.13 および 3.6.14)以降、レプリカセットのノードが、インメモリ ストレージエンジン(投票または非投票)を使用している場合に、レプリカセットで
writeConcernMajorityJournalDefault
が true に設定されている場合、レプリカセットのノードは起動時に警告をログに記録します。false
MongoDB は、投票権を持つノードの過半数がメモリ内で操作を適用した後で、書込み (write) 操作に確認応答を返します。
警告:
レプリカセットのいずれかの投票ノードが、インメモリ ストレージエンジンを使用している場合は、
writeConcernMajorityJournalDefault
からfalse
まで設定する必要があります。バージョン 4.2(および 4.0.13 および 3.6.14)以降、レプリカセットのノードが、インメモリ ストレージエンジン(投票または非投票)を使用している場合に、レプリカセットで
writeConcernMajorityJournalDefault
が true に設定されている場合、レプリカセットのノードは起動時に警告をログに記録します。シャーディングされたクラスターのうち
writeConcernMajorityJournalDefault
がfalse
に設定されているもの(インメモリ ストレージエンジンを使用する投票ノードのあるシャードなど)ではトランザクションを実行できません。
members
members
タイプ: 配列
レプリカセットの各ノードに 1 つある、ノード構成ドキュメントの配列。
members
配列は 0 から始まるインデックスの配列です。各ノード固有の構成ドキュメントには、次のフィールドを含めることができます。
members[n]._id
タイプ: 整数
レプリカセット内のノードの整数識別子です。すべてのノード間で一意です。
MongoDB 5.0 以降では、値は
0
以上の任意の整数値にできます。以前は、この値は0
から255
までの整数に制限されていました。各レプリカ セット ノードには一意の
_id
が必要です。現在の構成でmembers[n]
エントリがその_id
を使用していない場合でも、_id
の値を再利用しないでください。一度設定すると、ノードの
_id
は変更できません。
members[n].host
型: string
セットのノードのホスト名と、指定されている場合はポート番号。
ホスト名はレプリカセット内のすべてのホストで解決可能である必要があります。
警告
members[n].host
は、セットのすべてのノードがlocalhost
に変換されるホスト上にない限り、localhost
またはローカル インターフェースに変換される値を保持できません。
members[n].arbiterOnly
任意。
タイプ: ブール値
デフォルト: false
アービタを指定するブール値です。値
true
は、ノードがアービタであることを示します。rs.addArb()
メソッドを使用してアービタを追加する場合、メソッドは追加されたノードのmembers[n].arbiterOnly
をtrue
に自動的に設定します。
members[n].buildIndexes
任意。
タイプ: ブール値
デフォルト: true
mongod
がこのノードにインデックスを構築するかどうかを示すブール値です。この値は、レプリカセットにノードを追加するときにのみ設定できます。ノードがセットに追加された後は、members[n].buildIndexes
フィールドを変更できません。ノードを追加するには、rs.add()
とrs.reconfig()
を参照してください。クライアントからクエリを受信する
mongod
インスタンスの場合はfalse
に設定しないでください。次の条件がすべて当てはまる場合は、
buildIndexes
をfalse
に設定すると便利な場合があります。このインスタンスを
mongodump
を使用してバックアップを実行するためにのみ使用しているこのノードはクエリを受け取らない。
インデックスの作成とメンテナンスが、ホスト システムに過度の負担をかける。
false
に設定しても、レプリケーションに必要な操作を容易にするために、セカンダリは_id
フィールドにインデックスを構築します。警告
members[n].buildIndexes
をfalse
に設定する場合は、members[n].priority
も0
に設定する必要があります。members[n].priority
が0
でない場合、MongoDB はmembers[n].buildIndexes
がfalse
に等しいノードを追加しようとするとエラーを返します。ノードがクエリを受け取らないようにするには、インデックスを構築しないインスタンスをすべて隠ぺいする必要があります。
members[n].buildIndexes
が false であるノードから他のセカンダリを複製することはできません。
members[n].hidden
任意。
タイプ: ブール値
デフォルト: false
この値が
true
の場合、レプリカセットはこのインスタンスを隠ぺいし、db.hello()
またはhello
の出力にそのノードを含めません。こうすれば、セカンダリの読み込み設定 (read preference) によって読み取り操作(つまり、クエリ)がこのホストに到達することを防止できます。非表示ノードは、 書込み保証 (write concern ) で発行された書込み (write) 操作に確認応答を返せます。
"majority"
書込み保証(write concern)とともに発行された書込み操作の場合、ノードは投票ノードでもある必要があります(votes
は0
より大きいです)。
members[n].priority
任意。
型: プライマリまたはセカンダリの場合は 0 ~ 1000 の数値、アービタの場合は 0 または 1 の数値。
デフォルト: プライマリまたはセカンダリの場合は 1.0、アービタの場合は 0。
レプリカセットがプライマリになる相対的な可能性を示す数値。
ノードがプライマリになる可能性を高めるには、そのノードの
priority
値を高く指定します。ノードがプライマリになる可能性を減らすには、そのノードの
priority
値を低く指定します。
ノードの優先順位を変更すると、1 つ以上の選挙がトリガーされます。選挙アルゴリズムは、最も優先順位が高いノードをプライマリに選出するために最善を尽くします。しかし、優先順位の高いセカンダリが使用できる場合でも、優先順位の低いノードがプライマリになる場合があります。
優先順位の低いノードがプライマリになると、サーバーは最も優先順位の高いレプリカセットがプライマリになるまで、定期的に選挙を呼び出します。選挙が行われる頻度は、選出されたノードと最も優先順位の高いノードとの間の優先順位の違いによって決まります。
優先順位が
0
のノードがプライマリになることはできません。投票権のないノード(つまり、
votes
が0
に設定されているノード)の優先順位は0
である必要があります。
members[n].tags
任意。
型: ドキュメント
デフォルト: なし
tags
ドキュメントには、レプリカセットのユーザー定義タグ フィールドと値のペアが含まれています。{ "<tag1>": "<string1>", "<tag2>": "<string2>",... } 読み取り操作では、読み込み設定 (read preference) でタグセットを指定して、指定したタグを持つレプリカセットに操作を指示できます。
書込み操作では、 と
settings.getLastErrorModes
を使用してカスタマイズされた 書込み保証settings.getLastErrorDefaults
を作成できます。
詳しくは、「レプリカセットのタグセットの構成」を参照してください。
members[n].secondaryDelaySecs
任意。
タイプ: 整数
デフォルト: 0
このレプリカセットがプライマリから "遅れる" 秒数。
遅延ノードを作成するにはこのオプションを使用します。遅延ノードは、過去のある時点におけるデータの状態を反映したデータのコピーを保持します。
遅延ノードは、 書込み保証 (write concern ) 付きで発行された書込み (write) 操作の確認に貢献できます。 ただし、設定された遅延値よりも早く書込み (write) 確認応答が返されることはありません。
"majority"
書込み保証(write concern)とともに発行された書込み操作の場合、ノードは投票ノードでもある必要があります(votes
は0
より大きいです)。
members[n].votes
任意。
タイプ: 整数
デフォルト: 1
レプリカセット選挙においてサーバーが投じる投票数です。各ノードが持つ投票数は
1
または0
で、アービタ は常にちょうど1
票を持ちます。が より大きいメンバーは、
priority
00votes
を使用できません。レプリカセットには最大50メンバーを含めることができますが、投票メンバーは7メンバーのみです。 1 つのレプリカセットに7を超えるノードが必要な場合は、追加の投票権のないノードのために
members[n].votes
から0
を設定します。投票権のない(すなわち
votes
は0
です)メンバーは、 0のpriority
を持っている必要があります。MongoDB 5.0 以降では、新しく追加されたセカンダリは投票権のあるノードとしてカウントされず、
SECONDARY
状態に達するまで選出されません。投票権のないノードは、
"majority"
書込み保証 (write concern) 付きで発行された書込み (write) 操作に確認応答できません。
settings
settings
任意。
型: ドキュメント
レプリカセット全体に適用される構成オプションを含むドキュメントです。
settings
ドキュメントには次のフィールドが含まれています。settings.chainingAllowed
任意。
タイプ: ブール値
デフォルト: true
MongoDB 5.0.1以前で、
settings.chainingAllowed
が次の場合。MongoDB 5.0.2 以降
レプリカセットのセカンダリメンバーは、
settings.chainingAllowed
がfalse
であっても、他のセカンダリ メンバーからデータを複製できます。settings.chainingAllowed
を上書きするには、enableOverrideClusterChainingSetting
サーバー パラメータをtrue
に設定します。enableOverrideClusterChainingSetting
のデフォルトはfalse
です。
settings.getLastErrorDefaults
任意。
型: ドキュメント
MongoDB 5.0 以降では使用できません。
重要
MongoDB 5.0以降では、デフォルトの
{ w: 1, wtimeout: 0 }
以外のsettings.getLastErrorDefaults
でデフォルトの書込み保証 (write concern) を指定することはできません。 代わりに、setDefaultRWConcern
コマンドを使用して、レプリカセットまたはシャーディングされたクラスターのデフォルトの読み取りまたは書込み保証 (write concern) を設定します。
settings.getLastErrorModes
任意。
型: ドキュメント
members[n].tags
の使用を通じて書込み保証を定義するために使用されるドキュメント。カスタム書込み保証により、データセンターの認識ができます。{ getLastErrorModes: { <name of write concern> : { <tag1>: <number>, .... }, ... } } <number>
は、書き込み保証を満たすために必要な異なるタグの値の数を示します。たとえば、次のsettings.getLastErrorModes
は、dc
タグの値が異なる 2 つのノードに書き込みを伝播することを要求するdatacenter
という名前の書き込み保証を定義します。{ getLastErrorModes: { datacenter: { "dc": 2 } } } カスタム書込み保証 (write concern) を使用するには、
w
オプションに書込み保証 (write concern) の名前を渡します。例を以下に示します。{ w: "datacenter" } 詳細と例については、「レプリカセットのタグセットの構成」を参照してください。
settings.heartbeatTimeoutSecs
任意。
タイプ: int
デフォルト: 10
レプリカセットがお互いのハートビートが成功するまで待つ秒数です。あるノードが時間内に応答しない場合、他のノードは期限を過ぎたそのノードをアクセス不可としてマークします。
settings.electionTimeoutMillis
任意。
タイプ: int
デフォルト: 10000(10 秒)
レプリカセットのプライマリが到達不能なときを検出するための時間制限(ミリ秒単位)。 この設定は、
protocolVersion: 1
を使用する場合のフェイルオーバーの区別を制御します。 フェイルオーバー タイムアウトはelectionTimeoutMillis
の値を超えないことが予想されます。値を選択する際には、次の点を考慮してください。
値が大きいほどフェイルオーバーは遅くなりますが、プライマリ ノードやネットワークの速度低下やむらの影響を受けにくくなります。
値が小さいほどフェイルオーバーは速くなりますが、プライマリ ノードやネットワークの速度低下やむらの影響を受けやすくなります。
この設定は
protocolVersion: 1
を使用する場合にのみ適用されます。注意
force
フィールドをtrue
に設定せずにrs.stepDown()
またはreplSetStepDown
を使用してプライマリを降格すると、降格したプライマリは、選挙を直ちに呼び出す資格のあるセカンダリを指名します。
settings.catchUpTimeoutMillis
任意。
タイプ: int
デフォルト: -1、キャッチアップ時間は無限。
新たに選出されたプライマリが、より新しい書込み (write) を行った可能性のある他のレプリカセットと同期(キャッチアップ)するまでの時間制限(ミリ秒単位)です。時間制限が無限の場合や長い場合には、選挙後に他のノードがロールバックする必要のあるデータ量は減りますが、フェイルオーバー時間は長くなる可能性があります。
新たに選出されたプライマリは、セットの他のノードに完全に追いつくと、キャッチアップ期間を早く終了します。キャッチアップ期間中は、新しく選出されたプライマリはクライアントからの書込み (write) に対応できません。キャッチアップを中止してプライマリへの移行を完了するには、
replSetAbortPrimaryCatchUp
を使用します。この設定は
protocolVersion: 1
を使用する場合にのみ適用されます。
settings.catchUpTakeoverDelayMillis
任意。
タイプ: int
デフォルト: 30000(30 秒)
ノードが現在のプライマリよりも進んでいると判断した後、キャッチアップ引き継ぎの開始を待つ時間(ミリ秒単位)です。キャッチアップ引き継ぎ中、現在のプライマリの進んだノードがレプリカセットの新しいプライマリになるための選挙を開始します。
引き継ぎを開始したノードが現在のプライマリよりも先行していると判断した後、指定されたミリ秒数待機してから、次のことを確認します。
まだ現在のプライマリよりも進んでいること
利用可能な全ノードの中で最新のノードであること
現在のプライマリが現在、そのノードをキャッチアップしていること
これらの条件をすべて満たしていると判断すると、引き継ぎを開始したノードは直ちに選挙に立候補します。
レプリカセット選挙の詳細については、「レプリカセット選挙」を参照してください。
注意
catchUpTakeoverDelayMillis
を-1
に設定すると、キャッチアップ引き継ぎが無効になります。catchUpTimeoutMillis
を0
に設定すると、プライマリのキャッチアップが無効になり、キャッチアップの引き継ぎも無効になります。
settings.replicaSetId
型: ObjectId
レプリカセットに関連付けられ、
rs.initiate()
またはreplSetInitiate
中に自動的に作成された ObjectId 。replicaSetId
は変更できません。