レプリカセット データの同期
共有データ セットの最新のコピーを維持するために、レプリカ セットのセカンダリ ノードは他のノードのデータを 同期または複製します。MongoDB は、新しいノードに完全なデータ セットを入力する最初の同期と、進行中の変更をデータ セット全体に適用するレプリケーションという 2 つの形式のデータ同期を使用します。
最初の同期
最初の同期では、レプリカセットの 1 つのメンバーから別のメンバーにすべてのデータがコピーされます。最初の同期ソースの選択基準の詳細については、「最初の同期ソースの選択」を参照してください。
localデータベースには最初の同期プロセスで使用されるoplogデータが保存されます。local最初の同期プロセスが完了するためのoplogデータベースを保存するのに十分なスペースがあることを確認します。
注意
最初の同期中に、MongoDB は宛先メンバーの oplog を切り捨てます。この oplog の切り捨ては、oplog データに依存する変更ストリームなどのプロセスに影響を与える可能性があります。
initialSyncSourceReadPreference パラメーターを使用して、優先される最初の同期ソースを指定できます。このパラメーターは、mongod を起動するときにのみ指定できます。
プロセス
最初の同期を実行すると、MongoDB は次の処理を実行します。
ローカル データベースを除くすべてのデータベースを複製します。クローンを作成するために、
mongodは各ソース データベース内のすべてのコレクションをスキャンし、すべてのデータをこれらのコレクションの独自のコピーに挿入します。バージョン 3.4 での変更: 最初の同期では、コレクションごとにドキュメントがコピーされる際にすべてのコレクション インデックスがビルドされます。 MongoDB の以前のバージョンでは、このステージは
_idインデックスのみがビルドされていました。バージョン3.4で変更: 最初の同期は、データコピーの間に新しく追加されたoplog レコードをプルします。 このデータ コピー ステージの実行中にこれらの oplog レコードを一時的に保存するのに十分なディスク領域がターゲット メンバーの
localデータベース内にあることを確認します。すべての変更をデータ セットに適用します。
mongodは、ソースからの oplog を使用して、レプリカ セットの現在の状態を反映するようにデータ セットをアップデートします。最初の同期が完了すると、ノードは
STARTUP2からSECONDARYに移行します。
最初の同期を実行するには、「自己管理型レプリカ セットのノードの再同期 」を参照してください。
NVMe クラスターの最初の同期
Expressのオートスケーリング を使用している場合は、ローカル 非Atlas ボリューム メモリ式（ NVMe の SSD ストレージ オプションを使用するクラスターで 最初の同期 を実行する必要があります。Atlas NVMe クラスターは、ストレージ領域の90 % がいっぱいになると、次の上位層にオートスケールします。 最初の同期は、後続の同期に比べて完了に時間がかかり、データが読み取られるプライマリのパフォーマンスが低下します。
フォールトトレランス
最初の同期を実行しているセカンダリが同期プロセス中に一時的ではない（つまり永続的な）ネットワーク エラーに遭遇した場合、セカンダリは最初の同期プロセスを最初から再開します。
最初の同期を実行しているセカンダリ ノードは、一時的な要因（つまり、一時的な）ネットワーク エラー、コレクションの削除、またはコレクションの名前変更によって中断された場合、同期プロセスの再開を試みることができます。
デフォルトでは、セカンダリによる最初の同期の再開は 24 時間試みられます。initialSyncTransientErrorRetryPeriodSeconds サーバー パラメーターを使用して、セカンダリによる最初の同期の再開の試行時間を制御できます。セカンダリによる最初の同期プロセスが設定した時間内に正常に再開できない場合、セカンダリにより、レプリカセットから正常なソースが新しく選択され、最初の同期プロセスが改めて最初から開始されます。
セカンダリは、致命的なエラーを返す前に、最初の同期の再開を最大 10 回試行します。
最初の同期ソースの選択
最初の同期ソースの選択は、 mongodスタートアップ パラメーターinitialSyncSourceReadPreferenceの値によって異なります。
initialSyncSourceReadPreferenceがprimaryに設定されている場合（chainingが無効になっている場合はデフォルト）、同期ソースとして [プライマリ] を選択します。プライマリが使用できない、またはアクセスできない場合は、エラーをログに記録し、プライマリの可用性を定期的に確認してください。initialSyncSourceReadPreferenceがprimaryPreferred（投票レプリカ セット ノードのデフォルト）に設定されている場合、同期ソースとして [プライマリ] を選択してください。プライマリが使用できない、またはアクセスできない場合は、残りのレプリカセット ノードから同期ソースを選択します。他のすべてのサポートされている読み取りモードでは、レプリカセット ノードから同期ソースを選択します。
最初の同期ソースの選択を実行するノードは、すべてのレプリカ セット ノードのリストを 2 回通過します。
メンバーは、最初のパスを実行して最初の同期ソースを選択するときに、各レプリカセットのメンバーに以下の条件を適用します。
同期ソースはオンラインかつアクセス可能でなければなりません。
initialSyncSourceReadPreferenceがsecondaryまたはsecondaryPreferredの場合、同期ソースはセカンダリである必要があります。同期ソースは
visibleである必要があります。同期ソースは、プライマリ上の最新の oplog エントリから
30秒以内である必要があります。ノードが
builds indexesする場合、同期ソースはインデックスを構築する必要があります。メンバーがレプリカセットの選挙で
votesする場合、同期ソースも投票する必要があります。メンバーが
delayed memberでない場合、同期ソースは遅延してはなりません。メンバーが
delayed memberである場合、同期ソースにはより短い遅延を設定する必要があります。同期ソースは現時点で最高の同期ソースよりも高速（低レイテンシ）でなければならなりません。
最初の試行で候補の同期ソースが残らない場合、ノードは緩やかな基準で2回目の試行を行います。「 Sync Source Selection (Second Pass)」を参照してください。
メンバーは、2 回目のパスを実行して最初の同期ソースを選択するときに、各レプリカセットのメンバーに以下の条件を適用します。
同期ソースはオンラインかつアクセス可能でなければなりません。
initialSyncSourceReadPreferenceがsecondaryの場合、同期ソースはセカンダリである必要があります。ノードが
builds indexesする場合、同期ソースはインデックスを構築する必要があります。同期ソースは現時点で最高の同期ソースよりも高速（低レイテンシ）でなければならなりません。
ノードが 2 回の通過後に最初の同期ソースを選択できない場合は、エラーがログに記録され、選択プロセスを再開する前に 1 秒間待機します。セカンダリ mongod は、エラーで終了する前に、最初の同期ソース選択プロセスを最大 10 回まで再開できます。
複製
セカンダリ ノードは、最初の同期後にデータを継続的に複製します。セカンダリ ノードは、同期元ソースから oplog をコピーし、これらの操作を非同期プロセスで適用します。[1]
セカンダリは、ping 時間や他のノードのレプリケーションの状態の変化に基づいて、必要に応じて同期元ソースを自動的に変更する場合があります。同期ソースの選択基準について詳しくは、「 レプリケーション同期ソースの選択」を参照してください。
| [1] | replica setのセカンダリ メンバーは、適用に低速操作しきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:
|
ストリーミングレプリケーション
同期元ソースは、同期元のセカンダリに oplog エントリの連続ストリームを送信します。ストリーミング レプリケーションは、高負荷および高レイテンシのネットワークでのレプリケーション ラグを軽減します。また:
セカンダリからの読み取りの古さを軽減します。
プライマリ フェイルオーバーが原因で w: 1 の書込み操作が失われるリスクを軽減します。
w: "majority"および w: >1 を使用した書き込み操作のレイテンシを軽減します（つまり、レプリケーションを待機する必要がある書込み保証）。
oplogFetcherUsesExhaust スタートアップ パラメーターを使用してストリーミング レプリケーションを無効にし、古いレプリケーション動作を使用します。同期元ソースにリソース制約がある場合、またはレプリケーション用の MongoDB のネットワーク帯域幅の使用を制限する場合にのみ、oplogFetcherUsesExhaust パラメーターを false に設定します。
マルチスレッド レプリケーション
MongoDB は、同時実行性を向上させるために、複数のスレッドを使用してバッチで書込み操作を適用します。MongoDB はドキュメント ID（WiredTiger）ごとにバッチをグループ化し、異なるスレッドを使用して各操作グループを同時に適用します。MongoDB は常に、与えられたドキュメントに書込み操作を元の書込み順で適用します。
セカンダリをターゲットし、読み取り保証レベルが "local" または "majority" に設定されている読み取り操作は、レプリケーション バッチが適用されているセカンダリで読み取りが行われる場合、データの WiredTiger スナップショットから読み取ります。
スナップショットからの読み取りにより、データの一貫したビューが保証され、ロックを必要とせずに進行中のレプリケーションと同時に読み取りを実行できるようになります。その結果、これらの読み取り懸念レベルを必要とするセカンダリ読み取りは、レプリケーション バッチが適用されるまで待機する必要がなくなり、受信時に処理できるようになります。
フロー制御
MongoDB 4.2 以降、majority
committed の遅延を設定可能な最大値 flowControlTargetLagSeconds 以下に抑えることを目的として、プライマリが書き込み (write) を適用する速度を管理者が制限することができます。
デフォルトのフロー制御は、enabled です。
注意
フロー制御を有効にするには、レプリカセットおよびシャーディングされたクラスターは、4.2 の FCV（featureCompatibilityVersion）を有し、かつ読み取り保証（read concern）がmajority enabled である必要があります。つまり、FCV が 4.2 でない場合や、読み取り保証（read concern）の過半数が無効になっている場合、フロー制御を有効にしても効果はありません。
詳しくは、「フロー制御」を参照してください。
レプリケーション同期ソースの選択
レプリケーション同期ソースの選択は、レプリカセット chaining の設定によって異なります。
チェーンが有効になっている場合（デフォルト）、レプリカセット ノードから同期ソースの選択を実行します。
チェーンが無効になっている場合は、同期ソースとして [プライマリ] を選択します。プライマリが使用できない、またはアクセスできない場合は、エラーをログに記録し、プライマリの可用性を定期的に確認してください。
レプリケーション同期ソースの選択を行うノードは、すべてのレプリカセットメンバーのリストを2回通過します。
メンバーは、レプリケーション同期ソースを最初に選択する際に、各レプリカセットのメンバーに次の基準を適用します。
同期ソースはオンラインかつアクセス可能でなければなりません。
同期ソースには、メンバーよりも新しい（同期ソースがメンバーより進んでいる） oplog エントリが必要です。
同期ソースは
visibleである必要があります。同期ソースは、プライマリ上の最新の oplog エントリから
30秒以内である必要があります。ノードが
builds indexesする場合、同期ソースはインデックスを構築する必要があります。メンバーがレプリカセットの選挙で
votesする場合、同期ソースも投票する必要があります。メンバーが
delayed memberでない場合、同期ソースは遅延してはなりません。メンバーが
delayed memberである場合、同期ソースにはより短い遅延を設定する必要があります。同期ソースは現時点で最高の同期ソースよりも高速（低レイテンシ）でなければならなりません。
1 回目のパス後に候補となる同期ソースが 1 つも残っていない場合、メンバーは緩和された基準で 2 回目のパスを実行します。「Sync Source Selection (Second Pass)」を参照してください。
メンバーは、レプリケーション同期ソースを 2 回目に選択する際に、各レプリカセットのメンバーに以下の基準を適用します。
同期ソースはオンラインかつアクセス可能でなければなりません。
ノードが
builds indexesする場合、同期ソースはインデックスを構築する必要があります。同期ソースは現時点で最高の同期ソースよりも高速（低レイテンシ）でなければならなりません。
ノードが2回の試行後に同期ソースを選択できない場合、エラーをログに記録し、1 秒待機してから選択プロセスを再起動します。
1 時間あたりにソースを変更できる回数は、maxNumSyncSourceChangesPerHour パラメーターを設定することで構成できます。
注意
最初の同期ソースを選択すると、起動パラメーターinitialSyncSourceReadPreferenceはレプリカセットのsettings.chainingAllowed設定よりも優先されます。 レプリカセット メンバーが最初の同期を正常に実行した後、レプリケーション同期ソースを選択するときに、 chainingAllowedの値に従います。
最初の同期ソース選択の詳細については、「 最初の同期ソースの選択 」を参照してください。