replica setメンバー
MongoDB のレプリカセットは、冗長性と高可用性を提供する mongod プロセスのグループです。レプリカセットのノードには以下のタイプがあります。
- 原発
- プライマリは、すべての書き込み操作を受け取ります。
- セカンダリ
- セカンダリはプライマリからの操作を複製して、同一のデータ設定を維持します。 セカンダリには、特別な使用プロファイル用の追加の構成がある場合があります。 たとえば、セカンダリは 投票なし または 優先度 0 である可能性があります。
replica setreplica setの最小推奨構成は、3 つのデータ保持メンバー (1 つの プライマリ メンバーと 2 つの セカンダリ メンバー) を含む 3 メンバー です。状況によっては (プライマリとセカンダリがあるが、コストの制約により別のセカンダリの追加が禁止されている場合など)、 アービターを含めることを選択できます。 アービターは 選挙 に参加しますが、データを保持しません(つまり、 データの冗長性は提供されません)。
replica set最大 50 のメンバーを含めることができますが、投票メンバーは 7 人だけです。
原発
プライマリは、 replica set内で書き込み操作を受信する唯一のメンバーです。 MongoDB はプライマリに書き込み操作を適用し、その操作をプライマリのoplogに記録します。 セカンダリメンバーはこのログを複製し、そのデータに操作を適用します。
次の 3 つのメンバーのreplica setでは、プライマリがすべての書き込み操作を受け入れます。 次に、セカンダリはoplogを複製してデータに適用します。
replica setのすべてのメンバーは読み取り操作を受け入れることができます。 ただし、既定では、アプリケーションは読み取り操作をプライマリ メンバーに指示します。 デフォルトの読み取り動作の変更の詳細については、「 読み取り設定 」を参照してください。
replica set最大 1 つのプライマリを含めることができます。 [2] 現在のプライマリが使用できなくなった場合、選挙によって新しいプライマリが決定されます。 詳細については、 replica set選挙を参照してください。
セカンダリ
セカンダリはプライマリのデータのコピーを保持します。 データを複製するために、セカンダリはプライマリのoplogからの操作を非同期プロセスで自身のデータに適用します。 [1] replica set 1つ以上のセカンダリを含めることができます。
次の 3 メンバーのreplica setは 2 つのセカンダリ メンバーがあります。 セカンダリはプライマリのoplogを複製し、その操作をデータに適用します。
クライアントはセカンダリにデータを書き込むことはできませんが、セカンダリ メンバーからデータを読み取ることはできます。 クライアントがレプリカ セットに読み取り操作を送信する方法の詳細については、 「読み取り設定」を参照してください。
セカンダリはプライマリになることができます。 現在のプライマリが使用できなくなった場合、 replica setどのセカンダリを新しいプライマリにするかを選択する選挙を開催します。
詳細については、 replica set選挙を参照してください。
セカンダリ メンバーを特定の目的に合わせて構成できます。 セカンダリは次のように構成できます。
選挙でプライマリにならないようにして、セカンダリデータセンターに常駐したり、コールドスタンバイとして機能させたりできるようにします。 優先度 0 のreplica setメンバーを参照してください。
アプリケーションがそこから読み取れないようにすることで、通常のトラフィックから分離する必要があるアプリケーションを実行できるようになります。 非表示のreplica setメンバーを参照してください。
意図せずに削除されたデータベースなどの特定のエラーからの回復に使用するために、実行中の「履歴」スナップショットを保持します。 遅延replica setメンバーを参照してください。
| [1] | replica setのセカンダリ メンバーは、適用に低速操作しきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:
|
アービタ
状況によっては (プライマリとセカンダリがあるが、コストの制約により別のセカンダリを追加できない場合など)、 replica setにアービターを追加することを選択できます。 アービターはプライマリーの選挙に参加しますが、アービターはデータのコピーを持っていないため、プライマリーになることはできません。
アービターは、正確に 1 選挙票を持っています。 デフォルトでは、アービターの優先度は 0です。
重要
replica setのプライマリ メンバーまたはセカンダリ メンバーもホストするシステムでは、アービターを実行しないでください。
警告
シャーディングされたシャーディングされたクラスターのシャードにプライマリとセカンダリのアービタ（PSA）アーキテクチャを使用すると、データを保持するセカンダリが使用できない場合に可用性が失われる可能性があります。 PSA クラスターは、通常のレプリカセットとは異なります。 シャーディングされたシャーディングされたクラスターでは、シャードはw: majority書込み保証（ 書込み保証 (write concern) ）操作を実行しますが、この操作を確認するために必要な残りのクラスター ノードにアービタがある場合は完了できません。
アービタを追加するには、「自己管理型レプリカセットへのアービタの追加 」を参照してください。
アービターを使用する際の考慮事項については、 replica setアービター」を参照してください。
| [2] | 状況によっては、 replica set内の 2 つのノードが一時的に自分たちがプライマリであると認識することがありますが、最大でそのうちの 1 つが{ w:
"majority" }書き込み懸念で書き込みを完了できます。 { w: "majority" }書き込みを完了できるノードは現在のプライマリであり、もう一方のノードは、通常はネットワークパーティションが原因で降格をまだ認識していない以前のプライマリです。これが発生すると、以前のプライマリに接続するクライアントは、読み取り設定primaryを要求したにもかかわらず、古いデータを検出する可能性があり、以前のプライマリへの新しい書き込みは最終的にロールバックされます。 |