複製

冗長性とデータ可用性

レプリケーションにより冗長性が確保でき、データの可用性が向上します。複数のデータベースサーバー上にデータのコピーを保持することで、レプリケーションは単一のデータベースサーバーが失われた場合でも、一定のフォールトトレランスを提供します。

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

MongoDB でのレプリケーション

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

プライマリ ノードはすべての書き込み操作を受け付けます。レプリカセットには、{ w: "majority" } 書き込み保証（write concern）で書き込みを確認できるプライマリが 1 つだけ存在します。ただし、状況によっては、別の mongod インスタンスが一時的に自分自身もプライマリであると認識する場合があります。[1] プライマリではデータセットに対するすべての変更を操作ログ（oplog）に記録します。プライマリ ノード操作の詳細については、「レプリカセット プライマリ」を参照してください。

クリックして拡大します

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

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

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

非同期レプリケーション

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

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

自動フェイルオーバー

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

クリックして拡大します

レプリカセットは、選挙が正常に完了するまで、書き込み (write) 操作を処理できません。プライマリがオフラインのときにセカンダリ クエリを実行するように構成されている場合、レプリカセットは引き続き読み取りクエリを処理できます。

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

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

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

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

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

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

• レプリカセットの選挙

• 再試行可能な書き込み

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

読み取り操作

読み込み設定 (read preference)

デフォルトでは、クライアントはプライマリ [1] から読み取りますが、クライアントは読み込み設定 (read preference) を指定して、読み取り操作をセカンダリに送信できます。

クリックして拡大します

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

読み取り操作を含む分散トランザクションでは、読み込み設定（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 のレプリカセット ノード」、 「非表示のレプリカセット ノード」、および「遅延レプリカセット ノード」を参照してください。