複製

冗長性とデータ可用性

レプリケーションは、複数のデータベース サーバーにデータのコピーを保持することで、単一サーバーの障害に対応できる冗長性とデータの可用性を提供します。

場合によっては、クライアントが読み取り操作を別のサーバーに送信できるため、レプリケーションによって読み取りキャパシティーを増大することができます。異なるデータセンターにデータのコピーを保持することで、分散アプリケーションのためのデータローカリティと可用性を高めることができます。また、ディザスタリカバリ、レポート作成、バックアップなどの専用目的で追加のコピーを保持することもできます。

MongoDB でのレプリケーション

レプリカセットは、同じデータセットを保持する mongod インスタンスのグループです。レプリカセットには、データを保持する複数のノードと、オプションとして 1 つのアービタ ノードが含まれます。データを保持するノードのうち、1 つのノードだけがプライマリノードと見なされ、他のノードはセカンダリノードと見なされます。

The primary node receives all write operations. A replica set can have only one primary capable of confirming writes with { w: "majority" } write concern, although in some circumstances, another mongod instance may transiently believe itself to also be primary. [1] The primary records all changes to its data sets in its operation log, that is, the oplog. For more information on primary node operation, see Replica Set Primary.

クリックして拡大します

セカンダリではプライマリの oplog を複製し、セカンダリのデータセットにプライマリのデータセットを反映するように操作をデータセットに適用します。プライマリが利用できない場合は、資格のあるセカンダリが選挙を行い、自分自身を新しいプライマリに選出します。セカンダリ ノードの詳細については、「レプリカセットのセカンダリ ノード」を参照してください。

コスト上の制約によりセカンダリを追加できない場合は、レプリカセットにmongod インスタンスをアービタとして追加できます。アービタは選挙に参加しますが、データを保持しません（つまり、データの冗長性を提供しません）。アービタの詳細については、「レプリカセット アービタ」を参照してください。

アービタは常にアービタであり続けますが、選挙中にプライマリが格下げしてセカンダリになったり、セカンダリがプライマリになったりすることもあります。

非同期レプリケーション

セカンダリはプライマリの oplog を複製し、非同期にデータセットに操作を適用します。セカンダリのデータセットにプライマリのデータセットを反映させることで、1 つ以上のノードに障害が発生しても、レプリカセットは機能し続けることができます。

レプリケーションの仕組みの詳細については、「レプリカセット Oplog」および「レプリカセット データ同期」を参照してください。

自動フェイルオーバー

プライマリが、設定された electionTimeoutMillis 時間（デフォルトは 10 秒）を超えてセットの他のノードと通信しない場合、適格なセカンダリが選挙を呼びかけ、自身を新しいプライマリに指名します。

クリックして拡大します

The median time before a cluster elects a new primary should not typically exceed 12 seconds, assuming default replica configuration settings. This includes time required to mark the primary as unavailable and call and complete an election. You can tune this time period by modifying the settings.electionTimeoutMillis replication configuration option. Factors such as network latency may extend the time required for replica set elections to complete, which in turn affects the amount of time your cluster may operate without a primary. These factors are dependent on your particular cluster architecture.

electionTimeoutMillis のレプリケーション設定オプションをデフォルトの 10000（10 秒）から下げると、プライマリ障害をより早く検出できるようになります。ただし、プライマリが正常であっても、一時的なネットワーク レイテンシなどの要因により、クラスターがより頻繁に選挙を呼び出すことがあります。これにより、w : 1 書き込み (write) 操作のロールバックが増加する可能性があります。

アプリケーション接続ロジックには、自動フェールオーバーとその後の選挙に対する許容範囲が含まれている必要があります。MongoDB ドライバーはプライマリの損失を検出し、自動的に 1 回、特定の書き込み操作を再試行することで、自動フェイルオーバーと選挙の組み込み処理を追加で行います。

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

MongoDB provides mirrored reads to pre-warm electable secondary members' cache with the most recently accessed data. Pre-warming the cache of a secondary can help restore performance more quickly after an election.

MongoDB のフェイルオーバーの詳細な手順については、以下を参照してください。

• レプリカセットの選挙

• 再試行可能な書き込み

• レプリカセットのフェイルオーバー中のロールバック

読み取り操作

読み込み設定 (read preference)

By default, clients read from the primary [1]; however, clients can specify a read preference to send read operations to secondaries.

クリックして拡大します

Asynchronous replication to secondaries means that reads from secondaries may return data that does not reflect the state of the data on the primary.

読み取り操作を含むトランザクションでは、読み込み設定 (read preference) primary を使用する必要があります。特定のトランザクション内のすべての操作は、同じノードにルーティングする必要があります。

レプリカセットからの読み取りについては、「読み込み設定 (read preference)」を参照してください。

db.adminCommand( {
  setParameter: 1,
  mirrorReads: { samplingRate: 0.0 }
} )

db.serverStatus( { mirroredReads: 1 } )

トランザクション

レプリカセットではマルチドキュメントトランザクションが利用できます。

読み取り操作を含むトランザクションでは、読み込み設定 (read preference) primary を使用する必要があります。特定のトランザクション内のすべての操作は、同じノードにルーティングする必要があります。

トランザクションがコミットされるまで、トランザクションで行われたデータ変更はトランザクションの外部には表示されません。

ただし、トランザクションが複数のシャードに書き込む場合、すべての外部読み取り操作が、コミットされたトランザクションの結果がシャード全体で表示されるまで待機する必要はありません。たとえば、トランザクションがコミットされ、書込み 1 がシャード A で表示されているものの、書込み 2 がシャード B にまだ表示されていない場合、読み取り保証（read concern） "local" での外部読み取りは、書き込み 2 を見ることなく書き込み 1 の結果を読み取ることができます。

変更ストリーム

変更ストリームは、 レプリカセット と シャーディングされたクラスター で使用できます。 ストリーム変更を使用すると、oplog を追尾する複雑さやリスクなく、アプリケーションがリアルタイムデータの変更にアクセスできます。 アプリケーションはストリーム変更を使用して、1 つまたは複数のコレクションのすべてのデータ変更をサブスクライブできます。

追加機能

レプリカセットは、アプリケーションのニーズをサポートするためのさまざまなオプションを提供します。たとえば、複数のデータセンターのノードを持つレプリカセットを配置したり、一部のノードの members[n].priority を調整して選挙の結果を制御したりできます。レプリカセットでは、レポート作成、障害復旧、またはバックアップ機能専用のノードもサポートします。

詳細については、「優先順位 0 のレプリカセット ノード」、 「非表示のレプリカセット ノード」、および「遅延レプリカセット ノード」を参照してください。