共有データ セットの最新のコピーを維持するために、レプリカ セットのセカンダリ ノードは他のノードのデータを 同期または複製します。MongoDB は、新しいノードに完全なデータ セットを入力する最初の同期と、進行中の変更をデータ セット全体に適用するレプリケーションという 2 つの形式のデータ同期を使用します。
最初の同期
最初の同期では、レプリカセットの 1 つのノードから別のノードにすべてのデータがコピーされます。最初の同期ソースの選択基準について詳しくは、「最初の同期ソースの選択」を参照してください。
localデータベースには最初の同期プロセスで使用されるoplogデータが保存されます。local最初の同期プロセスが完了するためのoplogデータベースを保存するのに十分なスペースがあることを確認します。
注意
最初の同期中に、MongoDB は宛先メンバーの oplog を切り捨てます。この oplog の切り捨ては、oplog データに依存する変更ストリームなどのプロセスに影響を与える可能性があります。
initialSyncSourceReadPreference パラメーターを使用して、優先される最初の同期ソースを指定できます。このパラメーターは、mongod を起動するときにのみ指定できます。
MongoDB 5.2 以降では、最初の同期は 論理またはファイル コピー ベースにすることができます。
注意
クラウドベースの最初の同期の曖昧さ回避
自己管理型配置の場合、最初の同期とはMongoDBがレプリカセットに新しいノードを追加するために使用するプロセスです。これは、MongoDB Atlasで利用可能なクラウドベースの最初の同期とは異なります。これは、クラウドプロバイダーのネイティブ機能を活用してソースノードのデータのスナップショットを作成し、それを新しいノードに復元します。
論理的な最初の同期プロセス
論理的な最初の同期を実行すると、MongoDB は次の処理を実行します。
ローカル データベースを除くすべてのデータベースを複製します。クローンを作成するために、
mongodは各ソース データベース内のすべてのコレクションをスキャンし、すべてのデータをこれらのコレクションの独自のコピーに挿入します。データクローンと並行して、
mongodは各コレクションのすべてのドキュメントをコピーする際に、すべてのコレクションインデックスをビルドします。データのコピー中にバッファリングされたoplogレコードを適用します。
すべての変更をデータ セットに適用します。
mongodは、ソースからの oplog を使用して、レプリカ セットの現在の状態を反映するようにデータ セットをアップデートします。
重要
1 と 2 のステップ中に、
mongodは新しく追加されたoplogレコードをプルし、localデータベースの一時コレクションに保存します。このデータ コピー ステージの実行中にこれらのoplogレコードを一時的に保存するのに十分なディスク領域がターゲット ノードのlocalデータベース内にあることを確認します。ステップ 3 と 4 では、同期ノードはソースノードに対する操作の継続性をチェックします。ギャップが見つかった場合は、最初から最初の同期を再開します。これを回避するには、プロビジョニングされるoplogのサイズが、ステップ 3 と 4 が完了するのにかかる時間をカバーするのに十分なoplog windowを提供することを確認してください。
最初の同期が完了すると、ノードは STARTUP2 から SECONDARY に移行します。
最初の同期を実行するには、「自己管理型レプリカ セットのノードの再同期 」を参照してください。
ファイル コピー ベースの最初の同期
MongoDB Enterprise でのみ使用できます。
ファイル コピー ベースの最初の同期では、ファイル システム上のファイルをコピーおよび移動することによって最初の同期プロセスを実行します。この同期方法は、論理的な最初の同期よりも高速になる可能性があります。
重要
ファイル コピー ベースの最初の同期により不正確なカウントが発生する可能性があります
ファイル コピー ベースの初期同期が完了した後、クエリ述語なしで count() メソッドを実行すると、返されるドキュメントの数が不正確になる可能性があります。
クエリ述語のない count メソッドは次のようになります: db.<collection>.count()。
詳しくは、「クエリ述語がない場合の不正確なカウント」を参照してください。
ファイル コピー ベースの最初の同期を有効にする
ファイルコピーベースの最初の同期を有効にするには、最初の同期の宛先ノードの initialSyncMethod パラメーターを fileCopyBased に設定します。このパラメーターは、起動時にのみ設定できます。
動作
ファイルのコピーによる最初の同期では、同期中にターゲット ノードの local データベースが、ソース ノードの local データベースと置き換えられます。
制限
ファイル コピー ベースの最初の同期実行中:
同期先のノードまたは同期元のノードに対してバックアップを実行することはできません。
同期先ノードの
localデータベースに書き込むことはできません。
一度に実行できる初期同期は、指定された 1 人のノードからのみです。
暗号化された storage engine を使用する場合、MongoDB はソース キーを使用して宛先を暗号化します。
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 window
oplog ウィンドウ は、セカンダリが 論理的な最初の同期プロセス の開始と終了の間に発生する新しい oplog エントリを取得できるように十分な長さにする必要があります。ウィンドウの長さが十分でない場合、セカンダリがエントリを適用する前に、一部のエントリが oplog から外れてしまうリスクがあります。
新しい oplog エントリを取得するための追加時間を考慮して、oplog のサイズを設定することをお勧めします。これにより、最初の同期に発生する可能性のある変更に対応できます。
詳しくは、「Oplog サイズ」を参照してください。
複製
セカンダリ ノードは、最初の同期後にデータを継続的に複製します。セカンダリ ノードは、同期元ソースから 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 です。
詳しくは、「フロー制御」を参照してください。
レプリケーション同期ソースの選択
レプリケーション同期ソースの選択は、レプリカセット 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の値に従います。
最初の同期ソース選択の詳細については、「 最初の同期ソースの選択 」を参照してください。