16.4 복제 데이터 포맷

Statement 기반 바이너리 로그 포맷

• 실행된 SQL 그대로 바이너리 로그 포맷에 기록
• 장점
  • Row 기반 보다 용량 절약
  • 쿼리가 저장되다 보니 감사에 용이
• 단점
  • 비 확정적 쿼리는 복제 시 서버와 레플리카 간 데이터가 달라질 수 있음
  • Row 기반 보다 락이 더 많이 걸림
  • REPEATABLE-READ 이상에서만 사용 가능
• 비 확정적 쿼리
  • DELETE/UPDATE 시 ORDER BY 없는 LIMIT 사용
  • SELECT … FOR UPDATE (FOR SHARE) 쿼리 에서 NOWAIT 나 SKIP LOCKED 사용
  • 비 확정적 함수를 사용하는 쿼리 (LOAD_FILE, UUID, USER, FOUND_ROWS, RAND 등)
  • 비 확정적 사용자 정의 함수나 스토어드 프로시저를 사용하는 쿼리

Row 기반 바이너리 로그 포맷

• 데이터 변경이 발생했을 때 변경된 값 자체가 바이너리 로그에 기록되는 방식
• 5.7.7 부터 기본 (5.1 에서 도입)
• DDL 문은 모두 Statement로 기록되긴 함
• 장점
  • 각 복제들의 데이터 일관성을 보장하는 가장 안정적인 방식
  • 변경 분만 저장되기 때문에 복제 데이터 싱크 문제 없이 비 확정적 쿼리 사용 가능
  • 다음과 같은 쿼리에 락이 최소화되어 처리
    • INSERT … SELECT
    • INSERT with AUTO_INCREMENT
    • 적절한 인덱스 없이 풀스캔 처리되는 UPDATE/DELETE
  • 모든 트랜잭션 격리 수준에서 사용 가능
• 단점
  • 매우 많은 데이터를 변경한 경우 로그 파일 크기가 단시간에 매우 커질 수 있음
    • BLOB 같은 형태의 큰 값이 새로 저장되거나 변경되는 경우도 마찬가지

Mixed 바이너리 로그 포맷

• Statement로 기록 되었을 때 문제가 될 가능성이 있는 쿼리 라면 Row 포맷으로 변환되어 기록
  • Statement 기반 바이너리 로그 포맷의 비 확정적 쿼리가 여기에 해당
• InnoDB 는 Statement 포맷을 REPEATABLR-READ, SERIALIZABLE 격리 수준에서만 사용 가능