MariaDB InnoDB Log File Size 적정 크기 계산 방법 (mariabackup 실패 사례 기반)
결론부터 말하자면 ,
InnoDB log size는 “DB 사이즈”가 아니라
“redo 생성 속도 × 작업시간 × (여유)” 로 계산 한다.
여기서 작업 시간은 대규모 배치 작업이 될 수도 있고, 백업 작업이 될 수도 있다.
본 사례에서는 백업 시간이 10시간 이상으로 가장 긴 작업이었기 때문에,
해당 기준을 기반으로 사이즈 계산을 진행하였다.
문제 발생의 시작
수십 TB 규모의 MariaDB 환경에서 mariabackup이 간헐적으로 실패하는 문제가 발생하였다.
어떤 날은 성공
어떤 날은 실패
로그에는 항상 다음과 같은 메시지가 남았다.
Was only able to copy log from .. to .., not …
try increasing innodb_log_file_size
mariabackup: Stopping log copying thread
처음에는 버그를 의심했지만, 결론적으로는 설정 변경으로 해결할 수 있었다.
로그에서 이미 원인을 명확히 설명하고 있었다.
문제의 원인 파악
mariabackup은 왜 실패하는가 ?
mariabackup은 다음과 같은 방식으로 동작한다.
데이터 파일을 복사하는 동시에, redo log를 읽어 변경 사항을 반영한다.
문제는 이 과정에서 발생한다.
DB에서는 지속적으로 write가 발생하고 있고,
redo log는 circular buffer 이기 때문에, 공간이 부족하면 old log 부터 overwrite 된다.
이 상황에서,
redo 생성 속도가 backup이 로그를 읽는 속도보다 빠른 경우,
일정 시간 동안 누적된 redo 생성량이 log capacity를 초과하게 되고
결과적으로 필요한 로그가 overwrite되면서 백업이 실패하게 된다.
언제 성공 하고 언제 실패 하는가 ?
같은 환경에서 성공/실패 로그를 비교해 보았다.
성공 케이스에서는 redo 생성량 : 약 170MB
실패 케이스에서는 redo 생성량 : 약 40GB
약 200배 이상의 차이가 발생했다.
중요한 점은 단순히 redo 생성량이 많다는 것이 아니라,
redo 생성량이 현재 log capacity를 초과했는지 여부가 성공/실패를 결정한다는 점이다.
일반적으로 이렇게 생각 할 수 있다.
DB 사이즈가 크면 log size도 커야 하겠지 ?
아니다.
어떤 서비스인지가 훨씬 중요하다.
예를 들어,
100TB 규모라도 read 위주의 서비스라면 작은 log로도 충분 하다.
1TB 규모라도 write가 많은 서비스라면 더 큰 log 필요 하다.
즉, DB 크기보다 write workload의 특성이 훨씬 중요하다.
InnoDB Log File Size 계산 방법
InnoDB log size는 LSN(Log Sequence Number) 기반으로 계산하는 것이 가장 정확하다.
STEP 1. redo 생성 속도 측정
SHOW ENGINE INNODB STATUS\G
1분 간격으로 LSN 값을 수집하여 증가량을 계산한다.
LSN 증가량 = 60MB / minute
( 이 계산은 평균값 기준이므로, 실제 운영에서는 peak workload를 기준으로 잡는 것이 안전하다 )
STEP 2. 작업 시간 반영
예를 들어 backup 시간이 10시간이라면, 여유 시간을 포함하여 약 11시간(660분)으로 계산한다.
60MB × 660분 = 대략 40GB
STEP 3. (가능하다면) 안전 하게 여유 두기
운영 환경에서는 workload 변동성을 고려하여 여유를 확보하는 것을 추천한다.
최종 log size = 40GB × 1.5 = 60GB
이 서비스에서는 왜 InnoDB log size 15GB로는 부족했을까?
실제 운영 결과는 다음과 같았다.
5GB → 거의 항상 실패
10GB → 일부 성공
15GB → 대부분 성공 (하지만 여전히 실패 존재)
실패의 원인은 단순하다.
redo 생성량이 log capacity를 초과하면서, 필요한 로그가 overwrite 되었기 때문이다.
즉, 사이즈 결정 기준은 평균이 아니라 최대 workload 기준이어야 한다.
추가 튜닝 포인트
- backup 시간 조정
가능한 한 write workload가 낮은 시간대에 실행하는 것이 유리하다.
- parallel 옵션
–parallel = CPU core 수 (또는 N-1)
효과 : backup 속도 증가, redo 따라잡는 능력 개선, 실패 확률 감소
많은 튜닝 가이드에서 buffer pool 기준으로 log size를 잡는 경우가 있지만,
실제 운영에서는 redo 생성량과 작업 시간 기준으로 계산하는 것이 현실적으로 더 적합한 방법이다.
자유롭게 댓글을 달아주세요! 언제나 환영합니다.
기타 문의: info@neoclova.co.kr
네오클로바 기술블로그 홈 바로가기: https://neoclova.net
네오클로바 홈페이지: http://neoclova.co.kr
