第3章 MongoDB の Debezium コネクター

MongoDB のレプリケーションメカニズムは冗長性と高可用性を提供し、実稼働環境における MongoDB の実行に推奨される方法です。MongoDB コネクターは、レプリカセットまたはシャードクラスターの変更をキャプチャーします。

MongoDB レプリカセット は、すべてが同じデータのコピーを持つサーバーのセットで設定され、レプリケーションによって、クライアントがレプリカセットの プライマリー のドキュメントに追加したすべての変更が、セカンダリーと呼ばれる別のレプリカセットのサーバーに適用されるようにします。MongoDB のレプリケーションでは、プライマリーが oplog (または操作ログ) に変更を記録した後、各セカンダリーがプライマリーの oplog を読み取って、すべての操作を順番に独自のドキュメントに適用します。新しいサーバーがレプリカセットに追加されると、そのサーバーは最初にプライマリー上のすべてのデータベースおよびコレクションの最初の 同期 を実行し、次にプライマリーの oplog を読み取り、最初の同期の開始後に加えられた可能性のあるすべての変更を適用します。この新しいサーバーは、プライマリーの oplog の最後に到達するとセカンダリーになり、クエリーを処理できます。

MongoDB コネクターはこのレプリケーションメカニズムを使用しますが、実際にはレプリカセットのメンバーにはなりません。ただし、MongoDB のセカンダリーと同様に、コネクターはレプリカセットのプライマリーの oplog を常に読み取ります。また、コネクターが初めてレプリカセットを確認すると、oplog を確認して最後に記録されたトランザクションを取得し、プライマリーのデータベースおよびコレクションの意図的な 同期 を実行します。すべてのデータがコピーされると、コネクターは先に読み込んだ位置から oplog の読み取りを開始します。MongoDB oplog における操作は べき等 であるため、操作の適用回数に関係なく、同じ最終状態になります。

MongoDB コネクターは oplog を処理すると、イベントの発信先の oplog の位置を定期的に記録します。MongoDB コネクターが停止すると、最後に処理した oplog の位置を記録するため、再起動時にその位置から oplog の読み取りが開始されます。つまり、コネクターを停止、アップグレード、または維持でき、後で再起動できます。イベントを何も失うことなく、停止した場所を正確に特定します。当然ながら、MongoDB の oplogs は通常は最大サイズに制限されているため、コネクターを長時間停止しないようにしてください。長時間停止すると、oplog の操作によってはコネクターによって読み取られる前にパージされる可能性があります。この場合、コネクターは不足している oplog 操作を検出し、初期同期を実行してから oplog の調整に進みます。

MongoDB コネクターは、レプリカセットのメンバーシップとリーダーシップの変更、シャードクラスター内でのシャードの追加と削除、および通信障害の原因となる可能性のあるネットワーク問題にも非常に寛容です。コネクターは常にレプリカセットのプライマリーノードを使用して oplog を調整するため、レプリカセットの選択が行われ、別のノードがプライマリーになると、コネクターは即座に oplog の追跡を停止し、新しいプライマリーに接続し、新しいプライマリーを使用して oplog のチューニングを開始します。同様に、コネクターがレプリカセットのプライマリーとの通信で問題が発生した場合は、再接続を試みます（ネットワークまたはレプリカセットに圧倒しないように指数バックオフを使用）。また、最後に停止した oplog の調整を続行します。これにより、コネクターはレプリカセットメンバーシップの変更を動的に調整でき、通信の失敗を自動的に処理できます。