共有データセットの最新のコピーを維持するために、レプリカセットのセカンダリ ノードはソース ノードからデータを同期または複製します。 MongoDB は、新しいメンバーに完全なデータ セットを入力する最初の同期と、進行中の変更をデータ セット全体に適用するレプリケーションという 2 つの形式のデータ同期を使用します。
最初の同期
最初の同期では、レプリカセットのソース メンバーのすべてのデータが宛先メンバーにコピーされます。 ソース ノードの選択基準について詳しくは、「最初の同期ソースの選択」を参照してください。
localデータベースには最初の同期プロセスで使用されるoplogデータが保存されています。local最初の同期プロセスが完了するためのoplogデータベースを保存するのに十分なスペースがあることを確認します。
注意
最初の同期中に、 MongoDB は宛先メンバーのoplogを切り捨てます。このoplog の切り捨ては、 変更ストリーム や Atlas Stream Processing チェックポイントなどの、 oplogデータに依存するプロセスに影響可能性があります。
initialSyncSourceReadPreference パラメーターを使用して、優先される最初の同期ソースを指定できます。このパラメーターは、mongod を起動するときにのみ指定できます。
MongoDB 5.2 以降では、最初の同期は 論理またはファイル コピー ベースにすることができます。
注意
クラウドベースの最初の同期の曖昧さ回避
自己管理型配置の場合、最初の同期とはMongoDBがレプリカセットに新しいノードを追加するために使用するプロセスです。これは、MongoDB Atlasで利用可能なクラウドベースの最初の同期とは異なります。これは、クラウドプロバイダーのネイティブ機能を活用してソースノードのデータのスナップショットを作成し、それを新しいノードに復元します。
論理的な最初の同期プロセス
論理的な最初の同期を実行すると、MongoDB は次の処理を実行します。
データクローンと並行して、
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 クラスターの最初の同期
Atlas のオートスケーリングを使用している場合は、ローカル 非容量メモリExpress（ NVMe ）のSSDストレージオプションを使用するクラスターで最初の同期 を実行する必要があります。 Atlas NVMe90 クラスターは、ストレージ領域の % がいっぱいになると、次の上位層にオートスケールします。最初の同期は、後続の同期に比べて完了に時間がかかり、データが読み取られるプライマリのパフォーマンスが低下します。
フォールトトレランス
最初の同期を実行している宛先メンバーが同期プロセス中に永続的なネットワークエラーに遭遇した場合、宛先メンバーは最初から同期プロセスを再開します。
最初の同期を実行している宛先ノードは、一時的なネットワークエラー、コレクションの削除、またはコレクションの名前変更によって中断された場合、同期プロセスの再開を試みることができます。
デフォルトでは、宛先メンバーは24時間最初の同期の再開を試みます。 initialSyncTransientErrorRetryPeriodSecondsサーバー パラメータを使用して、宛先メンバーによる最初の同期の再開の試行時間を制御できます。 設定された期間中に宛先メンバーが最初の同期プロセスを正常に再開できない場合は、レプリカセットから新しい正常なソース メンバーを選択し、最初から同期プロセスを再開します。
セカンダリは、致命的なエラーを返す前に、最初の同期の再開を最大 10 回試行します。
最初の同期ソースの選択
最初の同期ソースの選択は、 mongodスタートアップ パラメーターinitialSyncSourceReadPreferenceの値によって異なります。
initialSyncSourceReadPreferenceがprimaryに設定されている場合（chainingAllowedが無効になっている場合はデフォルト）、ソース メンバーとして [プライマリ] を選択します。 プライマリが使用できない、またはアクセスできない場合は、エラーをログに記録し、プライマリの可用性を定期的に確認してください。initialSyncSourceReadPreferenceがprimaryPreferred（投票レプリカ セット メンバーのデフォルト）に設定されている場合、ソース メンバーとして [プライマリ] を選択してください。 プライマリが使用できない、またはアクセスできない場合は、残りのレプリカセット メンバーから同期ソース メンバーを選択します。他のすべてのサポートされている読み取りモードでは、宛先メンバーから同期ソース メンバーを選択します。
最初のソース ノード選択を実行するノードは、すべてのレプリカ セット ノードのリストを 2 回通過します。
メンバーは、初期ソース メンバーを最初に選択する際に、各レプリカセットのメンバーに次の基準を適用します。
ソース ノードはオンラインかつアクセス可能でなければなりません。
initialSyncSourceReadPreferenceがsecondaryまたはsecondaryPreferredの場合、ソースメンバーは セカンダリ である 必要 があります 。ソースメンバーは
visibleである 必要 があります。ソースノードは、プライマリ上の最新のoplogエントリから （デフォルトでは
maxSyncSourceLagSecs）以内である必要があります。30メンバーが
builds indexesの場合、ソース メンバーはインデックスを構築する必要があります。メンバー
votesがレプリカセットの選挙で する場合、ソース メンバーも投票する必要があります。メンバーが で
delayed memberない 場合、ソース メンバーは遅延して はなりません 。ノードが
delayed memberである場合、ソース ノードにはより短い遅延を設定する必要があります。ソース ノードは現在の最高の同期ソースよりも高速である必要があります。
1 回目のパス後に候補となるソース メンバーが 1 つも残っていない場合、メンバーは緩やかな基準で 2 回目のパスを実行します。 詳しくはSync Source Selection (Second Pass)を参照してください。
メンバーは、2 回目のパスを実行して初期ソース メンバーを選択するときに、各レプリカセットのメンバーに以下の条件を適用します。
ソース ノードはオンラインかつアクセス可能でなければなりません。
initialSyncSourceReadPreferenceがsecondaryの場合、ソースメンバーは セカンダリ である 必要 があります 。メンバーが
builds indexesの場合、ソース メンバーはインデックスを構築する必要があります。ソース ノードは現在の最高の同期ソースよりも高速である必要があります。
宛先メンバーが 2 回のパス後にソース メンバーを選択できない場合は、エラーがログに記録され、選択プロセスを再開する前に1秒間待機します。 セカンダリmongodは、エラーで終了する前に、最初の同期ソース選択プロセスを最大10回再開できます。
oplog window
The oplog window must be long enough so that a destination member can fetch any new oplog entries that occur between the start and end of the Logical Initial Sync Process. If the window is too short, some entries may fall off the oplog before the destination member can apply them.
最初の同期中に発生する可能性のある変更に対応できるよう、oplog のサイズに十分な余裕を持たせてください。
詳しくは、「Oplog サイズ」を参照してください。
複製
宛先メンバーは、最初の同期後にデータを継続的に複製します。 宛先メンバーは、ソース メンバーからoplogをコピーし、これらの操作を非同期プロセスで適用します。
宛先ノードは、ping 時間や他のノードのレプリケーションの状態の変化に基づいて、必要に応じてソース ノードを自動的に変更します。 ソース ノードの選択基準について詳しくは、「レプリケーション同期ソースの選択」を参照してください。
ストリーミングレプリケーション
ソース ノードは、宛先ノードにoplogエントリの連続ストリームを送信します。 ストリーミング レプリケーションは、高負荷および高レイテンシのネットワークでのレプリケーション ラグを軽減します。 また:
セカンダリからの読み取りの古さを軽減します。
プライマリ フェイルオーバーが原因で w: 1 の書込み操作が失われるリスクを軽減します。
w: "majority"および w: >1 を使用した書き込み操作のレイテンシを軽減します（つまり、レプリケーションを待機する必要がある書込み保証）。
oplogFetcherUsesExhaustスタートアップ パラメータを使用してストリーミング レプリケーションを無効にし、古いレプリケーション動作を使用します。 ソース ノードにリソース制約がある場合、またはレプリケーション用の MongoDB のネットワーク帯域幅の使用を制限する場合にのみ、 oplogFetcherUsesExhaustパラメータをfalseに設定します。
マルチスレッド レプリケーション
MongoDB は、同時実行性を向上させるために、複数のスレッドを使用してバッチで書込み操作を適用します。MongoDB はドキュメント ID（WiredTiger）ごとにバッチをグループ化し、異なるスレッドを使用して各操作グループを同時に適用します。MongoDB は常に、与えられたドキュメントに書込み操作を元の書込み順で適用します。
セカンダリをターゲットし、読み取り保証レベルが "local" または "majority" に設定されている読み取り操作は、レプリケーション バッチが適用されているセカンダリで読み取りが行われる場合、データの WiredTiger スナップショットから読み取ります。
スナップショットからの読み取りにより、データの一貫したビューが保証され、ロックを必要とせずに進行中のレプリケーションと同時に読み取りを実行できるようになります。その結果、これらの読み取り懸念レベルを必要とするセカンダリ読み取りは、レプリケーション バッチが適用されるまで待機する必要がなくなり、受信時に処理できるようになります。
フロー制御
管理者は、 majority committedの遅延を設定可能な最大値flowControlTargetLagSeconds以下に抑えることを目的として、プライマリが書込み (write) を適用する速度を制限できます。
デフォルトのフロー制御は、enabled です。
詳しくは、「フロー制御」を参照してください。
レプリケーション同期ソースの選択
レプリケーションソース ノードの選択は、レプリカセットchainingの設定によって異なります。
チェーンが有効になっている場合（デフォルト）、宛先メンバーからソース メンバーの選択を実行します。
チェーンが無効になっている場合は、ソース ノードとして [プライマリ] を選択します。 プライマリが使用できない、またはアクセスできない場合は、エラーをログに記録し、プライマリの可用性を定期的に確認してください。
レプリケーションソース ノードの選択を実行するノードは、すべてのレプリカセット ノードのリストを 2 回通過します。
メンバーは、ソース メンバーを最初に選択する際に、各レプリカセットのメンバーに次の基準を適用します。
ソース ノードはオンラインかつアクセス可能でなければなりません。
ソース ノードには、 ノードよりも新しい oplog エントリが必要です。 つまり、ソース ノードは ノードよりも進んでいる必要があります。
ソースメンバーは
visibleである 必要 があります。ソースノードは、プライマリ上の最新のoplogエントリから （デフォルトでは
maxSyncSourceLagSecs）以内である必要があります。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の値に従います。
最初の同期ソース選択の詳細については、「 最初の同期ソースの選択 」を参照してください。