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": "1.5.4.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
     }
   }

   1

   before フィールドは、データベースのコミット前の行と値の状態を表しています。

   2

   after フィールドは、更新された行の状態を表し、first_name の値は Anne Marie になっています。

   3

   source フィールド構造には以前と同じ値が多数ありますが、ts_sec および pos フィールドは更新されています (他の状況では file が変更されることがあります)。

   4

   op フィールドの値は u になっており、更新によってこの行が変更されたことを示しています。

   5

   ts_ms フィールドは、Debezium がこのイベントを処理したときのタイムスタンプを表しています。

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

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