메인 콘텐츠로 건너뛰기

VillageSQL is a drop-in replacement for MySQL with extensions.

All examples on this page work on VillageSQL. Install Now →
MySQL 바이너리 로그는 데이터베이스에 이루어진 모든 변경 사항을 기록합니다 — 삽입, 업데이트, 삭제, 스키마 변경. 복제와 특정 시점 복구의 기반입니다. 대부분의 프로덕션 MySQL 서버는 바이너리 로깅을 활성화한 채로 실행됩니다.

바이너리 로깅 활성화

MySQL 8.0에서는 바이너리 로깅이 기본적으로 활성화되어 있습니다. 확인하려면:
my.cnf / my.ini에서 구성합니다:
log_bin을 설정하면 MySQL은 binlog 파일의 이름을 mysql-bin.000001, mysql-bin.000002 등으로 지정하고, 이들을 모두 나열하는 인덱스 파일(mysql-bin.index)을 만듭니다.

바이너리 로그 형식

MySQL은 세 가지 binlog 형식을 지원합니다: ROW 형식이 권장 기본값입니다. RAND()나 UUID() 같은 비결정적 함수가 포함되어도 올바르게 복제됩니다. 단점은 더 큰 로그 파일입니다 — 수백만 행을 건드리는 단일 UPDATE는 STATEMENT 형식에서는 하나의 문을 생성하지만 ROW 형식에서는 영향을 받는 행마다 하나의 행 이벤트를 생성합니다.

바이너리 로깅을 활성화할 시기와 선택할 형식

MySQL 8.0+에서는 바이너리 로깅이 기본적으로 활성화되어 있습니다. 보통 문제는 어떤 형식을 사용할지, 그리고 아예 켜 둘지 여부입니다. 형식을 확인하고 변경합니다:

바이너리 로그 나열 및 보기

모든 바이너리 로그 파일을 나열합니다:
현재 binlog 파일과 위치를 확인합니다:
SQL에서 binlog의 이벤트를 봅니다:

mysqlbinlog

mysqlbinlog 도구는 바이너리 로그 파일을 사람이 읽을 수 있는 SQL로 디코딩합니다. 특정 시점 복구와 감사에 사용됩니다:

특정 시점 복구

전체 백업과 바이너리 로그를 결합하면 백업 이후의 어느 시점으로든 복원할 수 있습니다. 일반적인 워크플로:
  1. mysqldump --single-transaction --source-data로 전체 백업을 만듭니다:
--source-data=2는 binlog 파일 이름과 위치를 덤프에 주석으로 기록합니다. 이것이 복구 시작점입니다.
  1. 전체 백업을 복원합니다:
  1. 덤프에서 binlog 파일과 위치를 찾습니다:
  1. 그 위치부터 되돌리려는 이벤트 직전까지 binlog를 재생합니다:

바이너리 로그 관리

오래된 바이너리 로그를 수동으로 삭제합니다:
binlog_expire_logs_seconds로 자동 삭제합니다(MySQL 8.0+; expire_logs_days는 제거됨):
binlog 파일을 rm으로 직접 삭제하지 마세요 — 인덱스 파일의 일관성이 유지되도록 PURGE BINARY LOGS를 사용하세요.

자주 묻는 질문

바이너리 로깅이 쓰기 성능에 영향을 주나요?

예, 약간 영향을 줍니다. ROW 형식 로깅은 변경된 데이터 양에 비례하는 오버헤드를 추가합니다. 쓰기 위주 워크로드에서 오버헤드는 보통 5–15%입니다. 복구와 복제 기능을 고려하면 거의 항상 그만한 가치가 있습니다.

특정 세션에서 바이너리 로깅을 건너뛸 수 있나요?

더 이상 전파할 필요가 없는 레플리카에 데이터를 로드하거나, 특정 시점 복구 범위에서 제외하려는 대량 작업에 유용합니다. SUPER, SYSTEM_VARIABLES_ADMIN, 또는 SESSION_VARIABLES_ADMIN이 필요합니다 — BINLOG_ADMIN만으로는 충분하지 않으며 시도는 ERROR 1227로 실패합니다.

바이너리 로그가 사용하는 디스크 공간은 어떻게 알 수 있나요?

또는 디스크에서: du -sh /var/log/mysql/mysql-bin.*

문제 해결

참고