3.2.4.6.6. イベントの削除
そのため、イベントの 作成 および 更新 の例が見られました。ここでは、同じテーブルの 削除 イベントの値を確認します。繰り返し発生すると、値の schema 一部は create イベントおよび 更新 イベントと全く同じになります。
{
"schema": { ... },
"payload": {
"before": {
"id": 1
},
"after": null,
"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": 46523128,
"xmin": null
},
"op": "d",
"ts_ms": 1465581902461
}
}
payload 部分を確認すると、イベントペイロードの 作成 または 更新 との違いが複数あります。
-
opフィールド値はd、この行が削除されたことを表しています。 -
この
beforeフィールドには、データベースのコミットで削除された行の状態が表示されます。この場合も、REPLICA IDENTITY 設定によりプライマリーキー列のみが含まれます。 -
afterフィールドは null で、行が存在しなくなったことを表します。 -
sourceフィールド構造には、、およびtxIdフィールドの変更を除き、前ts_mslsnと同じ値の多くが含まれます。 -
は
ts_ms、Debezium がこのイベントを処理したタイムスタンプを示しています。
このイベントにより、コンシューマーがこの行の削除を処理するのに使用できるすべての情報が提供されます。
PK なしのテーブルには注意してください。REPLICA IDENTITY DEFAULT を持つテーブルからの削除メッセージには、before （デフォルト ID レベルの唯一のフィールドである PK がない）そのため、空としてスキップされます。PK のないテーブルからのメッセージを処理するには、REPLICA IDENTITY を FULL レベルに設定します。
PostgreSQL コネクターのイベントは、Kafka ログの圧縮 と連携するように設計されています。これにより、すべてのキーの少なくとも最新のメッセージが保持されていれば、古いメッセージを削除することができます。これにより、Kafka はストレージ領域を回収でき、トピックに完全なデータセットが含まれ、キーベースの状態のリロードに使用できます。
行が削除されても、上記の delete イベント値はログの圧縮でも機能します。これは、Kafka が同じキーで以前のメッセージをすべて削除できるためです。しかし、メッセージ値が Kafka null では、同じキーを持つ すべてのメッセージ が削除できる場合にのみ使用されます。これを可能にするために、PostgreSQL コネクターは、常に同じキーではなく null 値を持つ特別な tombstone イベントで delete イベントに従います。
