Aurora MySQL Cluster 의 innodb_flush_log_at_trx_commit 파라미터

이 페이지에서는 MySQL 에서 자주 검토가 되는 파라미터 중 하나인 innodb_flush_log_at_trx_commit 및 Aurora MySQL Cluster 에서 고려해야 할 사항에 대해서 다룬다.

 

이 페이지는 아래의 외부 참조 URL 및 공식 AWS Document 와 관련되어 있다.

 

[1] https://jione-e.tistory.com/128

 

[2] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html#AuroraMySQL.BestPractices.Flush

 

 

innodb_flush_log_at_trx_commit 의 개념

 

MySQL 에서 검토되는 파라미터중 하나인 innodb_flush_log_at_trx_commit 은 commit 되는 데이터에 대하여 어느 정도의 주기로 storage 내 redo log file (ib_logfile) 에 데이터를 기입할지에 대해서 빈도를 설정하게 해주는 파라미터다.

이 내용은 [1] 의 내용들을 참조하면 각 값마다 (0, 1, 2) 어떤 과정으로 데이터가 기입되는지에 대해서 자세히 확인 할 수 있다. 각 값마다 보이는 특정을 간략하게 설명하면 이렇다.

- 0 으로 설정

Commit 단위가 아닌 시간 단위로 (1초) 데이터를 storage 에 기입한다. 그래서 commit 을 기다리지 않고 시간만 되면 바로 storage 에 데이터를 기입하기에 아래에 설명할 1 설정보다 더 빠른 데이터 기입 속도를 보인다. 그러나 commit 된 데이터가 메모리에서 기입할 때까지 대기하기에 데이터 기입 전, crash 가 발생하면 데이터가 소실될 수 있다.

- 1 로 설정

0, 2 와 달리 commit 단위로 데이터가 기입된다. 그래서 commit 이 데이터 기입 과정으로 바로 연결되기에 데이터 보존을 보장한다. 그러나 commit 이 늦어지면 이에 대한 데이터 처리 속도지연이 발생할 수 있다.

- 2 로 설정

0 설정과 거의 동일한 특성을 보인다. 그러나 0 과의 차이점은 이와 같다. 0은 DB 단위의 메모리 영역 (log buffer) 에 데이터를 보존하기에 DB, OS crash 에 둘다 취약하다. 2는 OS Buffer Cache 에 보존되기에 DB crash 로 인한 데이터 유실은 예방 할 수 있다. 

 

이와 같이 데이터 처리 속도와 데이터 보존의 안정성 사이에서 어떤 값을 설정할지 검토하게 된다.

 

 

Aurora Cluster 의 innodb_flush_log_at_trx_commit 설정의 의의

 

현재 Aurora Cluster 에서 사용되는 MySQL 8.0 에서는 (글을 기재하는 기점 기준 MySQL 5.7 은 올해 EOL 예정이므로 제외) innodb_flush_log_at_trx_commit 기본 값은 1이고 AWS 측에서 속도보다 데이터 보존을 더 중요시하게 여겼기에 예전에는 이에 대해서 수정 불가로 설정을 했었다. 그러나 최근에 다시 수정이 가능하도록 설정을 했다. 이를 설정하기 위해서는 Aurora Cluster 에서 지원하는 innodb_trx_commit_allow_data_loss 를 1로 설정하면 된다. 사용자측에서 데이터 손실의 리스크를 감수하겠다는 일종의 동의를 받는 것과 같다.