4.3.5.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.0.3.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
  }
}

これを挿入イベントの値と比較すると、payload セクションにいくつかの違いがあります。

op フィールドの値は u になっており、更新によってこの行が変更されたことを示しています。
before フィールドは、データベースのコミット前の行と値の状態を表しています。
after フィールドは、更新された行の状態を持ち、ここで 電子メール 値が noreply@example.org になったことを確認できます。
source フィールド構造には以前と同じフィールドがありますが、このイベントはトランザクションログの異なる位置からのものであるため、値は異なります。
event_serial_no フィールドの値は 2 です。これは、内向きの 2 つのイベントで設定される update イベントが原因で、2 番目のイベントのみを公開します。詳細は、ソースのドキュメントを確認し、$operation フィールドを参照してください。
ts_ms は、Debezium がこのイベントを処理したタイムスタンプを示します。

この ペイロード のセクションを参照することで学習できる点がいくつかあります。before と after の構造を比較 する と、コミットが原因で、この行で実際に何が変更されたかを判断できます。source 構造は、この変更の記録（トレーサビリティーを提供）に関する情報を示しますが、これには、このトピックや他のトピックの他のイベントと比較できる情報が含まれており、このイベントが他のイベントの前、後、または一部として他のイベントとして発生したかどうかを確認できます。

注記

行のプライマリーキー/一意キーの列が更新されると、行のキーの値が変更されたため、Debezium は DELETE イベントと、行の古いキーを持つ tombstone イベントと、行の新しいキーを持つ INSERT イベントという 3 つ のイベントを出力します。

4.3.5.2.2. 更新イベント

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links