ホーム
製品
Red Hat build of Debezium
1.9.7
Debezium ユーザーガイド
8.2.6.2. Debezium SQL Server 変更イベントの値

8.2.6.2. Debezium SQL Server 変更イベントの値

変更イベントの値はキーよりも若干複雑です。キーと同様に、値には schema セクションと payload セクションがあります。schema セクションには、入れ子のフィールドを含む、 Envelope セクションの payload 構造を記述するスキーマが含まれています。データを作成、更新、または削除する操作のすべての変更イベントには、Envelope 構造を持つ値 payload があります。

変更イベントキーの例を紹介するために使用した、同じサンプルテーブルについて考えてみましょう。

CREATE TABLE customers (
  id INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY,
  first_name VARCHAR(255) NOT NULL,
  last_name VARCHAR(255) NOT NULL,
  email VARCHAR(255) NOT NULL UNIQUE
);

このテーブルへの変更に対する変更イベントの値部分には、以下の各イベント型について記述されています。

作成イベント

以下の例は、customers テーブルにデータを作成する操作に対して、コネクターによって生成される変更イベントの値の部分を示しています。

{
  "schema": {


    "type": "struct",
    "fields": [
      {
        "type": "struct",
        "fields": [
          {
            "type": "int32",
            "optional": false,
            "field": "id"
          },
          {
            "type": "string",
            "optional": false,
            "field": "first_name"
          },
          {
            "type": "string",
            "optional": false,
            "field": "last_name"
          },
          {
            "type": "string",
            "optional": false,
            "field": "email"
          }
        ],
        "optional": true,
        "name": "server1.dbo.customers.Value",


        "field": "before"
      },
      {
        "type": "struct",
        "fields": [
          {
            "type": "int32",
            "optional": false,
            "field": "id"
          },
          {
            "type": "string",
            "optional": false,
            "field": "first_name"
          },
          {
            "type": "string",
            "optional": false,
            "field": "last_name"
          },
          {
            "type": "string",
            "optional": false,
            "field": "email"
          }
        ],
        "optional": true,
        "name": "server1.dbo.customers.Value",
        "field": "after"
      },
      {
        "type": "struct",
        "fields": [
          {
            "type": "string",
            "optional": false,
            "field": "version"
          },
          {
            "type": "string",
            "optional": false,
            "field": "connector"
          },
          {
            "type": "string",
            "optional": false,
            "field": "name"
          },
          {
            "type": "int64",
            "optional": false,
            "field": "ts_ms"
          },
          {
            "type": "boolean",
            "optional": true,
            "default": false,
            "field": "snapshot"
          },
          {
            "type": "string",
            "optional": false,
            "field": "db"
          },
          {
            "type": "string",
            "optional": false,
            "field": "schema"
          },
          {
            "type": "string",
            "optional": false,
            "field": "table"
          },
          {
            "type": "string",
            "optional": true,
            "field": "change_lsn"
          },
          {
            "type": "string",
            "optional": true,
            "field": "commit_lsn"
          },
          {
            "type": "int64",
            "optional": true,
            "field": "event_serial_no"
          }
        ],
        "optional": false,
        "name": "io.debezium.connector.sqlserver.Source",


        "field": "source"
      },
      {
        "type": "string",
        "optional": false,
        "field": "op"
      },
      {
        "type": "int64",
        "optional": true,
        "field": "ts_ms"
      }
    ],
    "optional": false,
    "name": "server1.dbo.customers.Envelope"


  },
  "payload": {


    "before": null,


    "after": {


      "id": 1005,
      "first_name": "john",
      "last_name": "doe",
      "email": "john.doe@example.org"
    },
    "source": {


      "version": "1.9.7.Final",
      "connector": "sqlserver",
      "name": "server1",
      "ts_ms": 1559729468470,
      "snapshot": false,
      "db": "testDB",
      "schema": "dbo",
      "table": "customers",
      "change_lsn": "00000027:00000758:0003",
      "commit_lsn": "00000027:00000758:0005",
      "event_serial_no": "1"
    },
    "op": "c",


    "ts_ms": 1559729471739

}
}

Expand

表8.6 作成イベント値フィールドの説明
項目	フィールド名	説明
1	`schema`	値のペイロードの構造を記述する、値のスキーマ。変更イベントの値スキーマは、コネクターが特定のテーブルに生成するすべての変更イベントで同じになります。
2	`name`	`スキーマ` セクションで、各 `name` フィールドは、値のペイロードのフィールドのスキーマを指定します。 `server1.dbo.customers.Value` はペイロードの`before` および `after` フィールドのスキーマです。このスキーマは `customers` テーブルに固有です。 `before` および `after` フィールドのスキーマ名は`logicalName.database-schemaName.tableName.Value` の形式を取るので、スキーマ名がデータベースで一意になるようにします。つまり、Avro コンバーターを使用する場合、各論理ソースの各テーブルの Avro スキーマには独自の進化と履歴があります。
3	`name`	`io.debezium.connector.sqlserver.Source` は、ペイロードの `source` フィールドのスキーマです。このスキーマは、SQL Server コネクターに固有です。コネクターは生成するすべてのイベントにこれを使用します。
4	`name`	`server1.dbo.customers.Envelope` は、ペイロードの全体的な構造のスキーマで、`server1` はコネクター名、`dbo` はデータベーススキーマ名、`customers` はテーブルを指します。
5	`payload`	値の実際のデータ。これは、変更イベントが提供する情報です。イベントの JSON 表現はそれが記述する行よりもはるかに大きいように見えることがあります。これは、JSON 表現にはメッセージのスキーマ部分とペイロード部分を含める必要があるためです。しかし、Avro コンバーターを使用すると、コネクターが Kafka トピックにストリーミングするメッセージのサイズを大幅に小さくすることができます。
6	`before`	イベント発生前の行の状態を指定する任意のフィールド。この例のように、`op` フィールドが create (作成) の `c` である場合、この変更イベントは新しい内容に対するものであるため、`before` は `null` になります。
7	`after`	イベント発生後の行の状態を指定する任意のフィールド。この例では、`after` フィールドには、新しい行の `id`、`first_name`、`last_name`、および `email` 列の値が含まれます。
8	`source`	イベントのソースメタデータを記述する必須のフィールド。このフィールドには、イベントの発生元、イベントの発生順序、およびイベントが同じトランザクションの一部であるかどうかなど、このイベントと他のイベントを比較するために使用できる情報が含まれています。ソースメタデータには以下が含まれています。 Debezium バージョンコネクター型および名前データベースおよびスキーマ名データベースに変更が加えられた時点のタイムスタンプイベントがスナップショットの一部であるか新しい行が含まれるテーブルの名前サーバーログオフセット
9	`op`	コネクターによってイベントが生成される原因となった操作の型を記述する必須文字列。この例では、`c` は操作によって行が作成されたことを示しています。有効な値は以下のとおりです。 `c` = create `u` = update `d` = delete `r` = read (読み取り、スナップショットのみに適用)
10	`ts_ms`	コネクターがイベントを処理した時間を表示する任意のフィールド。イベントメッセージエンベロープでは、Kafka Connect タスクを実行している JVM のシステムクロックを基にします。 `source` オブジェクトで、`ts_ms` は変更がデータベースにコミットされた時刻を示します。`payload.source.ts_ms` の値を `payload.ts_ms` の値と比較することにより、ソースデータベースの更新と Debezium との間の遅延を判断できます。

更新イベント

サンプル customers テーブルにある更新の変更イベントの値には、そのテーブルの作成イベントと同じスキーマがあります。同様に、イベント値のペイロードは同じ構造を持ちます。ただし、イベント値ペイロードでは更新イベントに異なる値が含まれます。以下は、コネクターによって customers テーブルでの更新に生成されるイベントの変更イベント値の例になります。

{
  "schema": { ... },
  "payload": {
    "before": {


      "id": 1005,
      "first_name": "john",
      "last_name": "doe",
      "email": "john.doe@example.org"
    },
    "after": {


      "id": 1005,
      "first_name": "john",
      "last_name": "doe",
      "email": "noreply@example.org"
    },
    "source": {


      "version": "1.9.7.Final",
      "connector": "sqlserver",
      "name": "server1",
      "ts_ms": 1559729995937,
      "snapshot": false,
      "db": "testDB",
      "schema": "dbo",
      "table": "customers",
      "change_lsn": "00000027:00000ac0:0002",
      "commit_lsn": "00000027:00000ac0:0007",
      "event_serial_no": "2"
    },
    "op": "u",


    "ts_ms": 1559729998706

}
}

Expand

表8.7 更新イベント値フィールドの説明
項目	フィールド名	説明
1	`before`	イベント発生前の行の状態を指定する任意のフィールド。更新イベント値の `before` フィールドには、各テーブル列のフィールドと、データベースのコミット前にその列にあった値が含まれます。この例では、`email` の値は `john.doe@example.org` です。
2	`after`	イベント発生後の行の状態を指定する任意のフィールド。`before` と `after` の構造を比較すると、この行への更新内容を判断できます。この例では、`email` の値は `noreply@example.org` です。
3	`source`	イベントのソースメタデータを記述する必須のフィールド。`source` フィールド構造には create イベントと同じフィールドがありますが、一部の値が異なります。たとえば、更新イベントサンプルのオフセットは異なります。ソースメタデータには以下が含まれています。 Debezium バージョンコネクター型および名前データベースおよびスキーマ名データベースに変更が加えられた時点のタイムスタンプイベントがスナップショットの一部であるか新しい行が含まれるテーブルの名前サーバーログオフセット `event_serial_no` フィールドは、同じコミットおよび変更 LSN を持つイベントを区別します。このフィールドの値が `1` 以外である場合に典型的な状況です。更新によって SQL Server の CDC 変更テーブルに 2 つのイベントが生成されるため、更新イベントの値は `2` に設定されています (詳細はソースドキュメントを参照してください)。最初のイベントには古い値が含まれ、2 番目のイベントには新しい値が含まれます。コネクターは最初のイベントの値を使用して 2 つ目のイベントを作成します。コネクターは最初のイベントを破棄します。プライマリーキーが更新されると、SQL Server は 2 つのイベントを生成します。古いプライマリーキーを持つレコードを削除するための削除イベントと、新しいプライマリーキーを持つレコードを追加するための作成イベント。どちらの操作も同じコミットおよび変更 LSN を共有します。イベント番号はそれぞれ `1` および `2` です。
4	`op`	操作の型を記述する必須の文字列。更新イベントの値では、 `op` フィールドの値は `u` で、更新によってこの行が変更したことを示します。
5	`ts_ms`	コネクターがイベントを処理した時間を表示する任意のフィールド。イベントメッセージエンベロープでは、Kafka Connect タスクを実行している JVM のシステムクロックを基にします。 `source` オブジェクトで、`ts_ms` は変更がデータベースにコミットされた時刻を示します。`payload.source.ts_ms` の値を `payload.ts_ms` の値と比較することにより、ソースデータベースの更新と Debezium との間の遅延を判断できます。

注記

行のプライマリーキー/一意キーの列を更新すると、行のキーの値が変更されます。キーが変更されると、3 つ のイベントが Debezium によって出力されます。3 つのイベントとは、削除イベント、行の古いキーを持つ廃棄 (tombstone) イベント、および行の新しいキーを持つ作成イベントです。

削除イベント

削除変更イベントの値は、同じテーブルの作成および更新イベントと同じ schema の部分になります。サンプル customers テーブルの削除イベントの payload 部分は以下のようになります。

{
  "schema": { ... },
  },
  "payload": {
    "before": { <>
      "id": 1005,
      "first_name": "john",
      "last_name": "doe",
      "email": "noreply@example.org"
    },
    "after": null,


    "source": {


      "version": "1.9.7.Final",
      "connector": "sqlserver",
      "name": "server1",
      "ts_ms": 1559730445243,
      "snapshot": false,
      "db": "testDB",
      "schema": "dbo",
      "table": "customers",
      "change_lsn": "00000027:00000db0:0005",
      "commit_lsn": "00000027:00000db0:0007",
      "event_serial_no": "1"
    },
    "op": "d",


    "ts_ms": 1559730450205

}
}

Expand

表8.8 削除イベント値フィールドの説明
項目	フィールド名	説明
1	`before`	イベント発生前の行の状態を指定する任意のフィールド。削除イベント値の `before` フィールドには、データベースのコミットで削除される前に行にあった値が含まれます。
2	`after`	イベント発生後の行の状態を指定する任意のフィールド。削除イベント値の `after` フィールドは `null` で、行が存在しないことを示します。
3	`source`	イベントのソースメタデータを記述する必須のフィールド。削除イベント値の `source` フィールド構造は、同じテーブルの作成および更新イベントと同じになります。多くの `source` フィールドの値も同じです。削除イベント値では、`ts_ms` および `pos` フィールドの値や、その他の値が変更された可能性があります。ただし、削除イベント値の `source` フィールドは、同じメタデータを提供します。 Debezium バージョンコネクター型および名前データベースおよびスキーマ名データベースに変更が加えられた時点のタイムスタンプイベントがスナップショットの一部であるか新しい行が含まれるテーブルの名前サーバーログオフセット
4	`op`	操作の型を記述する必須の文字列。`op` フィールドの値は `d` で、行が削除されたことを示します。
5	`ts_ms`	コネクターがイベントを処理した時間を表示する任意のフィールド。イベントメッセージエンベロープでは、Kafka Connect タスクを実行している JVM のシステムクロックを基にします。 `source` オブジェクトで、`ts_ms` は変更がデータベースに加えられた時間を示します。`payload.source.ts_ms` の値を `payload.ts_ms` の値と比較することにより、ソースデータベースの更新と Debezium との間の遅延を判断できます。

SQL Server コネクターイベントは、Kafka ログコンパクションと動作するように設計されています。ログコンパクションにより、少なくとも各キーの最新のメッセージが保持される限り、一部の古いメッセージを削除できます。これにより、トピックに完全なデータセットが含まれ、キーベースの状態のリロードに使用できるようにするとともに、Kafka がストレージ領域を確保できるようにします。

廃棄 (tombstone) イベント

行が削除された場合でも、Kafka は同じキーを持つ以前のメッセージをすべて削除できるため、削除イベントの値はログコンパクションで動作します。ただし、Kafka が同じキーを持つすべてのメッセージを削除するには、メッセージの値が null である必要があります。これを可能にするために、Debezium の SQL Server コネクターは削除イベントを出力した後に、 null 値以外の同じキーを持つ、特別な廃棄 (tombstone) イベントを出力します。

8.2.6.2. Debezium SQL Server 変更イベントの値

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links