2.2.4.6.6. イベントの削除
ここまでで、create と update イベントのサンプルを確認しました。次に、同じテーブルの 削除 イベントの値を見てみましょう。ここでも、値の schema 部分は create および update イベントと全く同じになります。
{
"schema": { ... },
"payload": {
"before": {
"id": 1
},
"after": null,
"source": {
"version": "1.0.3.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
}
}
ペイロード 部分を確認すると、create または updateイベントペイロードと比べて多くの違いがあります。
-
opフィールドの値はdになっており、この行が削除されたことを示しています。 -
beforeフィールドは、データベースのコミットで削除した行の状態を表しています。ここでも、REPLICA IDENTITY 設定によるプライマリーキー列のみが含まれます。 -
afterフィールドが null で、行が存在しなくなったことが分かります。 -
sourceフィールド構造には以前と同じ値が多数ありますが、ts_msフィールド、lsnフィールド、およびtxIdフィールドは変更されました。 -
ts_msは、Debezium がこのイベントを処理したタイムスタンプを示します。
このイベントでは、この行の削除の処理に使用できるあらゆる種類の情報をコンシューマーに提供します。
PK のないテーブルに注意してください。REPLICA IDENTITY DEFAULT の付いたテーブルからの削除メッセージは、パーツの 前 には指定されません（デフォルトの ID レベルの唯一のフィールドは PK であるため）、完全に空になるようにスキップされます。PK を REPLICA IDENTITY を設定せずにテーブルからのメッセージを FULL レベルに処理できるようにするには、以下を行います。
PostgreSQL コネクターのイベントは、Kafka ログコンパクション と動作するように設計されています。これにより、すべてのキーの最新のメッセージが保持される限り、古いメッセージを削除できます。これにより、トピックに完全なデータセットが含まれ、キーベースの状態のリロードに使用できるようにするとともに、 Kafka がストレージ領域を確保できるようにします。
行が削除された場合でも、Kafka は同じキーを持つ以前のメッセージをすべて削除できるため、上記の削除 イベントの値はログコンパクションで動作します。ただし、メッセージ値が null の場合のみ、Kafka は同じキーを持つ すべてのメッセージ を削除できることを認識します。これを可能にするために、PostgreSQL コネクターは、null 値以外で同じキーを持つ特別な廃棄( tombstone )イベントで 削除 イベントに従います。
