5.3.4.2.2. イベントの更新
このテーブルの 更新 変更イベントの値は実際には同じ スキーマ を持ち、ペイロードは同じですが、異なる値を保持します。以下に例を示します。
これを 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
イベントが出力されます。