4.4.3. ストリーミングの変更

レプリカセットのコネクタータスクにオフセットがある場合、オフセットを使用して変更のストリーミングを開始する oplog の位置を決定します。その後、タスクはレプリカセットのプライマリーノードに接続し、その位置からの変更のストリーミングを開始し、すべての作成、挿入、および削除の操作を処理し、それらを Debezium 変更イベント に変換します。各変更イベントには、操作が見つかった oplog の位置が含まれ、コネクターはこれを最新のオフセットとして定期的に記録します。オフセットが記録される間隔は offset.flush.interval.ms、Kafka Connect ワーカー設定プロパティーであるによって制御されます。

コネクターが正常に停止されると、処理された最後のオフセットが記録され、再起動すると、コネクターはそのまま停止した場所をそのまま保持します。ただし、コネクターのタスクが突然終了した場合、タスクは最後にオフセットを記録した後に、最後のオフセットが記録される前に処理および生成されたイベントが発生した可能性があります。再起動すると、コネクターは最後に 記録 されたオフセットから開始し、クラッシュの直前に生成された同じイベントが生成される可能性があります。

上記のように、コネクタータスクは常にレプリカセットのプライマリーノードを使用して oplog から変更をストリーミングし、コネクターが可能な限り最新の操作を認識するようにし、代わりに 2 つのデータが使用される場合よりも低いレイテンシーで変更をキャプチャーできます。レプリカセットが新しいプライマリーを選択すると、コネクターはストリーミングの変更を停止し、新しいプライマリーに接続し、新しいプライマリーノードからの変更のストリーミングを開始します。同様に、コネクターがレプリカセットのメンバーと通信する際に問題が発生した場合に、指数関数的バックオフを使用してレプリカセットに過重なバックオフを行わないようにし、接続すると、最後に完了した場所から変更がストリーミングを継続します。これにより、コネクターはレプリカセットメンバーシップの変更に動的に調整し、通信の失敗を自動的に処理できます。

要約すると、MongoDB コネクターはほとんどの場合で実行を継続します。通信の問題により、問題が解決するまでコネクターが待機する可能性があります。