レプリケーション遅延により、「遅延した」ノードはすぐにプライマリになる資格を失い、分散された読み取り操作が一貫性を失う可能性が高まります。
このページにはレプリケーションラグ を軽減できるいくつかのヒントが含まれていますが、多くの場合はエスカレーションが必要になる場合があります。レプリケーションラグの原因を特定できない場合や、追加のサポートが必要な場合は、テクニカル サポートにお問い合わせください。
前提条件チェック
配置における現在のレプリケーションラグの長さを確認するには
mongoshプライマリに接続されている セッションで、 メソッドを呼び出して、プライマリrs.printSecondaryReplicationInfo()ホストに対する各セカンダリの現在のラグを表示します。各ノードの
syncedTo値を返します。これは、次の例に示すように、直近の oplog エントリがセカンダリに書き込まれた時刻を示します。source: m1.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 7230 secs (2 hrs) behind the primary source: m2.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary プライマリより遅れている秒数は、セカンダリがプライマリよりもどれだけ遅れているかを示します。
プライマリの非アクティブ期間が
members[n].secondaryDelaySecsの値より大きい場合、遅延ノードはプライマリより0秒遅れて表示されることがあります。Atlas 配置では、Replication Lag Cloud Managerおよび Ops Manager で使用可能な グラフで、 oplog時間値がゼロ以外または増加しているかどうかを確認して、Atlas 配置のレプリケーションの速度を監視します。
さらに、クラスターの メトリクスタブでReplication Lag 、 、 を確認することで、AtlasOplog GB/Hour Replication Oplog Windowのレプリケーションラグを監視できます。詳細については、「 利用可能なメトリクスの確認 」を参照してください。
一般的な問題と解決策
レプリケーションラグにはエラー コードはなく、原因を即座に特定する方法はありません。ただし、サポートにエスカレートする前に、次の問題が遅延の原因になっているかどうかを確認してください。
ネットワーク レイテンシ
クラスター ノードが相互に確実に通信できない場合、レプリケーションラグが蓄積されることがあります。
レプリカセットのメンバー間のネットワークルートに、パケットロスやネットワークルーティングの問題がないことを確認します。
セットメンバー間のレイテンシをテストするにはping などのツールを使用し、ネットワークtraceroute エンドポイント間のパケットのルーティングを明らかにするには を使用します。
または、replSetGetStatus を実行し、pingMs フィールドを確認します。プライマリ ノードと セカンダリ ノード間の現在のネットワークレイテンシをミリ秒単位で返します。
セカンダリ リソースの枯渇
セカンダリ ノードは、プライマリからの受信読み取り操作を効率的に処理できない場合、リソースの競合が発生する可能性があります。これにより、キャッシュ競合などのメモリの問題が発生する可能性があります。キャッシュがクリティカルなしきい値に達すると、サーバーはアプリケーションスレッドを使用してページを排除するため、レプリケーション の管理に使用できるスレッド数が減ります。
サーバーがアプリケーションスレッドをリダイレクトしてタスクをエビクションするかどうかを確認するには、mongosh シェルで次のコマンドを実行します。
db.serverStatus().wiredTiger.cache['pages evicted by application threads']
結果 =0 の場合: エビクションのために一時停止されるアプリケーションスレッドはありません。
結果 >0 （および増加）の場合:データベースはキャッシュ負荷下にあります。受信クエリは実行前にキャッシュされたデータをエビクションする必要があるため、レプリケーションラグが増加する可能性があります。
Atlas ユーザーは、WiredTiger Cache Activity と Page Faults メトリクスをモニターして、キャッシュ関連の問題を調査することもできます。
この問題を解決する潜在的な戦略については、「 リソースのスケーリング 」を参照してください。
ディスク関連の問題
セカンダリノードがダーティ データをディスクに十分な速度でフラッシュできない場合は、プライマリ ノードより遅れます。このイベントは、プライマリからの書き込み量がセカンダリのディスクの書込み速度を超える場合に発生します。
ディスクに関連する問題は、仮想化インスタンスなどのマルチテナント システムでは一般的です。また、システムがIPネットワーク経由でディスク デバイスにアクセスする場合、一時的な問題である可能性があります。
ディスクの状態を評価するには、iostat や vmstat などのシステムレベルのツールを使用します。
Atlas ユーザーは、ディスクの問題を調査するために、 Disk IOPSやDisk Space Used などの Atlas メトリクスにアクセスできます。
ディスクの問題の一般的な原因には、次のようなものがあります。
プロビジョニング: セカンダリはプライマリよりも遅いディスク、または低 IOPS を使用します。
仮想化のオーバーヘッド: 共有環境では、他の仮想マシンが物理ディスク コンポーネントを飽和させる可能性があります。
ディスクの問題の解決策には、次のようなものがあります。
プロビジョニングされた IOPS の増加
より高い Atlasクラスター層にアップグレードします。詳細については、「 Atlas クラスターのサイズ設定と階層の選択 」を参照してください。
長時間実行操作
セカンダリでのレプリケーションが、プライマリで長時間実行されている操作によってブロックされる場合があります。最良の結果を得るには、セカンダリにレプリケーションの確認を要求するように書込み保証（write concern）を設定します。これにより、レプリケーションが書込み（write）負荷に追いつかない場合に、書込み操作が完了前に結果を返さないよう防げます。
過剰な書込み (write) 負荷
一括書込み (write) 操作では、レプリカセットの時間単位のレプリケーション能力を超え、レプリケーションラグが発生する可能性があります。
次のサブセクションでは、この問題に対して考えられる解決策を提供しています。
より小さいバッチを使用する
CRUDコマンドをバッチおよびフィルタリングして負荷を制御します。
月、週、日などの日付または時間範囲に対して各バッチするを実行します。コレクションスキャンを回避するために、クエリフィルターがインデックスを使用していることを確認します。コレクションスキャンにより、ワーキングセットからデータとインデックスページが排除され、レプリケーションラグが増加する可能性があります。
最初に小さな日付範囲を削除します。これらの操作が 秒以内に完了する場合は、バッチするサイズを増やします。rs.printSecondaryReplicationInfo() でレプリケーションラグを監視します。スループットとレプリケーションラグのバランスがとれるまで、バッチするサイズを増やします。システム負荷、他のユーザーとアプリケーションへの影響、およびセカンダリの遅延時間を引き続き監視します。
以下に例を挙げます。
db.collName.deleteMany({createdDate: {$gte: new Date("2018-12-01"), $lt: new Date("2019-01-01")}}); db.collName.deleteMany({createdDate: {$gte: new Date("2018-11-01"), $lt: new Date("2018-12-01")}}); db.collName.deleteMany({createdDate: {$gte: new Date("2018-10-01"), $lt: new Date("2018-11-01")}});
サーバーサイドの設定とパラメーターの構成
MongoDB は、書き込み集中型の操作中にリソース使用を制御できる次のサーバーサイド設定とパラメーターを提供します。
storageEngineConcurrentWriteTransactions: この値を小さくすると、他の書き込み操作が同時に発生した場合に一括削除による競合を軽減できます。注意
storageEngineConcurrentWriteTransactionsを変更するときは注意してください。設定を変更するとパフォーマンスの問題やエラーが発生する可能性があるためです。パラメーターを変更する前に、 MongoDBサポートに確認することをお勧めします。maxTimeMS: 一括書き込み操作が複雑な場合は、その実行時間を制限して、サーバーのパフォーマンスに影響を与える操作が長時間実行されるのを防ぐことができます。複雑な操作の例には、多くのドキュメントを照合したり、インデックスがないフィールドによるクエリを含む場合があります。
インデックスを作成した順序でのドキュメントの削除
一括操作を実行するフィールドがインデックス化されていない場合、一括操作によってコレクションまたはテーブルスキャンが発生し、リソース使用量が増加する可能性があります。クエリフィルターで使用されるフィールドにインデックスが存在するようにすると、削除がより速くなり、ロック競合を減らし、パフォーマンスを向上させることができます。
操作を実行中前に、インデックスを作成します。
db.collection.createIndex({ status: 1 });
次に、インデックスフィールドに基づいて削除します。
db.collection.deleteMany({ status: "inactive" });
oplogウィンドウ サイズ
同期するデータ量に対してoplog ウィンドウ が小さすぎると、レプリケーションラグ が発生する可能性があります。 oplog が大きいほど、レプリカセットの遅延に対する許容度が高まります。
特定のレプリカセット のノードでoplogのサイズとその操作の日付範囲を確認するには、 でそのノードに接続し、mongosh rs.printReplicationInfo()メソッドを実行します。 oplogは、予想しうる最長のセカンダリのダウンタイムの間、すべてのトランザクションを保持できる長さである必要があります。 []1 少なくとも、 oplog で少なくとも24 時間の操作を保持できる必要があります。ただし、多くのユーザーは、72 時間または 1 週間分の操作の保持を好みます。
注意
通常、すべてのノードで oplog を同じサイズに揃えます。oplog のサイズを変更する場合は、すべてのノードでサイズを変更します。
oplogサイズを変更するには、「自己管理型レプリカセット ノードのoplogサイズの変更」チュートリアルを参照してください。
| [1] | oplog は、majority commit point が削除されるのを回避するために、設定されたサイズ制限を超えて大きくなることがあります。 |
解決策を確認する
問題が解決されたことを確認するには、rs.printSecondaryReplicationInfo() メソッドを呼び出して、遅延ノードがないことを確認します。
より多くのサポートのために収集する診断情報
上記の解決策でもラグが軽減されない場合は、 サポートにお問い合わせ ください。サポートでは、問題をさらに診断するために診断をリクエストする場合があります。
Atlas ユーザーがサポートを収集するために役立つ診断には、次のようなものがあります。
遅延が開始されたときのタイムライン
配置に対する最近の変更（スキーマ、インデックス、アプリケーション、階層、またはハードウェアの変更など）。