MySQL CDC to BigQuery: 주기적 동기화가 놓치는 것과 binlog가 해결하는 방법
MySQL CDC to BigQuery: what periodic syncs miss, and how binlog avoids it
MySQL에서 BigQuery로 데이터를 옮길 때 흔히 쓰는 주기적 동기화는 삭제된 행이나 중간 변경 상태를 놓치기 쉽고, 프로덕션 DB에 부하를 줍니다. 이 글은 MySQL의 binlog를 활용한 CDC(Change Data Capture)가 어떻게 모든 변경을 정확히 포착하는지, 필요한 MySQL 설정(ROW 포맷, FULL row image, 권한 등)과 BigQuery로 안정적으로 적재하는 방법을 단계별로 설명합니다. 또한 관리형 플랫폼(Erathos 등)이 server-id 충돌, binlog 보존 기간 등 복잡한 문제를 어떻게 처리하는지도 다룹니다.
제때 도착하지만 불완전한 데이터를 적재하는 파이프라인은 가끔 몇 분 늦어도 결코 틀리지 않는 파이프라인보다 나쁩니다.
- karakanb
고지: 저는 Bruin(https://github.com/bruin-data/bruin)의 공동 창업자이며, Erathos의 경쟁사입니다.
꽤 직설적인 마케팅 글로 보이지만, Erathos에 대해 알게 되어 기쁘게 놀랐습니다. 좋은 제품이네요!
저는 개인적으로 프로덕션 환경에서 CDC를 그다지 좋아하지 않습니다. 스트리밍 데이터 이동은 일반적으로 혼란을 일으키기 쉽고, 감사 로그 없이 하드 삭제하거나 업데이트/삭제에 타임스탬프가 없는 등 잘못된 데이터 패턴을 조장합니다. 이러한 패턴은 보통 배치 로드를 사용할 수 없는 이유이기도 합니다. CDC는 기본 데이터베이스에 대한 상당한 운영 이해를 요구하며, Erathos 팀이 기사에서 언급한 것과 같은 몇 가지 함정이 있습니다. 우리는 클라우드 플랫폼과 오픈소스 도구 모두에서 CDC를 제공하지만, 가능하다면 저는 항상 커서 값을 사용한 증분 배치 로드를 CDC 연결보다 선호합니다.
조직의 복잡성이나 레거시 데이터베이스 이유로 인해 CDC가 때때로 필요하다는 점은 이해하지만, 이것은 제 개인적인 선호일 뿐입니다.
독립 실행형 Go CLI로 실행되는 오픈소스 CDC 도구를 찾고 있다면 ingestr를 확인해 보세요: https://github.com/bruin-data/ingestr
- gpaulbagetti
같은 실패 패턴을 너무 많이 본 후에 쓴 글입니다: 대시보드에서는 멀쩡해 보이지만 binlog를 읽는 대신 스냅샷을 비교하고 있어서 삭제 및 중간 업데이트를 수개월 동안 조용히 놓치고 있는 MySQL 동기화 작업. CDC가 단지 "최종적 일관성"이 아니라 실제로 완전하려면 MySQL 쪽에서 무엇이 참이어야 하는지(행 이미지, binlog_row_value_options, server-id, 보존 기간) 정확히 설명하려고 했습니다. 댓글에서 더 깊이 다루어 드릴 수 있습니다.