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. 업데이트된 고객 테이블 보기:

   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 문서가 표시되어야 합니다. 하나는 이벤트의 키 용이고 하나는 새 이벤트의 값에 대한 것입니다.

   다음은 업데이트 이벤트의 키 세부 정보입니다(읽기 쉽도록 형식 지정).

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

   이 키는 이전 이벤트의 키와 동일합니다.

   다음은 새 이벤트의 값 입니다. 스키마 섹션에 변경 사항이 없으므로 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.3.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 1 1

   이제 이전 필드에 데이터베이스 커밋 전에 값이 있는 행 상태가 있습니다.

   2 2 2

   이제 after 필드에 행의 업데이트된 상태가 있고 first_name 값은 이제 Anne she입니다.

   3 3 3

   소스 필드 구조에는 ts_sec 및 pos 필드가 변경되었음을 제외하고 이전과 동일한 값이 많이 있습니다(다른 상황에서 파일이 변경될 수 있음).

   4 4 4

   op 필드 값은 이제 u 이며 업데이트로 인해 이 행이 변경되었음을 나타냅니다.

   5 5 5

   ts_ms 필드는 Debezium이 이 이벤트를 처리할 때의 타임스탬프를 표시합니다.

   페이로드 섹션을 보면 업데이트 이벤트에 대한 몇 가지 중요한 사항을 확인할 수 있습니다.

   • 구조 이전 및 이후의 구조를 비교하면 커밋으로 인해 영향을 받는 행에서 실제로 변경된 내용을 확인할 수 있습니다.
   • 소스 구조를 검토하면 변경 사항에 대한 MySQL의 레코드에 대한 정보를 찾을 수 있습니다(추적 기능 제공).
   • 이벤트의 payload 섹션을 동일한 주제(또는 다른 주제)의 다른 이벤트와 비교하여 이벤트가 다른 이벤트와 동일한 MySQL 커밋 전, 이후 또는 일부인지 여부를 확인할 수 있습니다.