2.2.4.2. 変更のストリーミング
通常、PostgreSQL コネクターは、接続されている PostgreSQL サーバーから変更をストリーミングするのに多くの時間を費やします。このメカニズムは、クライアントが特定の位置(ログ シーケンス番号
または短い LSN とも呼ばれる)でサーバーのトランザクションログにコミットされたときにサーバーから変更を受け取る PostgreSQL のレプリケーションプロトコル に依存します。
サーバーがトランザクションをコミットするたびに、別のサーバープロセスが 論理デコードプラグイン からコールバック関数を呼び出します。この関数はトランザクションからの変更を処理し、特定の形式(Debezium プラグインの場合は Protobuf または JSON)に変換して、クライアントが使用できる出力ストリームに書き込みます。
PostgreSQL コネクターは PostgreSQL クライアントとして機能し、これらの変更を受信すると、イベントを Debezium の 作成、更新、またはイベントの LSN の位置が含まれるイベントに変換します。PostgreSQL コネクターはこれらの変更イベントを Kafka Connect フレームワーク(同じプロセスで実行されている)に転送するため、適切な Kafka トピックに同じ順序で非同期に書き込みます。Kafka Connect は、Debezium が各イベントに含まれるソース固有の位置情報に オフセット を使用し、Kafka Connect は別の Kafka トピックに最新のオフセットを定期的に記録します。
Kafka Connect が正常にシャットダウンすると、コネクターを停止し、すべてのイベントを Kafka にフラッシュし、各コネクターから受け取った最後のオフセットを記録します。再起動時に、Kafka Connect は各コネクターの最後に記録されたオフセットを読み取り、その時点からコネクターを起動します。PostgreSQL コネクターは、各変更イベントに記録された LSN をオフセットとして使用するため、コネクターを再起動すると PostgreSQL サーバーはその位置の直後に開始するイベントを送信します。
PostgreSQL コネクターは、論理デコーダープラグインによって送信されるイベントの一部としてスキーマ情報を取得します。唯一の例外は、プライマリーキーを設定する列に関する情報です。この情報は JDBC メタデータ(サイドチャネル)から取得されるためです。テーブルのプライマリーキー定義が変更されると(PK 列の追加、削除、または名前変更による)、JDBC からのプライマリーキー情報が論理デコードイベントの変更データと同期されず、一貫性のないキー構造でメッセージが少なって作成されます。これが発生すると、コネクターの再起動とメッセージの再処理により問題が修正されます。問題を完全に回避するには、以下の操作シーケンスを使用して Debezium のプライマリーキー構造への更新を同期することが推奨されます。
- データベースまたはアプリケーションを読み取り専用モードにする
- Debezium が残りのイベントをすべて処理させる
- Debezium の停止
- プライマリーキー定義の更新
- データベースまたはアプリケーションを読み取り/書き込み状態にし、Debezium を再び開始します。