innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit

DBMS를 사용하다 보면 읽기보다는 쓰기에 더 신경이 쓰일때가 있다. InnoDB는 쓰기작업에 있어서 몇가지

옵션을 제공하므로 정확히 알아두면 굉장히 유용하게 쓰일수 있다.

먼저 쓰기 작업에 대한 흐름을 살펴보자.

1. Commit 이 되면

2. InnoDB의 log buffer에 데이터를 쓴다(메모리영역)

3. 그런 다음 OS buffer 를 거쳐서(메모리영역)

4. redo 로그라 불리는 InooDB log file 에 쓰게 된다. (디스크영역) (이 부분을 flush라 표현한다.)

innodb_flush_log_at_trx_commit 옵션이 위 흐름을 어떻게 컨트롤 할지 선택할 수 있게 한다.

 

innodb_flush_log_at_trx_commit=1

기본값이다. 굳이 설정하지 않아도 해당 값으로 셋팅된다.

트랜잭션이 커밋되면 1~4 의 과정을 건건이 처리하게 되는데 ACID의 지속성을 보장받을수 있지만

IO 부하가 상당하다. 쓰기 속도보다 데이터의 중요도가 훨씬 더 크다면 기본값을 사용하는게 좋다.

innodb_flush_log_at_trx_commit=2

기본값과 다른점은 커밋됐을때 1~3 까지의 과정만 처리한다는 것이다. (한마디로 메모리 영역만)

그리고 실제 디스크에 쓰는 flush 는 약 1초에 한번씩 자동 수행된다.

트랜젝션의 양은 상관없이 flush 가 1초에 한번씩만 수행되기 때문에 매번 flush 되는 기본값보다 IO 성능이 

월등히 좋아지지만 단점은 데이터를 유실할 가능성이 있다는 점이다.

OS buffer 까지는 데이터가 넘어가기 때문에 DBMS가 크래시되는건 별 문제 없지만 1초마다 실행되는 flush가 

실행되고 있는 와중에 OS가 셧다운되버린다면 해당 트랜젝션은 커밋되었지만 유실될수 밖에 없다.

innodb_flush_log_at_trx_commit=0

이 옵션은 1~2 까지의 과정만 처리한다. 1초에 한번씩 3~4 과정을 자동으로 수행하게 되는데 쓰기 속도가

그만큼 더 빨라지지만 역시나 리스크는 더 커진다. 커밋해도 최종적으로 log buffer 에 쓰여지는 것 까지만 

보장하므로 flush 되는 과정에서 DBMS가 크래시 되면 해당 트랜잭션은 유실된다.

서버가 갑작스럽게 죽었을때 1~2초 정도의 데이터를 버릴수 있을 정도의 상황이라면 옵션2 가 가장 좋은 선택이다.

서버가 죽었을때는 당연하고 MySQL/MariaDB 가 갑자기 죽어도 1~2초 정도의 데이터를 버릴수 있다면 옵션0 이 가장 좋다.

커밋된 데이터는 무조건 살려야만 한다면 반드시 옵션1 을 선택해야 한다.