第4章 MongoDB の Debezium コネクター
Debezium の MongoDB コネクターは、データベースおよびコレクションにおけるドキュメントの変更に対して、MongoDB レプリカセットまたは MongoDB シャードクラスターを追跡し、これらの変更を Kafka トピックのイベントとして記録します。コネクターは、シャードクラスターにおけるシャードの追加または削除、各レプリカセットのメンバーシップの変更、各レプリカセット内の選出、および通信問題の解決待ちを自動的に処理します。
このコネクターと互換性のある MongoDB のバージョンについては、Debezium でサポートされる設定ページを参照してください。
Debezium MongoDB コネクターを使用するための情報および手順は、以下のように設定されています。
4.1. Debezium MongoDB コネクターの概要
MongoDB のレプリケーションメカニズムは冗長性と高可用性を提供し、実稼働環境における MongoDB の実行に推奨される方法です。MongoDB コネクターは、レプリカセットまたはシャードクラスターの変更をキャプチャーします。
MongoDB レプリカセット は、すべてが同じデータのコピーを持つサーバーのセットで設定され、レプリケーションによって、クライアントがレプリカセットの プライマリー のドキュメントに追加したすべての変更が、セカンダリーと呼ばれる別のレプリカセットのサーバーに適用されるようにします。MongoDB のレプリケーションでは、プライマリーが oplog (または操作ログ) に変更を記録した後、各セカンダリーがプライマリーの oplog を読み取って、すべての操作を順番に独自のドキュメントに適用します。新規サーバーをレプリカセットに追加すると、そのサーバーは最初にプライマリーのすべてのデータベースおよびコレクションの スナップショット を実行し、次にプライマリーの oplog を読み取り、スナップショットの開始後に加えられたすべての変更を適用します。この新しいサーバーは、プライマリーの oplog の最後に到達するとセカンダリーになり、クエリーを処理できます。
MongoDB コネクターは、変更をキャプチャするのに 2 つの異なるモードをサポートしています。capture.mode オプションで制御します。
- oplog ベース
- Change Streams ベース
Oplog キャプチャーモード (レガシー)
Debezium MongoDB コネクターは上記と同じレプリケーション機構を使いますが、実際にはレプリカセットのメンバーにはなりません。ただし、MongoDB のセカンダリーと同様に、コネクターはレプリカセットのプライマリーの oplog を常に読み取ります。また、コネクターが初めてレプリカセットを表示するとき、oplog を確認して最後に記録されたトランザクションを取得した後、プライマリーのデータベースおよびコレクションのスナップショットを実行します。すべてのデータがコピーされると、コネクターは oplog から読み取った位置から変更をストリーミングします。MongoDB oplog における操作は べき等 であるため、操作の適用回数に関係なく、同じ最終状態になります。
このモードの欠点は、挿入 変更イベントだけがドキュメント全体を含み、更新 イベントには変更されたフィールドの表現だけが含まれ (つまり、変更されていないフィールドは 更新 イベントから取得できない)、削除 イベントにはキー以外の削除されたドキュメントの表現が含まれないことです。
このモードはレガシーモードとみなされます。MongoDB 5 ではサポートされていないので、MongoDB 4.x サーバーでは使用しないことを強くおすすめします。
ストリームモードの変更
Debezium MongoDB コネクターは、実際にレプリカセットのメンバーになることはありませんが、上記のものと同様のレプリケーション機構を使用しています。主な違いは、コネクターが直接 oplog を読むのではなく、oplog のキャプチャとデコードを MongoDB の Change Streams 機能に委ねる点です。Change Streams では、MongoDB サーバーはコレクションへの変更をイベントストリームとして公開します。Debezium のコネクターは、ストリームを監視し、変更を下流に配信します。また、コネクターが初めてレプリカセットを表示するとき、oplog を確認して最後に記録されたトランザクションを取得した後、プライマリーのデータベースおよびコレクションのスナップショットを実行します。すべてのデータのコピーが完了すると、コネクターは先に oplog から読み取った位置からチェンジストリームを作成する。
MongoDB 4.x 以降では、変更ストリームが推奨されるモードです。MongoDB 3.x では変更ストリームモードを使用できません。
どちらのキャプチャモードも、オフセットに格納された異なる値を使用することで、コネクターの再起動後に最後に見た位置からストリーミングを再開することができます。そのため、Change Streams モードから oplog モードへの切り替えはできません。不用意なキャプチャモードの変更を防ぐため、コネクターにセーフティチェックを内蔵しています。
コネクターを起動すると、保存されているオフセットがチェックされます。元のキャプチャモードが oplog ベースで、新しいモードが Change Streams ベースの場合、Change Streams への移行を試みます。元のキャプチャーモードがストリームベースで変更された場合、新しいモードが oplog ベースの場合だけでなく、変更ストリームを使用し続け、このモードに関する警告がログに出力されます。
MongoDB コネクターは変更を処理すると、イベントの発信先の oplog/stream の位置を定期的に記録します。コネクターが停止したら、最後に処理した oplog/stream の位置を記録するため、再起動時にはその位置からストリーミングが開始されます。つまり、コネクターを停止、アップグレード、または維持でき、後で再起動できます。イベントを何も失うことなく、停止した場所を正確に特定します。当然ながら、MongoDB の oplogs は通常は最大サイズに制限されているため、コネクターを長時間停止しないようにしてください。長時間停止すると、oplog の操作によってはコネクターによって読み取られる前にパージされる可能性があります。この場合、コネクターを再起動すると、不足している oplog 操作が検出され、スナップショットが実行されます。その後、変更のストリーミングが続行されます。
MongoDB コネクターは、レプリカセットのメンバーシップとリーダーシップの変更、シャードクラスター内でのシャードの追加と削除、および通信障害の原因となる可能性のあるネットワーク問題にも非常に寛容です。コネクターは常にレプリカセットのプライマリーノードを使用して変更をストリーミングします。そのため、レプリカセットの選出が行われ、他のノードがプライマリーになると、コネクターはすぐ変更のストリーミングを停止し、新しいプライマリーに接続し、新しいプライマリーを使用して変更のストリーミングを開始します。同様に、コネクターがレプリカセットのプライマリーと通信する際に問題が発生した場合は、再接続を試み (ネットワークまたはレプリカセットを圧倒しないように指数バックオフを使用)、最後に停止した位置から変更のストリーミングを続行します。これにより、コネクターはレプリカセットメンバーシップの変更を動的に調整でき、通信の失敗を自動的に処理できます。
