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

   Copy to Clipboard Toggle word wrap

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)

   Copy to Clipboard Toggle word wrap

3. kafka-console-consumer 를 실행하는 터미널로 전환하여 5번째 새 이벤트를 확인합니다.

   고객 테이블의 레코드를 변경하면 Debezium MySQL 커넥터가 새 이벤트를 생성했습니다. 두 개의 새로운 JSON 문서, 즉 하나는 이벤트의 키 용이고 다른 하나는 새 이벤트의 값 이어야 합니다.

   다음은 업데이트 이벤트의 키 세부 정보(읽성을 위해 포맷됨)입니다.

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

   Copy to Clipboard Toggle word wrap

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

   다음은 이 새로운 이벤트의 가치입니다. 스키마 섹션에는 변경 사항이 없으므로 페이로드 섹션만 표시됩니다( 읽기 쉽도록 포맷됨).

   {
     "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.1.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

   
     }
   }

   Copy to Clipboard Toggle word wrap

   1 1 1

   이제 before 필드에는 데이터베이스가 커밋되기 전에 값이 포함된 행 상태가 됩니다.

   2 2 2

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

   3 3 3

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

   4 4 4

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

   5 5 5

   ts_ms 필드는 Debezium이 이벤트를 처리할 때의 타임 스탬프를 보여줍니다.

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

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