4.2. データベースの更新および 更新 イベントの表示

手順

1. MySQL コマンドラインクライアントを実行しているターミナルで、以下のステートメントを実行します。

   mysql> UPDATE customers SET first_name='Anne Marie' WHERE id=1004;
   Query OK, 1 row affected (0.05 sec)
   Rows matched: 1  Changed: 1  Warnings: 0

2. 更新された customers テーブルを表示します。

   mysql> SELECT * FROM customers;
   +------+------------+-----------+-----------------------+
   | id   | first_name | last_name | email                 |
   +------+------------+-----------+-----------------------+
   | 1001 | Sally      | Thomas    | sally.thomas@acme.com |
   | 1002 | George     | Bailey    | gbailey@foobar.com    |
   | 1003 | Edward     | Walker    | ed@walker.com         |
   | 1004 | Anne Marie | Kretchmar | annek@noanswer.org    |
   +------+------------+-----------+-----------------------+
   4 rows in set (0.00 sec)

3. kafka-console-consumer を実行しているターミナルに切り替え、新しい 5 番目のイベントを確認します。

   customers テーブルのレコードを変更したため、Debezium MySQL コネクターが新しいイベントを生成しました。新しい JSON ドキュメントが 2 つあるはずです。1 つはイベントの キー のドキュメントで、もう 1 つは新しいイベントの 値 のドキュメントです。

   更新 イベントの キー の詳細は以下のとおりです (書式を調整して読みやすくしてあります)。

     {
       "schema": {
         "type": "struct",
         "name": "dbserver1.inventory.customers.Key"
         "optional": false,
         "fields": [
           {
             "field": "id",
             "type": "int32",
             "optional": false
           }
         ]
       },
       "payload": {
         "id": 1004
       }
     }

   この キー は、以前のイベントの キー と同じです。

   新しいイベントの 値 は次のとおりです。schema セクションには変更がないため、payload セクションのみを表しています (書式を調整して読みやすくしてあります)。

   {
     "schema": {...},
     "payload": {
       "before": {  1
         "id": 1004,
         "first_name": "Anne",
         "last_name": "Kretchmar",
         "email": "annek@noanswer.org"
       },
       "after": {  2
         "id": 1004,
         "first_name": "Anne Marie",
         "last_name": "Kretchmar",
         "email": "annek@noanswer.org"
       },
       "source": {  3
         "name": "2.7.3.Final",
         "name": "dbserver1",
         "server_id": 223344,
         "ts_sec": 1486501486,
         "gtid": null,
         "file": "mysql-bin.000003",
         "pos": 364,
         "row": 0,
         "snapshot": null,
         "thread": 3,
         "db": "inventory",
         "table": "customers"
       },
       "op": "u",  4
       "ts_ms": 1486501486308,  5
       "ts_us": 1486501486308910,  6
       "ts_ns": 1486501486308910814  7
     }
   }

   表4.1 更新 イベント値のペイロード内におけるフィールドの説明

   項目	説明
   1	before フィールドには、データベースがコミットされる前の行に存在する値が表示されます。元の first_name の値は Anne です。
   2	after フィールドには、変更イベント後の行の状態が表示されます。first_name の値は Anne Marie になりました。
   3	source フィールド構造体には以前と同じ値が多数ありますが、ts_sec および pos フィールドは更新されています (他の状況では file が変更されることがあります)。
   4	op フィールドの値は u になっており、更新によってこの行が変更されたことを示しています。
   5	ts_ms、ts_us、ts_ns フィールドは、Debezium がこのイベントを処理したタイミングを示すタイムスタンプを示します。

   payload セクションを見ると、更新 イベントに関する重要な情報を確認できます。

   • before と after 構造を比較することで、コミットが原因で影響を受けた行で実際に何が変更されたかを判断できます。
   • source 構造を確認して、MySQL の変更の記録に関する情報を確認できます (トレーサビリティーを提供)。
   • イベントの payload セクションと、同じトピック (または別のトピック) の他のイベントを比較することで、別のイベントと同じ MySQL コミットの前、後、または一部としてイベントが発生したかどうかを判断できます。