3.2.4.6.5. 更新イベント
このテーブルの 更新 変更イベントの値には実際には同じ スキーマ があり、ペイロードは同じですが、異なる値を保持します。以下に例を示します。
{ "schema": { ... }, "payload": { "before": { "id": 1 }, "after": { "id": 1, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { "version": "1.1.2.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "snapshot": null, "db": "postgres", "schema": "public", "table": "customers", "txId": 556, "lsn": 24023128, "xmin": null }, "op": "u", "ts_ms": 1465584025523 } }
これを insert イベントの値と比較すると、payload
セクションにいくつかの違いが表示されます。
-
op
フィールド値はu
、更新によりこの行が変更されたことを示すようになりました。 -
この
before
フィールドには、データベースのコミット前に値がある行の状態が表示されますが、プライマリーキーコラムだけが対象になりますid
。これは、デフォルトで REPLICA IDENTITY であるためですDEFAULT
。
行のすべての列の以前の値を表示するには、最初に customers
テーブルを変更する必要があります。 ALTER TABLE customers REPLICA IDENTITY FULL
-
この
after
フィールドには更新された行の状態が使用されるようになりました。ここで、first_name
値は現在の状態であることを確認できAnne Marie
ます。 -
source
フィールド構造には以前のフィールドと同じフィールドがありますが、このイベントが WAL の別の位置にあるため、値は異なります。 -
は
ts_ms
、Debezium がこのイベントを処理したタイムスタンプを示しています。
本 payload
セクションのみで確認できる点がいくつかあります。コミットにより before
、と after
構造を比較して、この行で実際に何が変更されているかを判断できます。この source
構造では、この変更に関する PostgreSQL のレコード(トレース可能性の向上)について説明しますが、重要なことは、このイベントや他のトピックの他のイベントと比較し、他のトピックで発生したイベントが他のイベントとして発生したか、または他のイベントとして同じ PostgreSQL コミットの一部として確認できるようにすることができます。
行のプライマリー/一意キーの列が更新されると、行のキーの値が変更になり、Debezium は行の古いキーを持つ DELETE
イベント と、行の新しいキーの INSERT
イベント 3 つ のイベントを出力します。