重要

このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。

機能

Connect Oracle CDC Source Connector には、以下の機能があります。

redo ログトピック

コネクターは Oracle データベースの redo ログを読み取り、各行の redo ログイベントを別々の Kafka レコードとして書き込みます。コネクターは V$LOGMNR_CONTENTS ビューを照会します。一致したテーブルの 1 つに適用される結果セットの各行は、結果セットの各列のフィールドを使用してレコードに変換されます。コネクターは、"少なくとも 1 回" の保証を使用して、このトピックに書き込みます。コネクターは、再起動時に redo ログイベントレコードの一部を再書き込みすることがあります。

redo ログのトピックにアクセスするには、ACL でコネクターに対応する操作(CREATE、READ、WRITE など)のアクセス許可を付与する必要があります。出力トピックの場合、ACL でコネクターに CREATE または WRITE のアクセス許可を付与する必要があります。READ、WRITE または DELETE のアクセス許可が付与されると、コネクターは DESCRIBE 操作の権限を暗黙的に獲得します。詳細および ACL の例については、「Oracle CDC Source Connector の ACL」を参照してください。

注意

  • redo ログトピックは、コネクター間で共有しないでください。予期しない動作の原因となる場合があります。
  • 現在、コネクターがサポートしているのは 1 つのパーティションによる redo ログトピックへの書き込みのみです。
  • Confluent では、ログの保持ポリシーを 24 時間に増やすことを推奨しています。保持ポリシーが短く、テーブルに多数のアクティビティが含まれていない場合、コネクターは最後にコミットされた SCN を持つレコードを見つけることができない可能性があります。
  • When a connector is in the running state, you may not see a redo log topic being created (redo.log.topic.name). The connector will create the topic when a new INSERT, UPDATE, or DELETE is committed to the tables the connector is configured for. You may also create the topic with one partition before you run the connector.

redo ログの破損トピック

Oracle redo ログそのものが破損している可能性もあります。LogMiner が破損したブロックやセグメントを報告しても、コネクターは終了しません。破損したブロックの詳細をコネクターが別の Kafka トピックに書き込み、下流のコンシューマーがこの情報を使用して Oracle redo ログファイルの破損を追跡し、対応できるように構成することができます。

テーブル変更イベントトピック

コネクターは未加工のログを各テーブルの変更イベントに変え、構成した table-to-topic マッピングを使用してこれらのイベントを Kafka トピックに書き込むことができます。

取り込むテーブルのパターンマッチング

コネクター構成では 2 つの正規表現を使用して、データベース内でコネクターが取り込むテーブルを識別します。コネクターはデータベース内のテーブルを対象に、include 式で完全修飾名(<database-name>.<schema-name>.<table-name> など)が一致するすべてのテーブルからイベントを取り込みます。ただし、それらのテーブルが exclude 式との一致によって明示的に除外される場合を除きます。

テーブルの Kafka トピックへの柔軟なマッピング

コネクター構成は、イベントが書き込まれる Kafka トピックの名前を識別するテンプレートを指定します。このテンプレートは各変更イベントの名前に解決され、リテラルや template 変数 (スキーマ名、テーブル名、データベース名、さまざまなタイムスタンプ、トランザクション ID を含む)を使用できます。これにより、ユーザーは変更イベントが書き込まれる Kafka トピックの名前を柔軟に識別できるようになります。

レコードキー

コネクターが Kafka トピックに書き込むレコードは、データベース内の対応する行のプライマリキー列値に相当するキーを(デフォルトで)持っています。プライマリキーが単一列で構成される場合、Kafka レコードのキーにはその行の列の値が含まれます。プライマリキーが複数の列で構成される場合、Kafka レコードのキーは、プライマリキーの各列のフィールドが含まれる STRUCT になります。この動作は key.template 構成プロパティ を設定することで変更できます。他の Connect ソースコネクター同様、各レコードのキーはコネクターがレコードを書き込むトピックのパーティションを決定します。

スナップショット

コネクターを最初に起動すると、各テーブルの既存のすべての行のスナップショットの取得を試行し、それらをレコードとしてテーブルの Kafka トピックに書き込んだ後、それらの行に対する変更の取り込みを開始します。これにより、Kafka トピックにデータベーステーブルの各行のレコードが含まれるようになります。ただし、Kafka トピックが特定の時点のレコードのみを含めることが必要な場合は、start.from 構成プロパティ を使用して SCN またはタイムスタンプを指定できます。こうすると、コネクターがすべてのテーブルのイベントの取り込みを開始する時点が設定されます。

注釈

いずれかのテーブルのスナップショット実行中にコネクターの中断、停止、または障害が発生したら、リカバリまたは再起動時に、コネクターは未完了のすべてのスナップショットを最初から再開します。残念ながら、現在のところ、変更中のテーブルのスナップショットを再開する際に、そのテーブルへのすべての変更を確実に取り込むことは保証されません。

テーブルパーティションスナップショット

コネクターには、テーブルパーティションスナップショットの高度な機能が備わっています。コネクターはこの機能を使用して、Oracle でパーティション化された大きなテーブルのスナップショットを並列に実行し、これらのテーブルパーティションスナップショットをすべてのタスクに配信します。これにより、タスク数がリニアにスケーリングできるため、より多くのスナップショットがより多くのタスクで並列に実行されます。たとえば、コネクターは、多数のテーブルパーティション(たとえば、P=20)を含む 1 つの大きなテーブル(N=1)を、最大 P+1 個のタスクを使用して取り込み、スナップショットを作成できます。これにより、タスク数を増やすことで、スナップショットの実行に必要な全体の時間が短縮されます。

注釈

snapshot.by.table.partitions=true でコネクターを実行する場合は、事前にテーブル固有のトピックを作成します。テーブル固有のトピックを事前に作成しないと、パーティション化されたテーブルに割り当てられた一部のタスクが失敗します。また、対象のテーブルがすべてパーティション化されていることを確認してください。パーティション化されていないテーブルとパーティション化されているテーブルが混在している場合は、snapshot.by.table.partitions=false を使用します。プロパティの説明については、「snapshot.by.table.partitions」を参照してください。

ラージオブジェクトタイプ

バイナリラージオブジェクト(BLOB)、キャラクタラージオブジェクト(CLOB)、および各国語キャラクタラージオブジェクト(NCLOB)の各タイプの列を含むテーブルの変更を取り込むように、コネクターを構成できます。これらのラージオブジェクト(LOB)タイプは、下流のアプリケーションで消費できる別の LOB トピックに書き込まれます。この機能を有効にするには、lob.topic.name.template 構成プロパティ で使用するテンプレート変数を指定します(サポートされる変数については、「テンプレート変数」を参照)。有効にした場合、コネクターはトピックのキーを使って別のトピックに LOB オブジェクトを書き込みます。このトピックのキーは、テーブルのフルネーム、列名、LOB オブジェクト行の変更レコードのプライマリキーで構成されます。

注釈

  • ラージオブジェクト(LOB)タイプの列を含むテーブルにはプライマリキーが含まれている必要があります。
  • 1 KB を超えるサイズの LOB オブジェクトがサポートされています。enable.large.lob.object.supporttrue に設定されていることを確認してください。
  • LOB トピックと関連してプライマリキーを使用する場合は、プライマリキーの値をアップデートするときに注意してください。プライマリキーへのアップデートが処理されると、コネクターはアップデートされたレコードを変更イベントに送信しますが、LOB レコードキーを遡ってアップデートすることはありません。

自動テーブル設定の同期とタスクの再構成

コネクターの実行中に、Oracle データベースでテーブルを削除および作成することができます。コネクターは取り込み対象のテーブルに一致する、新たに追加されたテーブルや最近削除されたテーブルを、定期的にチェックします。コネクターが新規テーブルまたは削除されたテーブルを識別すると、タスクを自動的に再構成し、削除されたテーブルの監視を停止して、変更の取り込みを開始します。

スケーラブルなデータベースワークロード

コネクターは、コネクタータスクを使用して、少ないデータベースワークロードから大量のデータベースワークロードに拡張するように設計されています。コネクターは、わずか 1 つのタスク(tasks.max=1)を使用するように構成することも、またはすべてのテーブル変更を取り込むために必要なだけのタスクまで拡張することもできます。

タスクロードの再バランス微調整

起動時に、コネクターはそのタスクを各テーブルに均等に配分します。コネクターは各テーブルのスループットのばらつきと redo ログ内の各タスクの位置をモニタリングします。そして、頻繁に変更が発生するテーブルを別のタスクに割り当てることによって、すべてのコネクタータスクの負荷分散を自動的に試行します。

Kafka トピックの自動作成

ソースコネクターの書き込み先であるトピックのトピック設定を定義するコネクター構成に、ルールを含めることができます。

注釈

snapshot.by.table.partitions=true でコネクターを実行する場合は、事前にテーブル固有のトピックを作成します。テーブル固有のトピックを事前に作成しないと、パーティション化されたテーブルに割り当てられた一部のタスクが失敗します。また、対象のテーブルがすべてパーティション化されていることを確認してください。パーティション化されていないテーブルとパーティション化されているテーブルが混在している場合は、snapshot.by.table.partitions=false を使用します。プロパティの説明については、「snapshot.by.table.partitions」を参照してください。

自動再接続

データベースへの接続が中断または切断されたとき、コネクターは自動的に再接続することができます。接続が失われると、コネクターは停止し、切断警告メッセージやエラーメッセージをログに記録してから指数バックオフを使用して再接続を試行します。接続が再確立されると、コネクターは自動的に通常の操作を再開します。この動作を制御するのはいくつかの接続プロパティで、これには query.timeout.ms (デフォルトは 5 分)などがあります。

Oracle マルチテナント CDB/PDB アーキテクチャのサポート

Oracle では Oracle Database 12c 以上で マルチテナントアーキテクチャのサポート を提供しています。システムテーブルは単一のコンテナーデータベース(CDB)に格納されます。ユーザーテーブルは CDB に接続されたプラガブルデータベース(PDB)に格納されます。コネクターの各インスタンスは、1 つの PDB に常駐するユーザーテーブルを読み取ることができます。ユーザーテーブルが常駐する PDB の名前は、プロパティ oracle.pdb.name を使用して構成できます。CDB のシステムテーブルから、またはレガシー 11g データベースから読み取るには、oracle.pdb.name 構成プロパティを空白のままにしておきます。CDB、PDB、またはマルチテナントではないレガシーデータベースにアクセスするには、oracle.sid プロパティを Oracle システム ID(SID)に設定します。