5.3.4.2.3. イベントの削除

これまでは、イベントの 作成 および 更新 の例を確認することができます。以下の例は、同じテーブルの 削除 イベントの値を示しています。繰り返しになると、値の schema 一部は create および update イベントと全く同じになります。

{
  "schema": { ... },
  },
  "payload": {
    "before": {
      "id": 1005,
      "first_name": "john",
      "last_name": "doe",
      "email": "noreply@example.org"
    },
    "after": null,
    "source": {
      "version": "1.1.2.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
  }
}

payload 部分を確認すると、イベントペイロードの 作成 または 更新 との違いが複数あります。

このイベントにより、コンシューマーがこの行の削除を処理するのに使用できるすべての情報が提供されます。

SQL Server コネクターのイベントは、Kafka ログの圧縮 と連携するように設計されています。これにより、すべてのキーの少なくとも最新のメッセージが保持されていれば、古いメッセージを削除することができます。これにより、Kafka はストレージ領域を回収でき、トピックに完全なデータセットが含まれ、キーベースの状態のリロードに使用できます。

行が削除されても、上記の delete イベント値はログの圧縮でも機能します。これは、Kafka が同じキーで以前のメッセージをすべて削除できるためです。しかし、メッセージ値が Kafka null では、同じキーを持つ すべてのメッセージ が削除できる場合にのみ使用されます。これを可能にするため、SQL Server コネクターは、常に同じキーではなく null 値を持つ特別な tombstone イベントで delete イベントに従います。