3.4.3. oplog の調整

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

コネクターが正常に停止されると、処理された最後のオフセットが記録され、再起動時にコネクターは停止した場所から続行されます。しかし、コネクターのタスクが予期せず終了した場合、最後にオフセットが記録された後、最後のオフセットが記録される前に、タスクによってイベントが処理および生成されることがあります。再起動時に、コネクターは最後に 記録された オフセットから開始し、クラッシュの前に生成された同じイベントを生成する可能性があります。

上記のように、コネクタータスクは常にレプリカセットのプライマリーノードを使用して oplog を維持し、コネクターが可能な限り最新の操作を認識し、代わりにセカンダリーが使用されるよりも短いレイテンシーで変更をキャプチャーできるようにします。レプリカセットが新しいプライマリーを選出すると、コネクターは即座に oplog の追跡を停止し、新しいプライマリーの oplog の調整を開始し、新しいプライマリーの oplog を同じ位置で開始します。同様に、コネクターとレプリカセットメンバーとの通信で問題が発生した場合は、再接続を試みます（レプリカセットを過剰にさらしないように指数バックオフを使用）、接続すると、最後に停止した oplog の調整を続行します。これにより、コネクターはレプリカセットメンバーシップの変更を動的に調整でき、通信の失敗を自動的に処理できます。

下部の行では、MongoDB コネクターはほとんどの状況で引き続き実行されますが、通信の問題により、問題が解決されるまでコネクターが待機する可能性があります。