Post

DB Replication

DB Replication

Posted
By song yeong rok
8 min read
DB Replication

좋아요. 줄임말과 과한 캐주얼 표현을 빼고, 차분한 기술 블로그 톤으로 다시 정리했어요. 한국어 독자가 흐름을 따라가며 읽기 쉽게 구성했습니다.

MySQL 데이터베이스 복제(Replication) 정리

Binary Log 기록 방식(Row / Statement / Mixed)과 복제 동작 흐름

1. 개요

데이터베이스 복제는 서비스의 가용성, 읽기 성능 확장, 데이터 안전성을 확보하기 위한 기본 기술이다. 일반적으로 소스(Source) 인스턴스에서 변경된 내용을 리플리카(Replica) 인스턴스로 전달해 동일한 결과를 유지한다. MySQL에서는 소스에서 발생한 변경을 바이너리 로그(Binary Log) 에 기록하고, 리플리카가 이를 받아 적용하는 구조를 사용한다.

2. 바이너리 로그 기록 방식

MySQL은 바이너리 로그를 다음 세 가지 방식으로 기록한다. 각 방식은 정합성, 로그 크기, 운영 난이도에서 장단점이 다르다.

2.1 Row 기반

  • 기록 내용: 변경된 행의 실제 값
  • 장점: 쿼리를 재실행하지 않고 그대로 적용하므로 데이터 정합성이 가장 높다. 트리거, 함수, 타임존 등의 영향을 거의 받지 않는다.
  • 단점: 변경량이 많을수록 로그 크기가 커진다. 대량 갱신 작업에서는 저장소와 전송 구간에 부담이 된다.
  • 권장 상황: 정합성이 최우선이거나 비결정적 연산이 섞이는 환경, 복잡한 트리거를 사용하는 스키마.

2.2 Statement 기반

  • 기록 내용: 실행된 SQL 문장
  • 장점: 동일 작업을 한 문장으로 표현하므로 로그 크기가 상대적으로 작다. 전송 효율이 좋다.
  • 단점: NOW(), RAND(), UUID() 같은 비결정적 함수나 특정 문장 패턴으로 인해 소스와 리플리카의 결과가 달라질 수 있다.
  • 권장 상황: 트랜잭션이 단순하고, 비결정적 쿼리를 팀 규칙으로 금지할 수 있는 환경.

2.3 Mixed 기반

  • 기록 내용: 기본적으로 Statement를 사용하되, 비결정성이 감지되면 자동으로 Row로 전환
  • 장점: 저장 공간과 안전성을 현실적으로 절충한다.
  • 단점: 내부 판단 로직에 의존하므로 문제 분석이 다소 복잡할 수 있다.
  • 권장 상황: 일반적인 서비스의 기본값으로 선택하기 적절하다.

정리

  • 정합성 최우선: Row
  • 로그 효율 최우선: Statement(단, 규율 필요)
  • 균형을 원할 때: Mixed

3. 복제 동작 흐름

복제는 다음 순서로 진행된다.

1
2
3
4
5
6
7
8
9
10
11

[소스 DB]
1) 트랜잭션 커밋
2) 바이너리 로그에 변경 내용 기록
            │
            │ (네트워크 전송)
            ▼
[리플리카 DB]
3) I/O 스레드가 소스의 바이너리 로그를 읽어
   리플리카의 릴레이 로그(Relay Log)에 저장
4) SQL 스레드가 릴레이 로그를 읽어
   실제 테이블에 변경 사항 적용
  • I/O 스레드: 변경 로그를 받아 저장한다.
  • SQL 스레드: 받아 둔 로그를 순서대로 적용한다.
  • 동기화 지연: 일반적으로 수십에서 수백 밀리초 단위로 유지되지만, 네트워크 상태, 쿼리 패턴, 로그 모드, 하드웨어 및 부하 상황에 따라 달라질 수 있다.

4. 운영 시 고려사항

4.1 정합성과 안전성

  • Statement 또는 Mixed 모드에서는 비결정적 쿼리 사용 금지 원칙을 문서화하고 코드 리뷰에서 점검한다.
  • 타임존은 저장 시점 기준으로 통일하는 것이 좋다(예: UTC 저장).
  • 대량 변경 작업 전에는 Row 모드에서 로그와 저장소 증가를 예측하고 대비한다.

4.2 성능과 지연

  • 리플리카의 SQL 스레드 병목을 점검한다. 대형 트랜잭션, 누락된 인덱스, 핫한 테이블이 지연의 주요 원인이다.
  • 네트워크 대역폭과 바이너리 로그 압축 설정을 검토한다.
  • 대표 지표로 Seconds_Behind_Source, 릴레이 로그 크기, 적용 속도를 지속적으로 모니터링한다.

4.3 장애 대응과 유지보수

  • 신규 리플리카 추가 시 스냅샷 + 포지션/GTID를 정확히 기록하고 절차를 표준화한다.
  • 로그 보관 기간과 디스크 사용량을 모니터링해 저장소 부족으로 인한 중단을 방지한다.
  • 승격(페일오버) 절차와 쓰기 방향 전환 시나리오를 사전에 리허설한다.

5. 실무 체크리스트

  • 기본값으로 Mixed를 고려하고, 필요 구간은 Row로 운영 정책을 명확히 한다.
  • 비결정적 함수와 트리거 사용 가이드를 팀 차원에서 적용한다.
  • 대량 배치 전 저장소 사용량과 전송량을 점검하고, 가능하면 시간대를 분산한다.
  • 복제 지연 알림(지연 시간, 릴레이 로그 크기, SQL 스레드 오류)을 설정한다.
  • 신규 리플리카 투입 시 스냅샷과 GTID/포지션 절차를 문서화한다.
  • 정기적으로 무결성 검증(체크섬 또는 표본 비교)을 수행한다.

6. 결론

복제의 핵심은 무엇을 기록할지(Row·Statement·Mixed) 와 어떻게 적용할지(I/O 스레드·릴레이 로그·SQL 스레드) 를 이해하고, 서비스의 특성에 맞는 균형을 잡는 일이다. 정합성, 지연, 저장소라는 세 축을 지속적으로 모니터링하면, 실전 환경에서도 안정적인 복제를 운영할 수 있다.

CS, Database
Computer Science Database DB-Replicatiion
This post is licensed under CC BY 4.0 by the author.