Debezium 개념정리

도입 배경

1. A DB에서 B DB로 데이터 동기화를 해야한다.

2. 테이블 단위로 이루어지며, A DB와 B DB가 버전이 다르다.(오라클/mysql 포함)

 

기존 방식

1. A DB의 기준 컬럼(시간)을 기준으로 전송 데이터를 읽어 가공&전송한다.  

2. 전송받은 데이터를 B DB에 기록한다.

 

Debezium

1. Debezium은

 database에서 발생하는 변경사항을 추적할 수 있는 일종의 Apache Kafka Connect의 source connector 이다.

2. 데이터베이스의 바이너리 로그파일을 기반으로 변경사항을 감지한다.

3. 변경사항 감지는 카프카 커넥터로 이루어진다.

4. 현재 적용 대상인 mysql은 binary log 파일에 모든 데이터베이스 변경사항이 기록되는데 Debezium이 해당 파일을 읽을 수 있도록 설정을 변경해야 한다.

 

[mysqld]
log_bin=/home/mariadb/mysql/mysql-bin (로그옵션을 꼭 켜준다)
binlog_format=ROW

 

Debezium with Kafka

 

도입 효과

1. 휴먼 에러를 줄일 수 있다. 기존 방식은 소스 기반이기 때문에, 컬럼 형변환 에러라던지 통신 로직 문제로 인한 에러가 있었다.
2. Master Slave 개념으로 작동하여, slave에서 데이터가 삭제되더라도 Master에 영향이 가지 않는다.
3. BIN로그 기반으로 작동하기 때문에 모든 이벤트를 핸들링 할 수 있다. 기존의 방식은 UPSERT 기본에, DELETE를 옵션으로 사용했었다.
4. Kafka 메시지 큐에 변경사항이 적재되어 변경사항 추적이 가능하다.
5. 테이블 별로 토픽이 생성되어, 모듈화가 용이하다.

 

 

넘아야 할 산

1. 복잡한 커넥터 JSON 설정 ( *.properties 형태로 관리 가능 여부 체크 중 )
2. AWS Kafka 적용 시 커스터마이징 가능 여부 
3. Master 커넥터 초기 설정 시 모든 DB의 DDL을 읽어온 후 whiteList의 DB 데이터를 추출(DB락 발생 및 큰 서버 부하발생)
4. 토픽명이 중복되면 kafka에러가 발생한다.
5. MariaDB bin로그 관리 전략 필요하다.