レプリカセット データの同期
共有データセットの最新のコピーを維持するために、レプリカセットのセカンダリ メンバーはソース メンバーからデータを同期または複製し 。 MongoDB は、新しいメンバーに完全なデータ セットを入力する最初の同期と、進行中の変更をデータ セット全体に適用するレプリケーションという 2 つの形式のデータ同期を使用します。
最初の同期
最初の同期では、レプリカセットのソース メンバーのすべてのデータが宛先メンバーにコピーされます。 ソースノードの選択基準の詳細については、「 最初の同期ソースの選択」を参照してください。
注意
最初の同期中に、 MongoDBは宛先メンバーのoplogを切り捨てます。このoplog の切り捨ては、変更ストリームなど、 oplogデータに依存するプロセスに影響を与える可能性があります。
initialSyncSourceReadPreference パラメーターを使用して、優先される最初の同期ソースを指定できます。このパラメーターは 、 mongod を起動するときにのみ指定できます。
MongoDB 5.2 以降では、最初の同期は 論理またはファイル コピー ベースにすることができます。
論理的な最初の同期プロセス
論理的な最初の同期を実行すると、MongoDB は次の処理を実行します。
ローカルデータベースを除くすべてのデータベースを複製します。 クローンを作成するために、
mongodは各ソース メンバー データベース内のすべてのコレクションをスキャンし、すべてのデータをこれらのコレクションの独自のコピーに挿入します。コレクションごとにドキュメントがコピーされる際に、すべてのコレクション インデックスを構築します。
データのコピー中に新しく追加された oplog レコードを取得します。 このデータ コピー ステージの実行中にこれらの oplog レコードを一時的に保存するのに十分なディスク領域が宛先メンバーの
localデータベース内にあることを確認します。すべての変更をデータ セットに適用します。
mongodは、ソース メンバーからの oplog を使用して、レプリカセットの現在の状態を反映するようにデータセットをアップデートします。
最初の同期が完了すると、ノードは 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に設定されている場合（chainingAllowedが無効になっている場合はデフォルト）、ソース メンバーとして [プライマリ] を選択します。 プライマリが使用できない、またはアクセスできない場合は、エラーをログに記録し、プライマリの可用性を定期的に確認してください。initialSyncSourceReadPreferenceがprimaryPreferred（投票レプリカ セット メンバーのデフォルト）に設定されている場合、ソース メンバーとして [プライマリ] を選択してください。 プライマリが使用できない、またはアクセスできない場合は、残りのレプリカセット メンバーから同期ソース メンバーを選択します。他のすべてのサポートされている読み取りモードでは、宛先メンバーから同期ソース メンバーを選択します。
最初のソース ノード選択を実行するノードは、すべてのレプリカ セット ノードのリストを 2 回通過します。
メンバーは、初期ソース メンバーを最初に選択する際に、各レプリカセットのメンバーに次の基準を適用します。
ソース ノードはオンラインかつアクセス可能でなければなりません。
initialSyncSourceReadPreferenceがsecondaryまたはsecondaryPreferredの場合、ソースメンバーは セカンダリ である 必要 があります 。ソースメンバーは
visibleである 必要 があります。ソースノードは、プライマリ上の最新の oplog エントリから
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
は、宛先ノードが oplog window論理的な最初の同期プロセスoplog の開始と終了の間に発生する新しい エントリを取得できるように十分な長さにする必要があります。ウィンドウの長さが十分でない場合、宛先メンバーがエントリを適用する前に、一部のエントリがoplogから外れてしまうリスクがあります。
新しい oplog エントリを取得するための追加時間を考慮して、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 です。
注意
フロー制御を有効にするには、レプリカセットおよびシャーディングされたクラスターは、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の値に従います。
最初の同期ソース選択の詳細については、「 最初の同期ソースの選択 」を参照してください。