Bong's Log

MySQL/MariaDB 환경에서 데이터 백업을 위한 대표적인 두 가지 방법은 mysqldump와 mydumper입니다.

이번 글에서는 각 도구의 특징과 실제 사용 사례, 그리고 복원 시 myloader를 사용하는 구조까지 함께 살펴보며 어떤 상황에 어떤 도구를 선택하는 것이 좋을지 정리해 보겠습니다.

1. mysqldump: MySQL 기본 제공 백업 도구

특징

• MySQL 클라이언트에 기본 내장
• 텍스트 기반 SQL 파일로 백업
• 단일 스레드로 작동
• 다양한 백업 옵션 제공 (--no-data, --routines, --triggers 등)

백업 예시

mysqldump -u root -p \
  --single-transaction --routines --triggers --events \
  --default-character-set=utf8mb4 \
  mydb > /backup/mydb_dump.sql

복원

mysql -u root -p mydb < /backup/mydb_dump.sql

장점

• 간단하고 범용적으로 사용 가능
• SQL 기반으로 관리 및 버전 관리 용이
• 설치 필요 없음

단점

• 대용량 백업 시 느림
• 트랜잭션 중단 시 복원 실패 가능
• 복잡한 외래키/관계로 인한 복원 순서 문제 발생 가능

2. mydumper + myloader: 멀티스레드 기반 고속 백업/복원

특징

• 멀티스레드로 병렬 백업 및 복원 지원
• 테이블/쿼리 단위로 파일 분리
• DDL(스키마)와 데이터 분리 백업 가능 (--no-schemas)
• 별도 설치 필요

백업 예시

mydumper \
  -h mydbhost \
  -u myuser \
  -p mypass \
  -B mydb \
  -o /backup/mydb \
  --threads 4 \
  --compress \
  --no-schemas

복원 예시

myloader \
  -h mydbhost \
  -u myuser \
  -p mypass \
  -B mydb \
  -d /backup/mydb \
  --threads 4

장점

• 대용량에서도 빠른 백업/복원 가능
• 병렬 처리로 시간 단축
• 락 최소화 옵션 제공 (--less-locking, --use-savepoints 등)
• 백업 데이터 관리 유연성 높음

단점

• 별도 설치 필요
• 결과물이 SQL이 아닌 구조화된 파일이라 가독성 낮음
• 복원 시 myloader 필수

실전 전략: DDL 분리 + 데이터 병렬 백업

대부분 실무에서는 DDL과 데이터를 분리해 백업합니다. 그 이유는 다음과 같습니다:

• 외래키, 트리거 등으로 인해 데이터 삽입 전에 테이블 구조를 먼저 정의해야 함
• 순서 제어 가능 (DDL → 데이터 → 기타 오브젝트)

비교 요약표

결론 및 추천

마무리

mysqldump는 여전히 유용한 기본 도구지만, 대용량이나 성능 최적화가 필요한 환경에서는 mydumper 조합이 훨씬 효과적입니다. 또한, 트리거, 제약조건, 외래키 순서에 민감한 환경에서는 DDL과 데이터를 분리하는 전략이 안정성과 확장성을 동시에 확보할 수 있는 좋은 방법입니다.

MySQL이나 MariaDB 기반의 시스템을 운영하다 보면, 데이터 동기화나 변경 추적을 위한 기술을 고민하게 됩니다. 이때 자주 언급되는 두 가지 기술이 바로 Replication(복제)과 CDC(Change Data Capture)입니다. 얼핏 비슷해 보이지만 실제로는 적용 목적도, 구성 방식도 많이 다릅니다. 오늘은 이 두 기술의 차이점에 대해 실무 관점에서 정리해보겠습니다.

1. 개념 비교

2. 기술적 구성 차이

Replication

• MySQL이나 MariaDB에서 log_bin 활성화 후, CHANGE MASTER TO, START SLAVE 명령어로 구성
• 보통 마스터 DB의 변경을 슬레이브에 그대로 복사 (read-only 용도로 활용)
• DB 시스템 내부 기능이므로 설치가 간단하고 신뢰성이 높음

CDC

• binlog를 읽어 변경 이벤트만 추출
• Kafka, Debezium, Event Hub 등과 연동해 외부 시스템으로 실시간 전송
• 데이터 분석, 로그 수집, 실시간 대시보드 구성에 매우 유용
• 일반적으로 Kafka 기반 스트리밍 구조로 구성되며, 컨테이너 기반의 설치가 많음

3. 언제 어떤 기술을 쓸까?

4. Azure 환경에서의 구성 팁

• Replication: Azure Database for MySQL(Flexible Server)은 자체적으로 읽기 복제본을 생성 가능. 수동 복제 구성 시에는 VM 또는 외부 MySQL 인스턴스를 사용해야 함
• CDC: Azure에서는 AKS나 Azure Container Instances 위에 Kafka + Debezium 환경을 구성하고, Event Hub나 Azure Functions와 연계해 확장성 있는 아키텍처 구성 가능

5. Oracle에서는?

Oracle DB에서는 "Replication"이라는 용어보다는 다음과 같은 유사 기술명이 사용됩니다.

특히 GoldenGate는 Oracle에서 가장 강력한 CDC 및 복제 솔루션으로, 실시간 데이터 동기화뿐 아니라 이기종 DB 간 연계에도 사용됩니다. Data Guard는 고가용성 및 재해 복구 목적의 물리적/논리적 스탠바이 구성을 지원합니다.

6. DB 마이그레이션 시 Replication과 CDC의 활용 전략

DB 마이그레이션에서는 데이터 정합성을 유지하면서도 서비스 중단을 최소화하는 것이 핵심입니다. 이 과정에서 Replication과 CDC는 각각 다른 목적에 따라 유용하게 활용될 수 있습니다.

Replication 활용

• 기존 서비스의 중단 없이 새로운 DB로 데이터를 동기화하고자 할 때 효과적입니다.
• 예를 들어, MariaDB에서 MySQL로 이관 중이라면, 복제 구성을 통해 마스터(MariaDB)에서 슬레이브(MySQL)로 데이터를 실시간 반영해 두고, 마이그레이션 완료 후 역할을 전환하는 방식으로 사용할 수 있습니다.
• 단방향 동기화에 적합하며, 마이그레이션 후 즉시 전환 가능한 장점이 있습니다.

CDC 활용

• 마이그레이션 중 또는 이후에도 기존 DB에서 발생하는 변경 사항을 외부 시스템에 연동하거나, 이관된 DB의 데이터 변경 내역을 모니터링하고자 할 때 유용합니다.
• 특히 Kafka 기반 구조를 이미 사용 중이라면, CDC를 이용해 양쪽 시스템의 데이터 동기화를 더 유연하게 처리할 수 있습니다.
• 데이터 흐름이 복잡하거나 다양한 시스템과 연계되는 데이터 파이프라인이 필요할 때 추천됩니다.

활용 판단 기준 요약

마이그레이션을 위한 1회성 복제라면 Replication이 간편하고 실용적이며, 데이터 흐름 확장이나 실시간 변경 처리 체계를 만들고자 한다면 CDC가 더 적합합니다.

마무리

Replication과 CDC는 모두 데이터의 일관성이나 동기화라는 공통된 목적을 가지고 있지만, 사용하는 방식과 적용 대상은 매우 다릅니다. 단순한 DB 복제가 목적이라면 Replication으로도 충분하지만, 다양한 시스템과 연계되거나 실시간 처리가 필요한 경우에는 CDC가 더 강력한 도구가 될 수 있습니다. 자신의 시스템 목적에 맞는 방식을 선택하는 것이 가장 중요합니다.

MariaDB에서 MySQL로 사용자 계정과 권한을 이관할 때 핵심은 다음 두 가지입니다:

1. 사용자 정보와 권한을 쿼리로 추출하여 이관
2. 비밀번호는 새로 설정하는 방식으로 안전하게 적용

이 글에서는 사용자와 권한 정보를 효율적으로 옮기는 방법과, 왜 해시 복사보다 비밀번호 재설정이 바람직한지 설명합니다.

사용자 계정 및 권한 추출 쿼리

1. 사용자 계정 추출 (비밀번호 새로 설정 전용)

SELECT CONCAT('CREATE USER '', user, ''@'', host, '' IDENTIFIED BY '새비밀번호';')
FROM mysql.user
WHERE user NOT IN ('mysql.sys', 'mysql.session', 'root');

• 새비밀번호는 실제 운영 정책에 맞게 지정합니다.
• mysql_native_password나 해시를 쓰기보다는 명시적인 비밀번호 설정이 가장 안전합니다.

2. 사용자 권한 (GRANT) 추출

SELECT CONCAT('SHOW GRANTS FOR '', user, ''@'', host, '';')
FROM mysql.user
WHERE user NOT IN ('mysql.sys', 'mysql.session', 'root');

• 이 결과를 실행하면 각 사용자에 대한 GRANT ... TO 문장이 출력됩니다.
• 이를 그대로 MySQL에 붙여넣으면 권한 이관 완료!

왜 authentication_string 해시 복사는 위험할까?

→ 따라서 비밀번호는 새로 지정하는 것이 정석입니다.

자동화 가능한 것 vs 수동 관리가 필요한 것

정리

• 사용자 목록과 권한은 쿼리로 추출하면 거의 자동 이관 가능
• 비밀번호는 반드시 새로 설정하자 (안전 + 호환성)
• 해시 복사는 호환성/보안상 위험하므로 지양

운영 환경에서 안정적이고 반복 가능한 사용자 이관을 원한다면, 사용자 추출 쿼리 + 비밀번호 재설정 + GRANT 복원의 3단계 전략이 가장 실용적입니다.