728x90
반응형
운영하다 보면 MySQL 설정값 중에 한 번쯤 마주치는 항목이 바로
binlog_expire_logs_auto_purge야.
이게 뭔지 모르고 지나치기 쉬운데, 실제로는 디스크 용량 관리와 장애 예방에 직접적인 영향을 주는 중요한 옵션이야.
오늘은 이 설정을 현업 기준으로 이해하기 쉽게 정리해볼게.
binlog_expire_logs_auto_purge 한 줄 요약
👉 만료된 Binary Log(binlog)를 MySQL이 자동으로 삭제해줄지 결정하는 스위치
먼저, binlog가 뭐냐면
MySQL의 Binary Log는 다음 용도로 사용돼:
- Replication (복제)
- Point-in-Time Recovery
- 장애 복구
- 데이터 변경 추적
즉,
“DB에서 일어난 모든 변경 이력 기록 파일”
이라고 보면 된다.
이 파일들은 시간이 지나면 계속 쌓이는데,
정리 안 하면 디스크를 그대로 잡아먹는다 😅
binlog_expire_logs_auto_purge 역할
✅ 값이 ON (1)
binlog_expire_logs_auto_purge = ON- 설정된 보존 기간이 지나면
- MySQL이 알아서 오래된 binlog 삭제
👉 완전 자동 관리
운영 환경에서는 거의 이게 기본이야.
❌ 값이 OFF (0)
binlog_expire_logs_auto_purge = OFF- 자동 삭제 안 됨
- 사람이 직접 purge 해야 함
예:
PURGE BINARY LOGS BEFORE '2026-02-01';👉 수동 운영 방식
👉 깜빡하면 디스크 FULL 위험
같이 보는 핵심 옵션
이 옵션은 단독으로 의미가 거의 없고,
아래 설정과 항상 같이 봐야 해.
🔹 binlog_expire_logs_seconds
binlog_expire_logs_seconds = 604800의미:
- binlog를 몇 초 동안 보관할지
604800초 = 7일
즉 구조는:
보관 기간 → 지나면 → auto_purge가 ON이면 자동 삭제실제 운영 예시
가장 흔한 운영 세팅
binlog_expire_logs_auto_purge = ON
binlog_expire_logs_seconds = 604800 -- 7일의미:
binlog를 7일 보관 후 자동 삭제
이걸 왜 꼭 확인해야 하냐면
현장에서 자주 터지는 사고 패턴이 이거야:
- auto_purge 꺼져 있음
- binlog 무한 증가
- 디스크 FULL
- MySQL 다운
- 서비스 장애
특히 IDC → AWS 마이그레이션이나
Replication 구성 변경할 때 이 값 빠뜨리면 꽤 위험해.
지금 서버 설정 확인하는 방법
SHOW VARIABLES LIKE 'binlog_expire_logs%';결과 예:
binlog_expire_logs_auto_purge | ON
binlog_expire_logs_seconds | 604800정리
항목의미
| binlog_expire_logs_auto_purge | 만료 binlog 자동 삭제 여부 |
| ON | MySQL이 알아서 정리 |
| OFF | 사람이 직접 purge |
| binlog_expire_logs_seconds | binlog 보관 시간 |
마무리 한마디
이 설정은 눈에 안 띄지만,
디스크 장애를 막는 1차 방어선이야.
운영 DB라면 거의 무조건:
✅ auto_purge ON
✅ expire 시간 명시
이 조합으로 가져가는 게 정석이야.
728x90
반응형