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

Debezium を実行するための Java 要件が変更されました。このリリース以降、すべての Debezium コネクターには Java 17 のランタイムベースラインが必要です。

新しいコネクターで Java 11 を使用すると、Kafka Connect はコネクターを見つけられずにサイレントに失敗します。コネクターはバイトコードエラーを報告しません。

Debezium Server を実行するには、Java 21 のランタイムベースラインが必要です。

以前のリリースでは、コネクターの再起動後、Debezium は Kafka ベースのシグナルを自動的に再処理していたため、意図しない副次的な影響が出てくる可能性がありました。このリリース以降、コネクターが停止した場合に Kafka ベースのシグナルを処理する際は、シグナルを再送信する必要があります。

増分スナップショットシグナルの非推奨の additional-condition フィールドは削除され、サポートされなくなりました。このフィールドは、テーブルごとに条件を指定できる新しい additional-conditions プロパティーに置き換えられました。古いフィールドを参照するスクリプトまたはワークフローがある場合は、新しいプロパティーを使用するようにそれらを更新します。

以前のバージョンの MariaDB および MysSQL ドキュメントでは、schema.history.internal.store.only.captured.databases.ddl プロパティーのデフォルト値が正しくありませんでした。正しいデフォルト値は false です。

この変更はコードには影響しませんが、以前にこのプロパティーを設定していた場合は、現在の設定を確認して、環境に最適な値が含まれていることを確認してください。詳細は、Debezium ユーザーガイドを参照してください。

Oracle コネクターのデフォルトのマイニングストラテジーは online_catalog になりました。以前にデフォルトの redo_log_catalog ストラテジーに依存していて、そのストラテジーを引き続き使用する場合は、コネクター設定で明示的に指定する必要があります。

詳細は、「新しいデフォルトのマイニングストラテジー (DBZ-3656)」 を参照してください。

以前のリリースで非推奨となった次の Oracle コネクター設定プロパティーは、Debezium 3.0.8 では削除されました。

ReselectColumnsPostProcessor の動作が変更されました。このリリースでは、ポストプロセッサーは、lob.enabled 設定プロパティーの値に関係なく、Oracle LOB 列を再選択するようになりました。この変更により、列再選択ポストプロセッサーを使用して、ストリーミング中に LOB 列をマイニングせずに LOB 列にデータを入力できるようになりました。

MariaDB のスタンドアロンコネクター実装が完全にサポートされるようになりました。

Oracle コネクターは、BLOB、CLOB、および NCLOB データ型の処理を完全にサポートするようになりました。詳細は、Debezium ユーザーガイドの Oracle バイナリーと文字 LOB タイプ を参照してください。

複数の並列スレッドを使用して初期スナップショットを実行する機能が一般提供され、MySQL と MariaDB を除くすべての Debezium SQL コネクターで利用可能となりました。Debezium MariaDB および MySQL コネクターの並列初期スナップショット は、開発者プレビュー機能として利用できます。

並列初期スナップショットを使用するようにコネクターを設定するには、コネクター設定の snapshot.max.threads プロパティーを 1 より大きい値に設定します。

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

JDBC シンクコネクターは、バッファーセットを使用して、ターゲットデータベースへの書き込みのスループットを向上させます。場合によっては、他のアプリケーションが特定の行またはテーブルをロックすると、これらのバッファーのフラッシュ操作で特定の例外が発生することがあります。ユーザーエクスペリエンスを向上させるために、コネクター用に次の 2 つの設定プロパティーが利用できるようになりました。

再試行機能はデフォルトで有効になっています。コネクターは、フラッシュ操作の再試行を最大 5 回試行します。再試行間の遅延は 1 秒です。コネクターがフラッシュ操作を再試行しないようにするには、flush.max.retries を 0 に設定してこの機能を無効にします。

Debezium 3.0.8 では、Oracle コネクターの log.mining.strategy プロパティーのデフォルト値が redo_log_catalog から、一般的にパフォーマンスの高い online_catalog オプションに変更されました。以前にデフォルトの redo_log_catalog ストラテジーを使用していて、その設定を保持する場合は、現行バージョンにアップグレードした後、log.mining.strategy プロパティーの値を redo_log_catalog に明示的に設定する必要があります。

以前のリリースでは、Oracle RAC ノードのフラッシュストラテジーが変更され、データベース管理者が Oracle RAC ノードをオフラインにするたびに 3 秒の遅延が強制されるようになりました。この一時停止中に、コネクターはログライター (LGWR) プロセスをフラッシュしようとします。ただし、LGWR バッファーがフラッシュされない場合でも一時停止が実装されます。RAC ノードはオフラインのときは redo ログに書き込むことができないため、この遅延によって不要な待機時間が発生しました。

Debezium 3.0.8 では、安定性を向上させるために、Oracle RAC ノードへのアクティブな接続に対してのみ 3 秒の遅延が課されるようになりました。その結果、管理者が RAC ノードをオフラインにすると、コネクターによる遅延が発生しなくなります。

Oracle では、LOB 列が NULL でないことを確認するために、EMPTY_CLOB() or EMPTY_BLOB() 関数 を使用して、テーブル内の CLOB または BLOB フィールドにデフォルト値を指定できます。以前の Debezium リリースでは、これらの特殊関数は評価されず、これらの列に null 値が含まれる可能性があるため、コネクターはこれらの列をオプションとしてマークしていました。

Debezium 3.0.8 以降、EMPTY_BLOB() または EMPTY_CLOB() 関数を使用して Oracle BLOB 列のデフォルト値を定義すると、コネクターはフィールドをオプションではないものとして発行するようになりました。結果の変更イベントのフィールドには、適切なデフォルト値 (空のバイト配列または空の文字列) が含まれます。

この機能は、新しいコネクター設定プロパティー snapshot.isolation.mode を追加することで、PostgreSQL のスナップショット分離サポートを提供するという長年の要望に対応します。4 つのスナップショット分離レベルのいずれかを指定することにより、初期およびアドホックブロッキングスナップショットを実行するときに、一貫性とパフォーマンスの必要性のバランスをとる方法を指定できるようになりました。

これらの分離レベルは、スナップショットの 整合性 と、スナップショット中にコネクターがソースデータを読み取るときにソースデータに適用するロックの種類 (存在する場合) を指定します。

たとえば、snapshot.isolation.mode を serializable に設定して厳密な分離とロックを強制し、スナップショットの実行中に管理者やユーザーがテーブルインデックスの作成などの操作を実行できないようにすることができます。または、最も制限の少ない read_uncommitted 設定を適用して、スナップショットがまだコミットされていないユーザートランザクションからデータを読み取ることを許可することもできます。このような「ダーティーリード」を許可すると、データの不整合が発生する可能性がありますが、同時に、データはロックされないため、スナップショットはデータベースのパフォーマンスに影響を与えません。

詳細は、PostgreSQL コネクターのドキュメントの snapshot.isolation.mode を参照してください。

PostgreSQL 15 では、次のデータ型を提供する pgvector エクステンションが導入されました。

Debezium 3.0.8 以降、PostgreSQL コネクターはこれらの pgvector データ型を使用するイベントのストリーミングをサポートします。コネクターは、これらのデータ型のいずれかに関係する操作の変更イベントレコードを発行するときに、次のリストのマッピングに従って、ソース内の各 vector 型をセマンティック型に変換します。

データベースで pgvector エクステンションを有効にした後は、Debezium が vector 値を変換するための追加の設定は必要ありません。詳細は、PostgreSQL コネクターのドキュメントの pgvector 型 を参照してください。

透過的データ暗号化 (TDE) は、SQL Server 2017 Enterprise Edition と、SQL Server 2019 および 2022 の Standard Edition と Enterprise Edition の両方で利用できます。その名前が示すように、TDE は自動的かつ透過的に動作し、データベースとトランザクションログに保存されているデータを暗号化します。データベースで TDE が有効になっている場合、権限のないユーザーはデータを読み取ることができません。同時に、適切に設定された Debezium SQL Server コネクターによるアクセスを含め、認可されたユーザーによるアクセスは影響を受けません。Debezium が TDE が有効になっている SQL Server データベースから変更をストリーミングできるようにするための特別な設定は必要ありません。つまり、TDE が有効になっていないデータベースにコネクターが接続でき、後でデータベースで TDE が有効になった場合でも、元のコネクター設定は引き続き機能します。

複数の SQL Server データベースからの変更をストリーミングするために単一のコネクターをデプロイするときに、各データベースタスクのシグナルチャネルを一意に識別できるようになりました。

Debezium SQL Server コネクターがシグナリングおよび通知操作で使用する MBean 名の形式が、タスクごとに一意性を保証するために変更されました。SQL Server はデータベースマッピングごとに一意のタスクの生成をサポートしているため、通常の JMX メトリクスは taskId 属性を使用して登録されます。過去のリリースでは、JMX シグナルチャネルはこれを反映しなかったため、コネクターが各タスクのチャネルを開始できない可能性がありました。MBean 名に taskId を追加すると、これらの操作が複数のデータベースにまたがる場合にコネクターが複数のタスクを使用できるようになります。詳細は、Debezium ユーザーガイドの Debezium SQL Server コネクタースキーマ履歴メトリクス を参照してください。

Debezium SQL Server コネクターのドキュメントに、スキーマ履歴 MBean 名 の形式が正しく記述されるようになりました。更新された説明では、名前にはスナップショットおよびストリーミングメトリクス MBean 名に存在する同じ task 属性が含まれるようになったことが指定されています。

PostgreSQL の特長は、送信ボックステーブルを作成せずに送信ボックスパターンを実装できるという点です。代わりに、データベースは pg_logical_emit_message 関数を使用して、論理メッセージを Write-Ahead Logging (WAL) に直接書き込むことができます。ただし、Debezium が WAL からこれらのイベントをキャプチャーすると、Kafka に送信するデータは一連のバイトとしてフォーマットされます。構造化されたメッセージを必要とするアプリケーションでは、この形式のデータを消費できない可能性があります。

新しい論理メッセージデコーダー SMT (DecodeLogicalDecodingMessageContent) は、PostgreSQL 固有の単一メッセージ変換です。この変換は、pg_logical_emit_message イベントバイトを構造化イベント形式に変換し、消費するアプリケーションが処理できるように設計されています。この方法では、物理的な送信ボックステーブルを作成せずに送信ボックスパターンを実装できます。詳細は、Debezium ユーザーガイドの PostgreSQL 論理デコードメッセージのバイナリーコンテンツのデコード を参照してください。

列の標準容量を超えるサイズのデータ型を格納するために、一部のデータベースでは、メインテーブル以外の外部の場所にサイズ超過データを格納するための特殊なメカニズムを使用します。たとえば、PostgreSQL では Oversized-Attribute Storage Technique (TOAST) が使用され、Oracle では Large Object (LOB) ストレージ、つまり Oracle Exadata Extended Strings が使用されます。

デフォルトでは、Debezium がサイズが大きすぎるデータフィールドを含むテーブル行の変更に応答してイベントレコードを発行すると、結果のイベントレコードには、SQL 操作によって変更されたサイズが大きすぎるデータフィールドの値のみが含まれます。コネクターは、テーブル操作によってサイズ超過データ列の値が変更された場合にのみ、これらの値を入力します。サイズ超過データ列の値が変更されない場合、コネクターはフィールドにプレースホルダーを挿入します。このプレースホルダーは、フィールドに値が含まれていないことを誤って示します。

変更イベントレコード内のサイズ超過データフィールドの値を入力するために、ReselectColumnsPostProcessor が導入されました。このポストプロセッサーでは、int および bigint 配列データ型の再選択がサポートされるようになりました。これにより、SQL 操作後に値が変更されない場合でも、これらのフィールドは常に入力されるようになります。

このリリースでは、MongoDB シンクコネクターの実装が導入されています。Debezium MongoDB シンクコネクターは、最初にイベントフラット化変換を適用せずに、Debezium コネクターによって発行された未加工の変更イベントを取り込むことができる点で、他のベンダーの実装とは異なります。MongoDB シンクコネクターは、列タイプの伝播などのネイティブ Debezium ソースコネクター機能を利用できるため、データパイプラインの処理フットプリントを削減し、設定を簡素化できる可能性があります。

使用するために追加のプラグインをインストールする必要がある JDBC シンクリレーショナルコネクターとは異なり、MongoDB シンクコネクターは MongoDB ソースコネクターと一緒に同じアーティファクトにバンドルされています。したがって、Debezium 3.0.8 MongoDB ソースコネクターをインストールすると、MongoDB シンクコネクターもインストールされます。

MongoDB シンクコネクターを使い始めるには、次のような最小限の設定が必要です。

{
  "connector.class": "io.debezium.connector.mongodb.MongoDbSinkConnector",
  "connection.string": "...",
  "topics": "topic1,topic2",
  "sink.database": "targetdb"
}

{
  "connector.class": "io.debezium.connector.mongodb.MongoDbSinkConnector",
  "connection.string": "...",
  "topics": "topic1,topic2",
  "sink.database": "targetdb"
}

次の設定プロパティーは必須です。

MySQL コネクターで並列スキーマスナップショットを使用する機能は、引き続き開発者プレビュー機能として提供されます。

スナップショットのパフォーマンスを向上させるために、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 コネクターが論理スタンバイから変更をキャプチャーする機能は、引き続き開発者プレビュー機能として利用できます。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 コネクターのドキュメント を参照してください。

このリリースでは、Debezium は開発者プレビュー機能として、PostgreSQL コネクターに 1 回限りのセマンティクスを引き続き提供します。PostgreSQL の 1 回限りの提供はストリーミングフェーズにのみ適用され、スナップショットには適用されません。

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

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