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 つ のイベントを出力します。
