4.3.5.2.3. 削除イベント

ここまでで、create と update イベントのサンプルを確認しました。次に、同じテーブルの 削除 イベントの値を見てみましょう。ここでも、値の schema 部分は create および update イベントと全く同じになります。

{
  "schema": { ... },
  },
  "payload": {
    "before": {
      "id": 1005,
      "first_name": "john",
      "last_name": "doe",
      "email": "noreply@example.org"
    },
    "after": null,
    "source": {
      "version": "1.0.3.Final",
      "connector": "sqlserver",
      "name": "server1",
      "ts_ms": 1559730445243,
      "snapshot": false,
      "db": "testDB",
      "schema": "dbo",
      "table": "customers",
      "change_lsn": "00000027:00000db0:0005",
      "commit_lsn": "00000027:00000db0:0007",
      "event_serial_no": "1"
    },
    "op": "d",
    "ts_ms": 1559730450205
  }
}

ペイロード 部分を確認すると、create または updateイベントペイロードと比べて多くの違いがあります。

このイベントでは、この行の削除の処理に使用できるあらゆる種類の情報をコンシューマーに提供します。

SQL Server コネクターのイベントは、Kafka ログコンパクション と動作するように設計されています。これにより、すべてのキーの最新のメッセージが保持される限り、古いメッセージを削除できます。これにより、トピックに完全なデータセットが含まれ、キーベースの状態のリロードに使用できるようにするとともに、 Kafka がストレージ領域を確保できるようにします。

行が削除された場合でも、Kafka は同じキーを持つ以前のメッセージをすべて削除できるため、上記の削除 イベントの値はログコンパクションで動作します。ただし、メッセージ値が null の場合のみ、Kafka は同じキーを持つ すべてのメッセージ を削除できることを認識します。これを可能にするには、SQL Server コネクターは、null 値以外で同じキーを持つ特別な廃棄( tombstone )イベントで 削除 イベントに従います。