Louis.Kim 의 제 3막

AWS Aurora mysql 3 version 에서는 innodb_flush_log_at_trx_commit의 값에 대한 동작이 변경된다고 합니다.

기존 innodb_flush_log_at_trx_commit 동작의 경우 많은 분들이 잘 설명해 주셨기 때문에 참고 부탁 드립니다.

https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

https://minsql.com/mysql/innodb_flush_log_at_trx_commit-%EA%B0%9C%EB%85%90%EB%8F%84%EC%99%80-%ED%8A%9C%EB%8B%9D-%ED%8F%AC%EC%9D%B8%ED%8A%B8/

기존에는 innodb_flush_log_at_trx_commit 의 값이 2의 경우, OS buffer 까지 Transaction 내용을 작성하여, DB Crush 에 대해서는 Transaction 의 정합성을 보호해 주었습니다.

이로 인하여 DB 상에서는 Commit, Write latency 등의 각종 Transaction 지표를 향상시켜주는 마법을 보여줬지만, OS Crush에 대해서는 데이터 유실에 대한 위험성은 감수해야 했습니다. (DBA 입장에서는 피하고 싶은 Parameter 수정 중 하나 입니다.)

Aurora mysql 3 version 에서는 innodb_flush_log_at_trx_commit 의 1과 2의 동작이 동일하게 변경 되었습니다. 즉, 기존 2를 사용하여 DML 관련 latency 성능 지표들을 통해 효과를 본 것이, 없어지게 되었습니다.

이건 redo log 동작(Engine Instance에서 log flushing을 처리하는 방식)이 Aurora storage engine 에서 처리하는 것으로 일괄 변경되면서, 기존 Aurora instance 에서 동작+storage engine에서 동작하던 것이 변경된 것으로 이해하면 됩니다.

이는 Aurora mysql 의 Write 에 대한 강점을 더 높인 것이라고 생각합니다.

그래서, 혹시라도 Aurora mysql 3에서의 DML latency를 좀 더 높이면서, 데이터 유실을 감수하겠다고 한다면, 기존 innodb_flush_log_at_trx_commit 의 값을 2가 아닌, 0으로 설정해야 합니다. innodb_flush_log_at_trx_commit 값을 설정하기 전, innodb_trx_commit_allow_data_loss parameter 를 1로 설정한 후, innodb_flush_log_at_trx_commit 변경이 가능합니다. innodb_flush_log_at_trx_commit 를 1로 설정한다는 것 자체가, 다시 한번 데이터 유실에 대한 경감식과 고객이 스스로 인지하고 있다는 것을 확인 받는 것이라고 생각되어 현웃이 터졌네요..ㅎㅎ

자세한 내용은 아래 공홈 확인 부탁 드립니다.

DBA 는 데이터 유실에 대해서는 항상 애민해질 수 밖에 없는 이슈이며, 또한 서비스 운영하는 개발자 분들의 서비스 성능에 대한 논의를 할때 해당 Parameter 가 꼭 거론 되는 내용이라 공유해 봅니다.

서비스 성능은 DB를 잘 사용하면, 엄청난 효과를 가져오지만, 그렇다고 데이터 유실에 대한 Risk를 가져가면서 서비스 성능을 높이는 것은 다른 이야기 입니다. 

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

Aurora Storage 동작 방식에 대해서는 아래 사이트의 이미지 참고하시면 좋을거 같습니다. 가장 좋아하는 이미지인데, 유튜브에서만 보던 것을 정리해 주셨네요.

https://choieungi.github.io/posts/amazon-aurora-storage-with-innodb/