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

自己管理型レプリカセットの構成

項目一覧

  • レプリカセット構成ドキュメントの例
  • レプリカセット構成フィールド

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 の値と同一である必要があります

Tip

次を参照してください。

レプリカセット名の設定については、replSetName または --replSet を参照してください。

version

タイプ: int

レプリカセット構成ドキュメントの改訂版を前の構成と区別するため、数字を 1 つずつ増やします。

レプリカセット ノードは、 termversionを使用して「最新」レプリカ構成でコンテキストを実現します。 メンバーがレプリカ構成ドキュメントを比較する場合、 termが大きい構成ドキュメントが「最新」と見なされます。 termが同じか存在しない場合、より大きいversionを含む構成ドキュメントが「最新」と見なされます。

term

タイプ: int

featureCompatibilityVersion (fCV) "4.4" またはそれ以降でのみ使用可能です。

レプリカセット構成ドキュメントの改訂版を前の構成と区別するため、数字を 1 つずつ増やします。構成ドキュメントの term は、再構成を実行したプライマリのレプリカセットのタームと一致します。プライマリは、選挙で選出されるたびにタームが増加します。replSetReconfig オペレーターで明示的に設定されている場合、プライマリは term フィールドを無視します。

強制再構成を発行すると、 termフィールドが削除されます。 プライマリが次にreplSetReconfigを強制なしで発行すると、 termは 独自のターム に設定されます。

レプリカセット ノードは、 termversionを使用して「最新」レプリカ構成でコンテキストを実現します。 メンバーがレプリカ構成ドキュメントを比較する場合、 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) 操作に確認応答を返します。

重要: writeConcernMajorityJournalDefaulttrue の場合、投票権を持つレプリカセットの全ノードはジャーナリングを実行する必要があります。

レプリカセットのいずれかの投票ノードが、インメモリ ストレージエンジンを使用している場合は、writeConcernMajorityJournalDefault から false まで設定する必要があります。

レプリカセットの投票ノードのいずれかが インメモリストレージエンジンを使用し、かつ writeConcernMajorityJournalDefaulttrue である場合、"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 に設定されている場合、レプリカセットのノードは起動時に警告をログに記録します。

シャーディングされたクラスターのうち writeConcernMajorityJournalDefaultfalse に設定されているもの(インメモリ ストレージエンジンを使用する投票ノードのあるシャードなど)ではトランザクションを実行できません。

Tip

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

members

タイプ: 配列

レプリカセットの各ノードに 1 つある、ノード構成ドキュメントの配列。members 配列は 0 から始まるインデックスの配列です。

各ノード固有の構成ドキュメントには、次のフィールドを含めることができます。

members[n]._id

タイプ: 整数

レプリカセット内のノードの整数識別子です。すべてのノード間で一意です。

MongoDB 5.0 以降では、値は 0 以上の任意の整数値にできます。以前は、この値は 0 から 255 までの整数に制限されていました。

各レプリカ セット ノードには一意の _id が必要です。現在の構成で members[n] エントリがその _id使用していない場合でも_id の値を再利用しないでください。

一度設定すると、ノードの _id は変更できません。

注意

レプリカ構成オブジェクトを更新するときは、members 配列インデックス を使用して 配列内のレプリカセット メンバーにアクセスします。配列インデックスは0で始まります。 このインデックス値を、 members配列内の各ドキュメントのmembers[n]._idフィールドの値と混同 しないでください 。

members[n].host

: string

セットのノードのホスト名と、指定されている場合はポート番号。

ホスト名はレプリカセット内のすべてのホストで解決可能である必要があります。

警告

members[n].host は、セットのすべてのノードが localhost に変換されるホスト上にない限り、localhost またはローカル インターフェースに変換される値を保持できません。

members[n].arbiterOnly

任意

タイプ: ブール値

デフォルト: false

アービタを指定するブール値です。値 true は、ノードがアービタであることを示します。

rs.addArb()メソッドを使用してアービタを追加する場合、メソッドは追加されたノードのmembers[n].arbiterOnlytrueに自動的に設定します。

members[n].buildIndexes

任意

タイプ: ブール値

デフォルト: true

mongod がこのノードにインデックスを構築するかどうかを示すブール値です。この値は、レプリカセットにノードを追加するときにのみ設定できます。ノードがセットに追加された後は、 members[n].buildIndexes フィールドを変更できません。ノードを追加するには、 rs.add()rs.reconfig() を参照してください。

クライアントからクエリを受信する mongod インスタンスの場合は false に設定しないでください。

次の条件がすべて当てはまる場合は、buildIndexesfalse に設定すると便利な場合があります。

  • このインスタンスを mongodump を使用してバックアップを実行するためにのみ使用している

  • このノードはクエリを受け取らない。

  • インデックスの作成とメンテナンスが、ホスト システムに過度の負担をかける。

false に設定しても、レプリケーションに必要な操作を容易にするために、セカンダリは _id フィールドにインデックスを構築します。

警告

members[n].buildIndexesfalse に設定する場合は、 members[n].priority0 に設定する必要があります。members[n].priority0 でない場合、MongoDB は members[n].buildIndexesfalse に等しいノードを追加しようとするとエラーを返します。

ノードがクエリを受け取らないようにするには、インデックスを構築しないインスタンスをすべて隠ぺいする必要があります。

members[n].buildIndexes が false であるノードから他のセカンダリを複製することはできません。

members[n].hidden

任意

タイプ: ブール値

デフォルト: false

この値が true の場合、レプリカセットはこのインスタンスを隠ぺいし、db.hello() または hello の出力にそのノードを含めません。こうすれば、セカンダリの読み込み設定 (read preference) によって読み取り操作(つまり、クエリ)がこのホストに到達することを防止できます。

非表示ノードは、 書込み保証 (write concern ) で発行された書込み (write) 操作に確認応答を返せます。 "majority"書込み保証(write concern)とともに発行された書込み操作の場合、ノードは投票ノードでもある必要があります( votes0より大きいです)。

Tip

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

members[n].priority

任意

: プライマリまたはセカンダリの場合は 0 ~ 1000 の数値、アービタの場合は 0 または 1 の数値。

デフォルト: プライマリまたはセカンダリの場合は 1.0、アービタの場合は 0。

レプリカセットがプライマリになる相対的な可能性を示す数値。

  • ノードがプライマリになる可能性を高めるには、そのノードの priority 値を高く指定します。

  • ノードがプライマリになる可能性を減らすには、そのノードの priority 値を低く指定します。

ノードの優先順位を変更すると、1 つ以上の選挙がトリガーされます。選挙アルゴリズムは、最も優先順位が高いノードをプライマリに選出するために最善を尽くします。しかし、優先順位の高いセカンダリが使用できる場合でも、優先順位の低いノードがプライマリになる場合があります。

優先順位の低いノードがプライマリになると、サーバーは最も優先順位の高いレプリカセットがプライマリになるまで、定期的に選挙を呼び出します。選挙が行われる頻度は、選出されたノードと最も優先順位の高いノードとの間の優先順位の違いによって決まります。

優先順位が 0 のノードがプライマリになることはできません。

投票権のないノード(つまり、votes0 に設定されているノード)の優先順位は0 である必要があります。

Tip

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

members[n].tags

任意

: ドキュメント

デフォルト: なし

tags ドキュメントには、レプリカセットのユーザー定義タグ フィールドと値のペアが含まれています。

{ "<tag1>": "<string1>", "<tag2>": "<string2>",... }

詳しくは、「レプリカセットのタグセットの構成」を参照してください。

members[n].secondaryDelaySecs

任意

タイプ: 整数

デフォルト: 0

このレプリカセットがプライマリから "遅れる" 秒数。

遅延ノードを作成するにはこのオプションを使用します。遅延ノードは、過去のある時点におけるデータの状態を反映したデータのコピーを保持します。

遅延ノードは、 書込み保証 (write concern ) 付きで発行された書込み (write) 操作の確認に貢献できます。 ただし、設定された遅延値よりも早く書込み (write) 確認応答が返されることはありません。 "majority"書込み保証(write concern)とともに発行された書込み操作の場合、ノードは投票ノードでもある必要があります( votes0より大きいです)。

Tip

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

members[n].votes

任意

タイプ: 整数

デフォルト: 1

レプリカセット選挙においてサーバーが投じる投票数です。各ノードが持つ投票数は 1 または 0 で、アービタ は常にちょうど 1 票を持ちます。

が より大きいメンバーは、priority 00votesを使用できません。

レプリカセットには最大50メンバーを含めることができますが、投票メンバーは7メンバーのみです。 1 つのレプリカセットに7を超えるノードが必要な場合は、追加の投票権のないノードのためにmembers[n].votesから0を設定します。

投票権のない(すなわち votes0です)メンバーは、 0のpriorityを持っている必要があります。

MongoDB 5.0 以降では、新しく追加されたセカンダリは投票権のあるノードとしてカウントされず、SECONDARY 状態に達するまで選出されません。

投票権のないノードは、"majority" 書込み保証 (write concern) 付きで発行された書込み (write) 操作に確認応答できません。

settings

任意

: ドキュメント

レプリカセット全体に適用される構成オプションを含むドキュメントです。

settingsドキュメントには次のフィールドが含まれています。

settings.chainingAllowed

任意

タイプ: ブール値

デフォルト: true

MongoDB 5.0.1以前で、 settings.chainingAllowedが次の場合。

  • true: レプリカセットのセカンダリ ノードは、他のセカンダリ ノードからデータを複製できます。

  • false: セカンダリ ノードはプライマリからのみデータを複製できます。

MongoDB 5.0.2 以降

Tip

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

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 秒)

ノードが現在のプライマリよりも進んでいると判断した後、キャッチアップ引き継ぎの開始を待つ時間(ミリ秒単位)です。キャッチアップ引き継ぎ中、現在のプライマリの進んだノードがレプリカセットの新しいプライマリになるための選挙を開始します。

引き継ぎを開始したノードが現在のプライマリよりも先行していると判断した後、指定されたミリ秒数待機してから、次のことを確認します。

  1. まだ現在のプライマリよりも進んでいること

  2. 利用可能な全ノードの中で最新のノードであること

  3. 現在のプライマリが現在、そのノードをキャッチアップしていること

これらの条件をすべて満たしていると判断すると、引き継ぎを開始したノードは直ちに選挙に立候補します。

レプリカセット選挙の詳細については、「レプリカセット選挙」を参照してください。

注意

catchUpTakeoverDelayMillis-1 に設定すると、キャッチアップ引き継ぎが無効になります。catchUpTimeoutMillis0 に設定すると、プライマリのキャッチアップが無効になり、キャッチアップの引き継ぎも無効になります。

settings.heartbeatIntervalMillis

内部でのみ使用します

ハートビートの頻度(ミリ秒単位)。

settings.replicaSetId

: ObjectId

レプリカセットに関連付けられ、 rs.initiate()またはreplSetInitiate中に自動的に作成された ObjectId 。 replicaSetIdは変更できません。

戻る

参照