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 을 선택해야 한다.
'MySQL-MariaDB' 카테고리의 다른 글
| Binary Log(binlog) 사용하기 (1) | 2016.09.12 |
|---|---|
| innodb_flush_method, O_DIRECT에 대한 오해! (1) | 2016.08.22 |
| XtraBackup을 이용한 InnoDB 증분백업과 복구하기 ( 4 ) 원격백업 (0) | 2016.07.29 |
| XtraBackup을 이용한 InnoDB 증분백업과 복구하기 ( 3 ) 증분백업 (0) | 2016.07.29 |
| XtraBackup을 이용한 InnoDB 증분백업과 복구하기 ( 2 ) 풀백업 (0) | 2016.06.09 |
