replica setメンバー

原発

プライマリは、 replica set内で書き込み操作を受信する唯一のメンバーです。 MongoDB はプライマリに書き込み操作を適用し、その操作をプライマリのoplogに記録します。 セカンダリメンバーはこのログを複製し、そのデータに操作を適用します。

次の 3 つのメンバーのreplica setでは、プライマリがすべての書き込み操作を受け入れます。 次に、セカンダリはoplogを複製してデータに適用します。

クリックして拡大します

replica setのすべてのメンバーは読み取り操作を受け入れることができます。 ただし、既定では、アプリケーションは読み取り操作をプライマリ メンバーに指示します。 デフォルトの読み取り動作の変更の詳細については、「 読み取り設定 」を参照してください。

レプリカセットには、最大 1 つのプライマリを含めることができます。[1] 現在のプライマリが利用できなくなった場合、選挙によって新たなプライマリが決まります。詳細については、「レプリカセットの選挙」を参照してください。

セカンダリ

セカンダリは 、プライマリのデータセットのコピーを保持します。データを複製するために、セカンダリはプライマリのoplog の操作を非同期プロセスで自分のデータセットに適用します。 []レプリカセットには2 1 つ以上のセカンダリを含めることができます。

次の 3 メンバーのreplica setは 2 つのセカンダリ メンバーがあります。 セカンダリはプライマリのoplogを複製し、その操作をデータに適用します。

クライアントはセカンダリにデータを書き込むことはできませんが、セカンダリ メンバーからデータを読み取ることはできます。 クライアントがレプリカ セットに読み取り操作を送信する方法の詳細については、 「読み取り設定」を参照してください。

セカンダリはプライマリになることができます。 現在のプライマリが使用できなくなった場合、 replica setどのセカンダリを新しいプライマリにするかを選択する選挙を開催します。

詳細については、 replica set選挙を参照してください。

セカンダリ メンバーを特定の目的に合わせて構成できます。 セカンダリは次のように構成できます。

• 選挙でプライマリにならないようにして、セカンダリデータセンターに常駐したり、コールドスタンバイとして機能させたりできるようにします。 優先度 0 のreplica setメンバーを参照してください。

• アプリケーションがそこから読み取れないようにすることで、通常のトラフィックから分離する必要があるアプリケーションを実行できるようになります。 非表示のreplica setメンバーを参照してください。

• 意図せずに削除されたデータベースなどの特定のエラーからの回復に使用するために、実行中の「履歴」スナップショットを保持します。 遅延replica setメンバーを参照してください。

アービタ

状況によっては (プライマリとセカンダリがあるが、コストの制約により別のセカンダリを追加できない場合など)、 replica setにアービターを追加することを選択できます。 アービターはプライマリーの選挙に参加しますが、アービターはデータのコピーを持っていないため、プライマリーになることはできません。

アービターは、正確に 1 選挙票を持っています。 デフォルトでは、アービターの優先度は 0です。

アービタを追加するには、「自己管理型レプリカセットへのアービタの追加 」を参照してください。

アービターを使用する際の考慮事項については、 replica setアービター」を参照してください。