5.3.4.2.2. イベントの更新

このテーブルの更新変更イベントの値は実際には同じ スキーマ を持ち、ペイロードは同じですが、異なる値を保持します。以下に例を示します。

{
  "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.1.2.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
  }
}

これを insert イベントの値と比較すると、payload セクションにいくつかの違いが表示されます。

op フィールド値は u、更新によりこの行が変更されたことを示すようになりました。
この before フィールドには、データベースのコミットの前に値が含まれる行の状態が含まれるようになりました。
この after フィールドには更新された行の状態が使用されるようになりました。ここで、email 値は現在の状態であることを確認でき noreply@example.orgます。
source フィールド構造には以前のフィールドと同じフィールドがありますが、イベントがトランザクションログ内の別の位置にあるため、値は異なります。
この event_serial_no フィールドにはの値があり 2ます。これは、背後にある 2 つのイベントで構成され、2 つ目のイベントのみを公開している更新イベントによって生じます。詳しくは、ソースのドキュメントを確認し、フィールドを参照してください $operation。
は ts_ms、Debezium がこのイベントを処理したタイムスタンプを示しています。

本 payload セクションのみで確認できる点がいくつかあります。コミットにより before、と after 構造を比較して、この行で実際に何が変更されているかを判断できます。source 構造は、この変更の SQL Server の記録に関する情報を提供します（トレース可能性の向上）。より重要なことは、このイベントを他のトピックの他のイベントと比較し、このイベントが他のイベントとして発生したかどうか、または他のイベントの一部として確認することができます。

注記

行のプライマリー/一意キーの列が更新されると、行のキーの値が変更され、Debezium は 3 つ のイベント（ DELETE イベントおよび行の古いキーを持つコンブロックイベント）を出力し、行の新しいキーを含む INSERT イベントが出力されます。

5.3.4.2.2. イベントの更新

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links