From 3cf62c50fcecdfef4ab0a9f34cc0d4fcf01e2a45 Mon Sep 17 00:00:00 2001
From: dhyeonkim <dhyeonkim@smilegate.com>
Date: Tue, 13 Aug 2024 18:21:35 +0900
Subject: [PATCH] =?UTF-8?q?=EA=B8=B0=EB=B3=B8=EC=9D=B4=20=EC=A4=91?=
 =?UTF-8?q?=EC=9A=94=ED=95=98=EB=8B=A4=20[Kafka]?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 _posts/2024-05-07-KafkaCDC.md | 49 ++++++++++++++++++++++++++++-------
 _posts/2024-07-29-Kafka.md    |  4 +--
 2 files changed, 42 insertions(+), 11 deletions(-)

diff --git a/_posts/2024-05-07-KafkaCDC.md b/_posts/2024-05-07-KafkaCDC.md
index e1b003a..e66ac4c 100644
--- a/_posts/2024-05-07-KafkaCDC.md
+++ b/_posts/2024-05-07-KafkaCDC.md
@@ -130,7 +130,7 @@ insert into dbo.MEMBER_BASE(member_id, nickname) values (10, 'testNickname10');
 
 ![](https://github.com/K-Diger/K-Diger.github.io/blob/main/images/cdc/KafkaUIMessages.png?raw=true)
 
-```*json*
+```json
 "payload": {
   "before": null,
   "after": {
@@ -142,7 +142,7 @@ insert into dbo.MEMBER_BASE(member_id, nickname) values (10, 'testNickname10');
 위 항목으로 데이터가 어떻게 변경되었는지(생성, 변경, 삭제)를 파악할 수 있다.
 
 ### 생성
-```*json*
+```json
 "payload": {
   "before": null,
   "after": {
@@ -153,7 +153,7 @@ insert into dbo.MEMBER_BASE(member_id, nickname) values (10, 'testNickname10');
 ```
 
 ### 수정
-```*json*
+```json
 "payload": {
   "before": {
     "member_id": 1,
@@ -166,12 +166,43 @@ insert into dbo.MEMBER_BASE(member_id, nickname) values (10, 'testNickname10');
 ```
 
 ### 삭제
-```*json*
+```json
 "payload": {
-  "before": {
-    "member_id": 2,
-    "nickname": "testNickname2"
-  },
-  "after": null,
+    "before": {
+        "member_id": 2,
+        "nickname": "testNickname2"
+    },
+    "after": null,
 }
 ```
+
+---
+
+# 이론으로
+
+[로그 기반 CDC 5가지 장점](https://debezium.io/blog/2018/07/19/advantages-of-log-based-change-data-capture/)
+
+Debezium을 사용하는 Source CDC는 로그 기반으로 동작하게된다.
+
+즉, DBMS의 binlog를 활용하여 변경된 데이터를 감지하게 되는 것인데 이 방식의 구체적인 내용과 장점을 살펴본다.
+
+## Binary Log
+
+[MySQL 공식문서 - BinaryLog](https://dev.mysql.com/doc/refman/8.4/en/binary-log.html)
+
+Binary Log는 데이터베이스의 변경 사항을 기록하는 기능이다. 주로 소스 서버의 변경 사항을 레플리카 서버로 전송하는 데이터`복제`나 백업 이후의 변경 사항을 재실행하여 최신 상태로 `복구`할 때 활용된다.
+
+바이너리 로그는 예상치 못한 중단이 일어날 때를 대비하여 완전히 완료된 트랜잭션만 기록하고 다시 읽는 방식으로 동작한다.
+
+즉, 트랜잭션이 끝나지 않은 내용은 이후 BinaryLog에 기록되지 않아 DB에 적용되지 않는다.
+
+참고로, `Debezium`을 MySQL 사용하기 위해 Binary Log를 활용한다는 내용이었지만 `MSSQL`, `PostgreSQL`등 각자만의 Binary Log의 역할을 하는 개념을 도입시키거나 DBMS단위에서 자체적인 CDC를 제공한다.
+
+---
+
+## Global Transaction ID - GTID
+
+[MySQL 공식문서 - Replication](https://dev.mysql.com/doc/refman/8.4/en/replication.html)
+
+MySQL에서는 Binary Log방식이 아닌 Transaction ID를 통해 복제를 수행하는 GTID방식도 존재한다.
+
diff --git a/_posts/2024-07-29-Kafka.md b/_posts/2024-07-29-Kafka.md
index 06e8145..c117388 100644
--- a/_posts/2024-07-29-Kafka.md
+++ b/_posts/2024-07-29-Kafka.md
@@ -54,11 +54,11 @@ services:
         # 모든 리스너: 암호화되지 않은 PLAINTEXT 프로토콜 사용
         KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: 'CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT'
 
-        # 카프카가 수신할 주소와 포트 지정
+        # 브로커가 내부적으로 요청을 바인딩하는 주소
         # PLAINTEXT: 29092 포트, PLAINTEXT_HOST: 9092 포트 사용
         KAFKA_LISTENERS: 'PLAINTEXT://:29092,PLAINTEXT_HOST://:9092'
 
-        # 클라이언트에게 알릴 리스너 주소 지정
+        # 브로커를 외부(컨슈머)에 노출 시킬 주소:포트
         # ${EXTERNAL_IP}: 환경 변수, 실제 IP 주소로 대체
         KAFKA_ADVERTISED_LISTENERS: 'PLAINTEXT://${EXTERNAL_IP}:29092,PLAINTEXT_HOST://${EXTERNAL_IP}:9092'