Red Hat build of Debezium 2.7.3 のリリースノート

データベース通信エラーなどの特定の状況では、JDBC クエリーが永続的なハング状態になることがあります。この問題を軽減するために、Debezium では、コネクターがクエリー応答を待機する時間を設定できる query.timeout.ms プロパティーが提供されるようになりました。タイムアウト処理を無効にするには、値を 0 に設定します。デフォルト値は 600000 ミリ秒 (600 秒) です。

Debezium TimezoneConverter SMT を使用すると、送信されるペイロードの時間値を指定されたタイムゾーンに変換できます。元の実装では、ペイロードの before 部分または after 部分内の値の変換を許可するように特に制限されていました。コンバーターを使用して、source 情報ブロックの ts_ms など、メタデータ内の他の時間ベースのフィールドを変換できるようになりました。
この変更により、コネクターを実行する JVM のタイムゾーン設定がソースデータベースサーバーの設定と一致せず、envelope ts_ms および source ts_ms 値の差にエラーが発生する場合に、ラグメトリクスの計算が改善されます。TimezoneConverter を使用してメタデータフィールドを変換し、一貫したタイムゾーンを使用するようにコネクターを設定すると、これら 2 つのフィールド間の正確な遅延時間をより簡単に計算できます。

MySQL コネクターを読み取り専用モードで実行する場合を除き、増分スナップショットを実行するには、トランザクションログに記録されたデータと変更境界を調整するために、オープンマーカーとクローズマーカーを書き込むシグナルテーブルが必要です。場合によっては、スナップショットウィンドウがいつ開かれ、いつ閉じられたかを記録しておくと役立つことがあります。
Debezium では、次の例に示すように、シグナルテーブルの data 列にこれらのシグナルマーカーに関する詳細が提供されるようになりました。

{"openWindowTimestamp": "<window-open-time>"}

{"openWindowTimestamp": "<window-open-time>"}

{"openWindowTimestamp": "<window-open-time>", "closeWindowTimestamp": "<window-close-time>"}

{"openWindowTimestamp": "<window-open-time>", "closeWindowTimestamp": "<window-close-time>"}

デフォルトでは、CloudEvents コンバーターは、CloudEvent メッセージのスキーマを自動的に生成します。ただし、自動的に生成されたスキーマ名が不十分な場合は、metadata.source プロパティーで dataSchemaName を指定して設定を調整できます。dataSchemaName を次のいずれかの値に設定できます。

場合によっては、JDBC シンクコネクターが null 値のフィールドを含むイベントを消費し、イベントレコードをターゲットデータベースに書き込むときに、値 NULL ではなく、デフォルトのフィールド値が誤って書き込まれることがありました。

MongoDB コネクターの非推奨の replica_set モードが削除されました。Debezium の replica_set 接続モードにより、MongoDB コネクターは個別の Kafka Connect タスクを使用して、tasks.max 設定の範囲内で各データベースシャードを個別に処理できるようになりました。この設定は MongoDB ルーター (mongos) を回避しました。ただし、MongoDB データベースは、クライアントが常にルーターを介して接続することを想定して設計されています。その結果、replica_set 接続モードでは、シグナリング、増分スナップショットのサポート、およびコードベース全体の複雑さに問題が発生する可能性があります。

replica_set 接続モードを削除すると、コネクターは単一タスク操作に制限されます。以前に、replica_set モードを使用するように MongoDB コネクターを設定していた場合、Debezium 2.7.3 へのアップグレード後もコネクターを引き続き使用するには、設定を調整する必要があります。詳細は、MongoDB コネクターのドキュメント を参照してください。

Oracle 12 のサポートは以前のリリースでは非推奨になりました。Debezium 2.7.3 以降では、Oracle 12 データベースで Debezium を使用できなくなりました。

Oracle Database 12c リリース 1 (12.1) は、2022 年 7 月 31 日にライフサイクル終了に達しました。この日付以降、Oracle はこのバージョンに対するバグ修正、セキュリティー更新、またはパッチを提供しません。Debezium 2.1.4 は、Oracle 12c のサポートを宣伝した最後のリリースでした。

この問題は修正され、コネクターは設定された小数点処理モードに従ってこれらの列を正しく出力するようになりました。コネクターをアップグレードすると、この動作の変更により、厳密なスキーマレジストリー互換性ルールを使用するデプロイメントで問題が発生する可能性があります。

SQL Server コネクターは、コネクターが最初にデプロイされたときにすべてのスキーマをキャプチャーせず、代わりに、設定の包含リストで定義されたテーブルに基づいてスキーマのみをキャプチャーしていました。これは、新しいテーブルのスキーマがスキーマ履歴トピックにすでに存在すると想定した場合に、ユーザーがコネクターに新しいテーブルを簡単に追加できなくする可能性があるバグでした。コネクターが store.only.captured.tables.ddl 設定オプションを正しく反映するようになる (DBZ-7593).

既存のコネクターのデプロイメントでは、スキーマ履歴トピックの store.only.captured.tables.ddl プロパティーを明示的に設定しないと、コネクターはデータベース内のすべての関連テーブルのスキーマ変更のキャプチャーを開始します。これを阻止し、以前の動作を維持する場合は、値が true の schema.history.internal.store.only.captured.tables.ddl を追加してコネクター設定を調整する必要があります。

以前のバージョンの Debezium では、SQL Server コネクターはポーリングのイテレーション中に利用可能なすべてのトランザクションを処理していました。トラフィック量が多いと、メモリーが過負荷になり、パフォーマンスが低下する可能性があります。この問題に対処するための max.iteration.transactions 設定プロパティーはすでに存在しますが、以前はデフォルト値 0 で設定されていました。以前のデフォルト値に基づいて、コネクターは引き続きすべてのトランザクションの処理を試行します。ポーリングのイテレーション中にコネクターが処理するトランザクションの数を制限するために、このリリースでは、プロパティーのデフォルト値が 500 に設定されるようになりました。

SQL Server はデータベースマッピングごとに一意のタスクの生成をサポートしているため、通常の JMX メトリクスは taskId 属性を使用して登録されます。過去のリリースでは、JMX シグナルチャネルはこれを反映しなかったため、コネクターが各タスクのチャネルを開始できない可能性がありました。この問題は修正され、JMX シグナルチャネルの MBean 名に taskId が含まれるようになりました。MBean 名に taskId を含めることで、単一のコネクターをデプロイして複数の SQL Server データベースからの変更をストリーミングするときに、各データベースタスクのシグナルチャネルを一意に識別できるようになりました。

以前のリリースでは、テクノロジープレビュー機能により、Oracle RAC 環境で Oracle Database 用の Debezium コネクターの使用をテストするオプションが提供されていました。Oracle RAC 環境でのコネクターの使用が完全にサポートされるようになりました。

PostgreSQL 16 データベースで Debezium コネクターを使用する場合、データベースのスタンバイインスタンスにレプリケーションスロットを定義できるようになりました。このデータベースの変更に基づいて、Debezium ではスタンバイ PostgreSQL 16 サーバーに接続し、そこから変更をストリーミングできるようになりました。運用システムからではなく、レプリカから変更データキャプチャーを実行すると、特に非常にアクティブなデータベースで、サーバーの負荷をより適切に分散できます。

変更イベントのタイムスタンプの精度を向上させるために、変更イベントには、次の例に示すように、エンベロープに 2 つ、source 情報ブロックに 2 つの合計 4 つのフィールドが追加されました。

{
  "source": {
    ...,
    "ts_us": "1559033904863123",
    "ts_ns": "1559033904863123000"
  },
  "ts_us": "1580390884335451",
  "ts_ns": "1580390884335451325",
}

{
  "source": {
    ...,
    "ts_us": "1559033904863123",
    "ts_ns": "1559033904863123000"
  },
  "ts_us": "1580390884335451",
  "ts_ns": "1580390884335451325",
}

エンベロープ値はマイクロ秒 (ts_us) とナノ秒 (ts_ns) の値を提供します。source 情報ブロックには、マイクロ秒とナノ秒の両方の精度値を含めることができます。ソースデータベースが十分な精度を提供しない場合、タイムスタンプ値はより低い精度に切り捨てられます。

Debezium の以前のバージョンでは、column.truncate.* 機能は切り捨て設定に基づいてスライスされた ByteBuffer を返しました。これは Avro を使用する場合には機能しましたが、コネクター設定が JsonConverter を使用した場合は、切り捨ては行われませんでした。なぜなら、JsonConverter が指定された スライス ではなく、基礎となる配列全体に対して操作されたからです。

列の切り捨てロジックにより、新しい配列に基づいて ByteBuffer が明示的に作成されるようになりました。この変更により、JsonConverter は Kafka へのシリアル化中に切り捨てられた列の値を反映できるようになります。

column.truncate.to.length.chars 設定プロパティーが改善され、以前サポートされていた文字列型に加えて、配列フィールド型もサポートされるようになりました。詳細は、Debezium ユーザーガイド の SQL ベースのソースコネクターに関するドキュメントを参照してください。

スナップショットプロセスは各コネクターのライフサイクルの不可欠な部分であり、データストア内に存在するすべての履歴データを収集して、指定されたターゲットシステムに送信できるようにします。以前のリリースでは、Debezium コネクターは一貫したスナップショットモードのセットをサポートしていませんでした。この一貫性の欠如は、複数のコネクタータイプを扱うユーザーにとって特に混乱を招きました。

このリリースでは、Debezium はすべてのコネクターに対して一貫したスナップショットモードのセットを実装します。同じスナップショットモードは、MySQL コネクターに固有の never モードを除き、すべてのコネクターで使用できます。その結果、以前は一部のコネクターでは使用できなかった when_needed などの特定のスナップショットモードが、どのコネクターでも使用できるようになりました。

デフォルトでは、スナップショットが完了すると、Debezium はすぐにストリーミングフェーズに移行します。スナップショットの終了とストリーミングフェーズの開始の間の遅延を指定するには、コネクター設定に streaming.delay.ms プロパティーを追加します。このプロパティーは、不要な再スナップショットを防止し、スナップショットからストリーミングへの移行中にコネクターの全体的な安定性を向上させるのに役立ちます。

このプロパティーを offset.flush.interval.ms プロパティーと組み合わせて使用し、ストリーミングが開始される前にオフセットが適切にフラッシュされるようにします。ストリーミングが開始される前に少なくとも 1 つのオフセットフラッシュ間隔が発生するようにするには、streaming.delay.ms の値を offset.flush.interval.ms よりわずかに大きい値に設定します。

一部のパイプラインでは、イベントの順序付けは消費アプリケーションにとって重要です。Kafka トピックの再パーティション化などの特定の操作により、データパイプライン内のイベントの通常の順序が乱れる可能性があります。アプリケーションがイベントの順序を再構築しようとすると、エラーが発生する可能性があります。

このリリースでは、トランザクションメタデータを有効にすると、メタデータイベントによってトランザクションの順序がエンコードされます。エンコードされた順序フィールドは、トランザクションのタイムラインを正しく再構築するために必要な情報をコンシューマーに提供します。

JDBC シンクコネクターは、ソース列を Kafka ARRAY ベースのペイロードフィールドタイプにマッピングする使用をサポートします。Debezium 2.7.3 では、設定を変更せずに、ARRAY ベースのフィールドをターゲットの PostgreSQL データベースにシリアル化できるようになりました。

増分スナップショットプロセスは、ソーステーブルまたはコレクションからデータセットの全体または一部を収集するための、さまざまなリカバリー状況で有用な役割を担っています。リレーショナルコネクターは、増分スナップショットシグナルに additional-conditions 値を指定してデータセットを制限し、特定のデータ行を対象とする再同期を実現するという考え方を長い間サポートしてきました。MongoDB でこれが可能になったことをお知らせします (DBZ-7138)。リレーショナルデータベースとは異なり、additional-conditions は JSON 形式で提供する必要があります。これは、増分スナップショットされるドキュメントのサブセットリストを取得するために、find 操作を使用して指定されたコレクションに適用されます。

このリリースから、Debezium MongoDB ExtractNewDocumentState 単一メッセージ変換では、delete イベントのイベントペイロードに _id 属性が追加されるようになりました。この属性の追加により、SMT が生成するイベントを消費アプリケーションがより有効に活用できるようになります。

「Oracle Real Application Clusters (RAC) のサポート」を参照してください。

Debezium は RAW 列タイプを一連のバイトとして扱うため、RAW 列を含む変更イベントでは BYTES のスキーマタイプが使用されます。消費アプリケーションが RAW 列のデータをどのように使用するかに関する情報がない場合、このデフォルトは理にかなっています。ただし、BYTES ではなく STRING 型として生成されたデータを使用するように設計されたアプリケーションをサポートするために、Debezium は、RAW 列を STRING ベースとして自動的に生成する RawToStringConverter を提供するようになりました。

コンバーターの設定方法は、Debezium ユーザーガイド を参照してください。

ROW_ID は、テーブルの存続期間中、テーブルのすべての行にわたって一意ではありませんが、テーブルと行のライフサイクルが非常に厳密に管理されている特定の状況で使用できます。コミュニティーのリクエストに応じて、Oracle コネクターの変更イベントソース情報ブロックに新しい row_id フィールドを追加しました。このフィールドには、次の条件に従って ROW_ID 値が設定されます。

基準に一致しないイベントには、オプション としてマークされているため、row_id フィールドは含まれません。

Debezium の以前のバージョンでは、Oracle コネクターは、コネクターユーザーアカウントのデフォルトのテーブルスペースに LogMiner フラッシュテーブルを作成するように設計されていました。DBA がフラッシュテーブルを別のテーブルスペースに移動したい場合、問題が発生する可能性があります。以前は、フラッシュテーブルを優先テーブルスペースに追加するには、いくつかの手順を実行する必要がありました。まず、ユーザーアカウントを変更して新しいデフォルトのテーブルスペースを指定するか、そのテーブルスペースを指定した別のアカウントを作成します。次に、正しい場所に配置されるようにテーブルを再作成する必要があります。

このリリース以降では、次の例に示すように、log.mining.flush.table.name プロパティーを使用してフラッシュテーブルを作成する場所を指定できます。

log.mining.flush.table.name=THE_OTHER_SCHEMA.LOG_MINING_FLUSH_TABLE

log.mining.flush.table.name=THE_OTHER_SCHEMA.LOG_MINING_FLUSH_TABLE

スキーマ名はオプションです。スキーマ名を指定しない場合、コネクターは従来の動作に従い、コネクターユーザーアカウントのデフォルトのテーブルスペースを使用してフラッシュテーブルを作成し、その存在を確認します。

Debezium Oracle コネクターは、単一のコネクターデプロイメントで数千のテーブルをサポートできます。ただし、IN モードを使用してクエリーフィルターをカスタマイズすることを推奨します。設定されたデータベースのテーブルに大量の変更が発生した場合、変更が処理のために Debezium に渡される前に、データベースレベルでそのデータセットをフィルター処理することを推奨します。

以前のバージョンでは、コネクターの log.mining.query.filter.mode が in に設定され、テーブルの include リストに 1000 を超える要素が含まれていると、SQL エラーが発生していました。Oracle では、IN 句内で 1000 を超える要素は許可されません。この制限に対処するために、Debezium 2.7.3 では、1000 項目の IN 句リストの複数のバケット間の論理和を使用します。

Debezium Oracle コネクターは、INSERT、UPDATE、および DELETE イベントレコードの source 情報ブロック内の操作の元の SQL を報告できるようになりました。変更イベントの一部として REDO SQL を含めるようにコネクターを設定するには、次の例に示すように log.mining.include.redo.sql プロパティーを設定します。

"log.mining.include.redo.sql": "true"

"log.mining.include.redo.sql": "true"

この機能はオプトインのみの機能です。使用するには、明示的に有効にする必要があります。

このオプションを有効にすると、次の例に示すように、source 情報ブロックに新しいフィールド redo_sql が含まれます。

"source": {
  ...
  "redo_sql": "INSERT INTO \"DEBEZIUM\".\"TEST\" (\"ID\",\"DATA\") values ('1', 'Test');"
}

"source": {
  ...
  "redo_sql": "INSERT INTO \"DEBEZIUM\".\"TEST\" (\"ID\",\"DATA\") values ('1', 'Test');"
}

LogMiner の使用時に、トランザクション登録の新しい遅延ストラテジーが追加されました。このストラテジーにより、コネクターがそのトランザクションの最初の変更をキャプチャーするまで、バッファー内のトランザクションレコードの作成が効果的に遅延されます。

トランザクション登録を遅らせることには、次のようないくつかの利点があります。

Debezium SQL Server コネクターは、fn_cdc_get_all_changes…​ と呼ばれる共通の SQL Server ストアドプロシージャーを使用して、特定のテーブルに関連するキャプチャーされた変更をすべて取得します。このクエリーは複数の結合を実行し、結合サブクエリーの 1 つからのみデータを返すため、非効率的になる可能性があります。

このコネクターのリリースでは、コネクターがテーブルの変更に関する詳細を収集するために使用する方法を指定する設定プロパティー data.query.mode が導入されています。デフォルトの動作は以前のリリースから変更されておらず、前述のストアドプロシージャーに委譲する値 function を使用して設定されます。

コネクターが変更を収集する効率を高めるには、data.query.mode の値を direct に設定して、コネクターがクエリーを内部的に構築するように設定します。

Debezium 2.7.3 では、heartbeat.action.query コネクター設定プロパティーのサポートが SQL Server コネクターに追加されました。heartbeat.action.query プロパティーにより、コネクターは、heartbeat.interval.ms で定義された間隔でソースデータベースへの書き込み操作を実行できます。書き込み操作は、コネクターによってキャプチャーされ、その後 Kafka またはターゲットシステムに送信される変更イベントを生成することを目的としています。

定期的に変更をキャプチャーしているアクティブなデータベースでは、変更のストリームが一定に保たれることで、オフセットをトランザクションログ内の読み取り位置と同期させることができます。ただし、コネクターがソースから変更をキャプチャーしている場合、キャプチャーされたテーブルよりもキャプチャーされていないテーブルで多くの変更が発生するため、heartbeat.action.query を設定すると、オフセット内の読み取り位置を低いキャプチャーアクティビティーと同期させることができます。

Debezium MongoDB コネクターの以前のイテレーションでは、変更ストリームをデプロイメントおよびデータベーススコープに対して開くことができましたが、権限が制限された環境では必ずしも理想的ではありませんでした。Debezium 2.7.3 では、コネクターが単一のコレクションの範囲内でのみ動作する新しい変更ストリームモードが導入され、このようなきめ細かい permissive 設定が可能になります。

MongoDB コネクターのキャプチャースコープを特定のコレクションに制限するには、コネクター設定の capture.scope プロパティーの値を collection に設定します。この設定は、コネクターが単一の MongoDB コレクションからのみ変更をキャプチャーすることを意図している場合に使用します。

この機能を使用する場合、一定の制限が存在します。capture.scope の値を collection に設定すると、コネクターはデフォルトの source シグナリング チャネルを使用できません。Kafka、JMX、または File チャネル経由で送信されるシグナルを含む増分スナップショットシグナルの処理を許可するには、コネクターの source チャネルを有効にする必要があります。したがって、コネクター設定で capture-scope プロパティーの collection オプションが設定されている場合、コネクターは増分スナップショットを実行できません。

スナップショットのパフォーマンスを向上させるために、MySQL コネクターは並列化を実装し、変更イベントのスナップショットを同時に作成して、テーブルのスキーマイベントを生成します。スナップショットを実行し、スキーマイベントを並行して生成することにより、コネクターはデータベース内の多数のテーブルのスキーマをキャプチャーするために必要な時間を短縮します。

MySQL の Debezium 初期スナップショットは常にシングルスレッドでした。この制限は主に、複数のトランザクション間でデータの一貫性を確保するのが複雑であることに起因します。

このリリースでは、複数のスレッドを使用してテーブルレベルのスナップショットを並列に実行するように MySQL コネクターを設定できます。

この新しい機能を活用するには、コネクター設定に snapshot.max.threads プロパティーを追加し、そのプロパティーを 1 より大きい値に設定します。

snapshot.max.threads=4

snapshot.max.threads=4

前の例の設定に基づいて、コネクターは一度に最大 4 つのテーブルのスナップショットを作成できます。スナップショットを作成するテーブルの数が 4 より大きい場合、スレッドは最初の 4 つのテーブルのうち 1 つの処理を完了した後、キュー内の次のテーブルを見つけてスナップショットの作成を実行し始めます。コネクターが指定されたすべてのテーブルでスナップショットの実行を完了するまで、プロセスは続行されます。

詳細は、Debezium ユーザーガイドの snapshot.max.threads を参照してください。

Oracle 用の Debezium コネクターは、実稼働データベースまたはプライマリーデータベースに接続するときに、内部フラッシュテーブルを使用して Oracle Log Writer Buffer (LGWR) プロセスのフラッシュサイクルを管理します。フラッシュプロセスでは、コネクターがデータベースにアクセスするために使用するユーザーアカウントに、このフラッシュテーブルの作成と書き込みの権限が必要です。ただし、論理スタンバイデータベースには制限的なデータ操作ルールが設定されていることが多く、読み取り専用の場合もあります。その結果、データベースへの書き込みが実行できなくなる可能性があります。

Oracle の読み取り専用論理スタンバイデータベースをサポートするために、Debezium はフラッシュテーブルの作成と管理を無効にするプロパティーを導入しています。この機能は、Oracle スタンドアロンインストールと Oracle RAC インストールの両方で使用できます。

Oracle コネクターが読み取り専用論理スタンバイを使用できるようにするには、次のコネクターオプションを追加します。

internal.log.mining.read.only=true

internal.log.mining.read.only=true

詳細は、Debezium ユーザーガイドの Oracle コネクターのドキュメント を参照してください。

LogMiner ハイブリッド マイニングストラテジーを使用するように。Oracle 用の Debezium コネクターを設定できるようになりました。このストラテジーは、デフォルトのマイニングストラテジーのすべてのスキーマ進化機能をサポートすると同時に、オンラインカタログストラテジーによって提供されるパフォーマンスの最適化も活用するように設計されています。このストラテジーを使用するようにコネクターを設定するには、log.mining.strategy 設定プロパティーを値 hybrid に設定します。

online_catalog ストラテジーでは、スキーマの変更とデータの変更が同じマイニングステップ内で発生する可能性があります。このような場合、LogMiner は SQL を正しく再構築できず、生成されるテーブルには OBJ# xxxxxx などの名前が割り当てられます。同様に、列は COL1、COL2 のように表されます。オンラインカタログストラテジーを使用する場合にこの状況を回避するには、マイニングステップでスキーマの変更とデータの変更の両方が同時に検出されないように、スキーマの変更を慎重に調整する必要がありますが、これは必ずしも実行可能ではありません。

対照的に、ハイブリッドストラテジーでは、データベースレベルでテーブルのオブジェクト ID を追跡し、この ID を使用して、Debezium リレーショナルテーブルモデルからテーブルに関連付けられたスキーマを検索します。したがって、Debezium は、これらの特定のコーナーケースで Oracle LogMiner が実行できないことを行うことができます。テーブル名はリレーショナルモデルのテーブル名から取得され、列は列の位置によってマップされます。

残念ながら、Oracle は、CLOB、BLOB、および XML データ型の失敗した SQL 操作を再構築する方法を提供していません。その結果、lob.enabled の値が true に設定されている場合は、hybrid ストラテジーを使用するようにコネクターを設定できません。hybrid ストラテジーを使用するように設定され、lob.enabled が true に設定されているコネクターを起動しようとすると、コネクターは起動に失敗し、設定エラーが報告されます。

このリリースでは、Debezium は PostgreSQL コネクターに対して 1 回限りのセマンティクスのサポートを提供します。PostgreSQL の 1 回限りの提供はストリーミングフェーズにのみ適用され、スナップショットには適用されません。

Debezium は、監視対象ソースで発生するすべての変更イベントをコネクターが確実にキャプチャーできるようにすることを目的として、少なくとも 1 回の配信を提供するように設計されています。KIP-618 では、Apache Kafka コミュニティーが、プロデューサーがメッセージを再試行するときに発生する問題に対処するためのソリューションを提案しています。ソースコネクターは、ブローカーが以前にバッチをコミットした後でも、イベントのバッチを Kafka ブローカーに再送信することがあります。この状況では、重複したイベントがコンシューマー (シンクコネクター) に送信され、重複を簡単に処理できないコンシューマーに問題が発生する可能性があります。

1 回限りの配信を有効にするためにコネクター設定を変更する必要はありません。ただし、Kafka Connect ワーカー設定で 1 回限りの配信を設定する必要があります。必要な Kafka Connect 設定プロパティーの設定に関する詳細は、KIP-618 を参照してください。