Change Streams の運用に関する推奨事項

レプリカセット

アービタ ノードを含むレプリカセットの場合、十分な数のデータを保持するノードが利用できず、操作を過半数でコミットできない場合、変更ストリームはアイドル状態のままになることがあります。

たとえば、2 つのデータを保持しているノードと 1 つのアービタを含む 3 ノードのレプリカセットを考えてみましょう。障害やアップグレードなどによりセカンダリがダウンした場合、書込み (write) を過半数でコミットすることはできません。変更ストリームは開いたままですが、通知は送信されません。

このシナリオでは、アプリケーションが最後に受信した操作がレプリカセットの oplog に残っている限り、アプリケーションはダウンタイム中に発生したすべての操作に追いつくことができます。

アップグレードや重大な災害などにより長時間のダウンタイムが予想される場合は、予想されるダウンタイムよりも長い時間にわたって操作が保持されるように、oplog のサイズを増やすことを検討してください。rs.printReplicationInfo() を使用して、oplog のサイズや操作の時間範囲など、oplog の状態に関する情報を取得します。

シャーディングされたクラスター

変更ストリームは、グローバル論理クロックを利用して、シャード全体の変更の総合的な順序付けを提供します。MongoDB では、変更の順序が保持され、変更ストリーム通知の受信順に安全に解釈されることを保証します。たとえば、3 つのシャードがあるシャーディングされたクラスターに対して変更ストリーム カーソルを開くと、3 つのシャードすべてにおけるそれらの変更の総合的な順序に応じた変更通知が返されます。

変更の総合的な順序を保証するために、mongos は変更通知のたびに各シャードをチェックして、そのシャードに最新の変更が加えられているかどうかを確認します。コレクションに対しほとんどもしくはまったくアクティビティがない、または「コールド」であるシャードが 1 つ以上あるシャーディングされたクラスターの場合、mongos は、変更の総合的な順序を保証するために、引き続きコールド シャードをチェックする必要があるため、変更ストリームの応答時間に悪影響を及ぼす可能性があります。この影響は、地理的に分散されたたシャードや、操作の大部分がクラスター内のシャードのサブセットで行われるワークロードでより顕著になる場合があります。コールド シャードのレイテンシを最小限に抑えるには、periodicNoopIntervalSecs の値を低く指定します。

シャーディングされたコレクションのアクティビティレベルが高い場合、mongos はすべてのシャードでの変化に追いつけない可能性があります。このようなコレクションには、通知フィルタを利用することを検討してください。たとえば、insert 操作のみをフィルタリングするように構成された $match パイプラインを渡します。

インデックスとパフォーマンス

変更ストリームではインデックスを使用できません。MongoDB は、 oplogコレクションでのインデックスの作成をサポートしていません。したがって、サーバーのパフォーマンスに影響を与える可能性があるため、特定のターゲットを絞った変更ストリームを大量に開かないようにしてください。

Change Streams と孤立したドキュメント

MongoDB 5.3 以降では、範囲の移行 中に、孤立したドキュメントの更新に対して 変更ストリームイベントは生成されません。