[Debezium] Mysql Binlog를 이용하여 특정 시점부터 다시 메세지 전송하는 방법 debezium with kafka connect는 디비지움의 offset (혹은 체크포인트)를 카프카 토픽(`offset.storage.topic으로 설정된 값`)에 저장한다. 이를 통해 디비지움이 재시작되면 offset 토픽에서 마지막으로 저장된 체크포인트부터 다시 카프카로 프로듀싱을 하게 되는데, 이때 몇가지 이슈가 발생해서 과거 시점부터 다시 빈로그를 프로듀싱 해야할 일이 발생했다. 공식 가이드 문서에 따르면 offset 카프카 토픽에 아래와 같은 데이터를 프로듀싱하면 된다고 나와있다. 다만 offset 토픽에 프로듀싱 해야하는 값들(ts_sec, file, pos, row, server_id, event)는 어디서 가지고 와야 하는지 나와있지 않아 여러가지 방법으로 처리한 결과를 정리해보고자 한.. [Debezium] Mysql의 Master-Slave 스위칭시 디비지움 동작 방식 회사에서는 Mysql 클러스터를 MHA로 구성해서 사용중이다. 마스터/슬레이브 모두 마스터용/슬레이브용 도메인에 연결되어있으며, failover로 인해 마스터-슬레이브간 스위칭 발생시 도메인도 함께 변경된다. 디비지움 POC를 진행하면서 Mysql의 마스터-슬레이브가 스위칭이 될때 디비지움이 어떻게 동작하는지, 정상적으로 CDC는 가능한지를 테스트 해보았고, 이것을 정리해 보고자한다. 보통 두가지 상황에서 마스터-슬레이브 스위칭이 발생한다. Master 장애 발생시 MHA 설정에 따른 Failover 시 대용량 테이블에 Alter를 수행하기 위해 실행하는 스위칭 두가지 상황에서 디비지움이 어떻게 동작하는지 확인해 보았다. 1. MHA Failover에 의한 마스터-슬레이브 스위칭 마스터에 장애가 발생하면.. [Docker] Apple M1, M2 CPU 도커 빌드 에러 해결 애플이 Intel CPU에서 자체 개발한 m1, m2 CPU를 탑재하게 되면서 발생하는 도커 문제 해결법에 대해 정리해보고자 한다. 문제1: /bin/sh: exec format error 에러 발생시 애플 m1 CPU에서 이미지 빌드후 Intel CPU가 장착된 장비에서 도커를 수행할 때 발생되는 문제이다. docker inspect {도커 이미지} | grep Architecture 검색된 결과를 보면 arm64 로 빌드되어있는것을 확인할 수 있는데, intel CPU에서 동작시키려먼 아키텍쳐가 amd64 이어야 한다. 해결방법: 도커 빌드시 platform을 지정하여 빌드한다. docker build --platform linux/amd64 -t {빌드 태그} . 문제2: ERROR [interna.. [Kubernetes] Statefulset에서 Local Persistent Volume 사용하기 쿠버네티스에 Mysql이나 Mongodb 같은 DB를 설치할때 statefulset을 이용하여 저장소를 구성할수 있다. 이때 Statefulset에서 사용하는 저장소를 NFS같은 네트워크 PV(Persistent Volume)을 설정하여 저장소를 구축할수 있지만, 좀더 나은 성능을 위해 쿠버네티스 노드의 로컬디스크를 이용하여 PV를 구성할 수도 있다. 오늘은 Local Persistent Volume을 구성하는 방법을 정리해보고자 한다. 1. Local Storage Class 생성 노드의 디스크를 Statefulset에서 바로 사용하려면 Local Storage Class를 생성해야 한다. 아래와 같은 yaml을 작성하여 Local Storage Class를 생성할 수 있다. kind: StorageC.. [Apache Avro] Avro 구조와 사용법 Apache Avro는 serialization library이다. Avro 특징 특징 json 형식으로 스키마를 지정하고 이 스키마 파일을 통해 serialize/deserialize 를 진행한다. java의 경우 플러그인을 통해 json 타입의 avro 스키마 파일을 읽고 .java 클래스를 생성할 수 있다. 장점 타 포멧 대비(ex. json) 데이터 사이즈가 컴팩트하다. Programing language에 상관없이 serialize/deserialize 가능하다.(자바에서 serialize 된 후 python에서 deserialize 가능) 다양한 데이터 타입을 지원한다. 스키마 변경을 유연하게 처리할 수 있다(Schema Evolution) 단점 binary 형태로 저장시 디버깅이 어렵다. J.. [Apache Hudi] 3-3. Components - Index Hudi에는 RDBMS와 비슷하게 인덱스가 존재한다. 다만 RDBMS의 index는 읽기성능을 위해 최적화 되어있다면, hudi는 Read & Write 성능을 위하여 인덱스를 사용한다. 예를 들어 인덱스는 hudi key(레코드 키 + 파티션 경로)를 파일 ID에 매핑하여, 데이터가 업데이트 될때, 어떤 파일을 업데이트 해야하는지 빠르게 찾아내어 write 성능을 높인다. 위 이미지에서 흰색 네모는 base file을, 노란색 네모는 update할 데이터를 나타낸다.(Merge On Read의 Delta file 이라고 보면될듯) 인덱스가 없는경우(우측) 모든 업데이트(25MB x 8 = 200MB)를 각 base파일에 머징을 시도하여 동일한 hudi key를 가진 데이터를 가진 데이터를 추려내 병합해.. [Apache Hudi] 3-2. Components - Table Type & Query Type hudi의 table과 Table 타입, 그리고 쿼리 타입에 대해 정리해보고자 한다. Table Type hudi는 두가지 테이블타입을 지원한다. Copy On Write: Columnar File Format(parquet)으로 데이터를 저장한다. 데이터를 쓸때 이전의 base file과 새로들어온 데이터를 병합하여 새로운 버전의 base file을 생성한다. Merge On Read: Columnar File Format(parquet) + Row Based File Format(avro)파일로 결합하여 저장된다. 업데이트 되는 신규 파일은 먼저 Avro포멧으로 생성된 Delta File에 먼저 쓰여지며, 이후 Compaction 작업을 통해 기존의 base file + Delta File을 병합하여.. [Apache Hudi] 3-1. Components - Timeline Timeline Hudi에서 발생한 모든 오퍼레이션을 저장하는 공간으로 basepath/.hoodie에 저장된다. 데이터가 인입되게 되면 타임라인에 어떤 작업이 수행되어는지를 모두 기록하고, base file에 실제 데이터를 저장하게 된다. timeline의 데이터는 모두 순차적으로 저장이 되게 된다. .hoodie 디렉토리 하위에 하나의 파일 형태로 저장되는것은 아니고, Action Type별로 파일이 생성되고 관리된다. Timeline Action Type COMMITS: 레코드들을 테이블에 Atomic 하게 쓰는 것을 의미한다. CLEANS: 오래된 버전의 파일을 제거하는 백그라운드 작업을 나타낸다. DELTA_COMMIT: 테이블 타입이 Merge On Write일 경우 delta log 파일에 .. 이전 1 2 3 4 ··· 8 다음
