複製

冗長性とデータ可用性

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

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

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 秒）を超えてセットの他のノードと通信しない場合、適格なセカンダリが選挙を呼びかけ、自身を新しいプライマリに指名します。

クリックして拡大します

クラスターで新しいプライマリを選出するまでの時間の中央値は、デフォルトの replica configuration settings を前提とすると、通常 12 秒を超えることはありません。これには、プライマリを 利用不可 とマークし選挙を呼び出して完了するまでの時間も含まれます。この時間は、settings.electionTimeoutMillis レプリケーション設定オプションを変更することで調整できます。ただし、ネットワーク レイテンシなどの要因により、レプリカセット選挙が完了するまでの時間が延長される可能性があり、それによりクラスターがプライマリなしで稼働する時間が影響を受けることがあります。これらの要因は、特定のクラスター アーキテクチャに依存します。

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

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

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

MongoDB は、選出可能なセカンダリ ノードのキャッシュを最も最近アクセスされたデータを使用して事前にウォームアップするために、ミラーリングされた読み取りを提供します。セカンダリのキャッシュを事前にウォームアップすることで、選挙後のパフォーマンスをより迅速に復元できます。

MongoDB のフェイルオーバー プロセスの詳細については、以下を参照してください。

• レプリカセットの選挙

• 再試行可能な書き込み

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

読み取り操作

読み込み設定 (read preference)

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

クリックして拡大します

セカンダリへの非同期レプリケーションを実行した場合、セカンダリからの読み取りによって、プライマリのデータの状態を反映しないデータが返される可能性があります。

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

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

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

db.serverStatus( { mirroredReads: 1 } )

トランザクション

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

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

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

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

変更ストリーム

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

追加機能

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

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