- Innodb_flush_log_at_trx_commit 시스템 변수
- 리두 로그를 어느 주기로 디스크에 동기화할지를 결정하는 시스템 변수
- 0,1,2 세 가지 값을 가질 수 있으며 기본 값은 1이다.
- 0: 1초에 한 번씩 리두 로그를 디스크로 기록(write)하고 동기화(sync)를 실행한다. 그래서 서버가 비정상 종료되면 최대 1초 동안의 트랜잭션은 커밋됐다고 하더라도 해당 트랜잭션에서 변경한 데이터는 사라질 수 있다.
- 1: 매번 트랜잭션이 커밋될 때마다 디스크로 기록되고 동기화까지 수행된다. 그래서 트랜잭션이 일단 커밋되면 해당 트랜잭션에서 변경한 데이터는 사라진다.
- 2: 매번 트랜잭션이 커밋될 때마다 디스크로 기록(write)은 되지만 실질적인 동기화(sync)는 1초에 한 번씩 실행된다. 일단 트랜잭션이 커밋되면 변경 내용이 운영체제의 메모리 버퍼로 기록되는 것이 보장된다. 그래서 MySQL 서버가 비정상 종료됐더라도 운영체제가 정상적으로 작동한다면 해당 트랜잭션의 데이터는 사라지지 않는다. MySQL 서버와 운영체제가 모두 비정상적으로 종료되면 최근 1초 동안의 트랜잭션 데이터는 사라질 수도 있다.
- innodb_flush_log_at_trx_commit 시스템 변수가 0이나 2로 설정되는 경우 디스크 동기화 작업이 항상 1초 간격으로 실행되는 것은 아니다. 스키마 변경을 위한 DDL이 실행되면 리두 로그가 디스크로 동기화되기 때문에 InnoDB 스토리지 엔진이 스키마 변경을 위한 DDL을 실행했다면 1초보다 간격이 작을 수도 있다. 하지만 스키마 변경 작업은 자주 실행되는 작업은 아니므로 리두 로그는 최대 1초 정도 손실이 발생할 수 있다는 정도로 기억해 두자. 또한 innodb_flush_log_at_trx_commit 시스템 변수가 0이나 2인 경우, 디스크 동기화 시간 간격을 innodb_flush_log_at_timeout 시스템 변수를 이용해 변경할 수 있다. 기본값은 1초이며, 일반적인 서비스에서 이 간격을 변경할 만한 특별한 이유는 없을 것으로 보인다.
- 진행 중인 프로젝트에서 데이터 삽입 로직이 느려 해결방법을 검색 중 알게 된 옵션입니다. 데이터 삽입 속도 상승과 데이터 유실 사이의 트레이드오프를 고려해 보았을 때 프로젝트 특성상 DB서버 문제 발생 시 1초 정도의 데이터 유실이 발생하여도 데이터 삽입 로직의 속도 향상이 더 중요하다고 판단하여 해당 옵션을 2로 적용하여 같은 조건에서 테스트 시 약 97.22%(180초 -> 5초) 정도의 성능 개선 을 하였습니다.
참고: https://product.kyobobook.co.kr/detail/S000001766482