AWS Aurora MySQL enhanced binlog - 향상된 binlog 기능

Last Updated on 12월 8, 2023 by Jade(정현호)

안녕하세요  
이번 포스팅은 AWS Aurora MySQL에 추가된 enhanced binlog(향상된 binlog) 기능에 대해서 확인 보도록 하겠습니다.     

binary log(바이너리 로그)

MySQL의 binary log(바이너리 로그,binlog)는 DDL 또는 DML과 같이 MySQL 데이터베이스 내에서 발생하는 변경 내역이 저장되는 로그 파일입니다.
트랜잭션 커밋시 기록되며 기본적으로 변경 순서를 보장하여 기록을 합니다.

이런 바이너리 로그는 MySQL을 사용하면서 여러 용도로 사용되며, 대표적인 기능으로 복제 환경 사용을 위해 사용되며, 또 다른 이유로 문제 발생시 복구를 위해서 바이너리 로그를 이용하기도 합니다.

바이너리 로그는 MySQL의 복제 기능의 역사와 같이 한 만큼 오래전부터 사용되는 데이터베이스의 변경 이벤트가 저장되는 로그 파일이었으며, 오래된 만큼 바이너리 로그의 기록(파일 작성)에 관하여 부하 및 성능 개선을 위해 여러가지 노력과 개선 사항이 계속 추가 반영되었습니다.

여러 가지 노력 및 계속적인 개선 적용은 그 만큼 바이너리 로그 활성화시에 신경 써야 할 성능적인 요소가 있다는 것을 의미합니다.

그렇지만 MySQL에서 복제 환경은 기본적인 구성이며 필수요소이기 때문에 바이너리 로그를 활성화하여 사용하는 것은 일반적인 상황입니다.

InnoDB 스토리지 엔진이 주로 사용되고, 기본 스토리지 엔진으로 채용되면서 트랜잭션 로그(Redo Log)와 바이너리 로그를 같이 쓰기가 되어야 함에 따라서 이 시기에 몇 가지 주요 기능이 추가되게 됩니다.

• 2pc commit
• 바이너리 로그 그룹 커밋

트랜잭션 커밋이 발생되면 트랜잭션 로그(Redo Log)와 바이너리 로그를 같이 작성이 되어야 하며, 해당 부분에 대해서 2단계 커밋(2PC, Two-Phase Commit)이 도입이 되었고, 그 다음 바이너리 로그를 작성하는 Fsync의 성능 개선을 위해서 바이너리 로그 그룹 커밋 기능이 도입되었습니다.

해당 내용은 이전 포스팅에서 자세하게 설명되어 있으므로 참고하시면 됩니다.

MySQL - Binary Log Group Commit - 바이너리 로그 그룹 커밋 - Two-Phase Commit

안녕하세요 이번 포스팅에서는 MySQL의 Binary Log Group Commit 와 관련된 트랜잭션의 Commit 에 관련된 내용을 확인해 보도록 하겠습니다.

이러한 MySQL의 고유한 특성 및 특징은 AWS Aurora MySQL에도 그대로 상속되어 있습니다.

AWS Aurora MySQL에서 컴퓨팅 노드(레이어)와 스토리지 레이어를 분리는 데이터베이스(DBMS)의 주요 과제 또는 숙제 중 하나인 처리량 부분을 해소하는 획기적인 혁신이었습니다.

그러나 이러한 아키텍처도 때때로 바이너리 로그 파일을 작성할 때 필요한 네트워크 워크로드 증가와 네트워크 홉 증가, 파일을 작성하는 과정에서의 CPU 오버헤드 등으로 인해 성능 저하의 요소가 될 수 있는 부분은 계속 존재하였습니다.

바이너리 로그가 활성 되면 인스턴스 비정상 종료 후 자동 복구(리커버리) 시에 바이너리 로그에 작성된 상태에 따라서 롤백 여부가 결정됨에 따라서 바이너리 로그를 읽어야 하며 그에 따라서 MySQL 또는 AWS Aurora MySQL의 복구 시간이 더 길어질 수도 있게 됩니다.

이렇게 MySQL에서는 복제 환경 사용 및 복구에 사용하기 위한 용도로 바이너리 로그는 사실상 필수적이고 중요한 파일이며, 이런 의미적인 부분 등으로 MySQL 8버전 부터는 바이너리 로그 활성화가 기본값으로 되었습니다.
(MySQL8 버전 부터는 별도의 설정 없이 기본적으로 바이너리 로그가 활성화되어 생성됨)
                   

Aurora MySQL enhanced binlog

MySQL 그리고 MySQL과 호환성을 가진 Aurora MySQL은 위에서 설명 드린 내용처럼 바이너리 로그에 관한 고유한 특성 및 특징을 같이 내재화 되어 있습니다.

그에 따라서 Aurora MySQL에서도 이러한 성능적인 부분을 개선하기 위해서 2021년 binlog i/o cache를 도입하게 되었습니다.

binlog I/O 캐시는 최신 binlog 이벤트를 순환 캐시(circular cache)에 보관하여 Aurora 스토리지 엔진의 읽기 I/O를 최소화합니다. binlog I/O 캐시는 binlog 활성화 환경에서 처리량이 5배 이상 향상되었습니다.

[Introducing binlog I/O cache]

이제 Aurora MySQL 3.03.1(매뉴얼 기준) 버전 부터는 binlog를 작성하고 저장하는 방법에 대해서 보다 근본적인 변경 사항을 도입하게 되었습니다.

이러한 enhanced binlog(향상된 binlog)는 경우에 따라서 최대 50% 도달할 수 있는 binlog 활성화에 따른 성능 부하를 13%로 줄입니다. 이는 동일한 하드웨어에서 추가적인 트랜잭션 처리량을 가능하게 합니다.

향상된 binlog 사용시 binlog I/O 캐시가 비활성화 되지만, 향상된 binlog는 binlog I/O 캐시와 유사한 읽기 성능 향상과 더 나은 쓰기 성능 개선을 제공합니다.
     

첫 번째 혁신은 트랜잭션 로그(Redo)의 스토리지와 binlog의 스토리지를 분리하는 것입니다. Aurora MySQL은 커뮤니티 MySQL과 다르게 binlog을 인터널이 아닌 외장(external) 스토리지에 저장하고 있습니다.

Aurora MySQL의 기본 구성은 트랜잭션 로그와 binlog를 모두 저장하기 위한 동일한 스토리지 노드를 사용하였습니다.
향상된 binlog기능을 사용하면 binlog에 최적화된 특수한 별도의 스토리지 노드에 binlog를 저장합니다.

이러한 스토리지 노드에는 데이터베이스 엔진이 binlog의 정렬과 순서 지정을 스토리지 계층으로 푸시다운 할 수 있도록 로직이 추가되었습니다. 이를 통해 병렬 처리를 늘리고, 잠금을 줄이며, 트랜잭션 로그와 binlog가 기록될 때 데이터베이스 엔진에서의 2단계 커밋(2PC Commit) 시간을 단축하는 동시에 순서대로 쓰기(ordered writes)를 수행할 수 있게 되었습니다.

이러한 아키텍처의 개선으로 인하여 Aurora MySQL의 binlog는 쓰기 성능이 크게 향상되었습니다.

다음은 커뮤니티 binlog(설치형 MySQL의 binlog, 위)와 새로운 향상된 binlog(아래)간의 트랜잭션 로그 및 binlog에 이벤트가 기록되는 방식을 비교한 것입니다.

[enhanced-binary-log-binlog]

이러한 변경사항은 binlog기능 활성화된 경우 데이터베이스 장애 조치시에 복구 성능(소요시간)을 개선하는 데도 도움이 됩니다.
분산 스토리지 계층을 통해 Aurora MySQL은 병렬 및 비순차적으로 복구할 수 있습니다.

또한 binlog기능이 활성화되면 인스턴스 비정상 종료(Crash) 발생 후 자동 복구 조치시에 롤백 여부를 판단에 대해서 binlog가 사용되며 그에 따라서 바이너리 로그 파일을 순차적으로 읽어야 합니다. 이런 추가적인 오버헤드는 특히 대규모 트랜잭션을 롤백 해야 하는 경우 Aurora 데이터베이스의 복구 시간에 영향을 미칠 수 있습니다.

향상된 binlog는 스토리지 계층에 로직을 추가하여 binlog파일을 순차적으로 스캔 할 필요가 없도록 합니다. 대신 트랜잭션에 대해서 일관성을 유지하면서 보다 선별적인 방식으로 복구를 합니다. 이렇게 하면 binlog를 통해서 복구에 대해서 최대 99%까지 단축할 수도 있게 됩니다. 결과적으로 데이터베이스 복구 시간이 최대 몇 분에서 몇 초로 비약적으로 단축될 수 있습니다.
                        

enhanced binlog 구성

enhanced binlog 기능은 기본적으로 비활성화 상태로 Aurora MySQL 인스턴스가 구성 및 시작됨으로 파라미터 변경을 통해서 활성화가 필요 합니다.

클러스터 파라미터 그룹에서 4개의 파라미터의 변경을 합니다.

binlog_format
 • 기본값 : -
 • AWS Aurora MySQL에서 바아너리 로그를 활성화하기 위해서는 binlog_format을 설정해서 바이너리 로그를 활성화합니다.
 • 파라미터 그룹은 MIXED 또는 ROW의 설정이 필요하며, 포스팅에서는 보통 ROW로 설정을 가이드 하고 있습니다.

aurora_enhanced_binlog
 • 기본값 : 0
 • enhanced binlog 사용하기 위해서는 해당 파라미터를 활성화(1)로 설정을 변경해야 합니다.

binlog_backup
 • 기본값 : 1
 • 이 설정은 바이너리 로그 데이터의 백업 여부를 제어되며, 이 설정은 aurora_enhanced_binlog 제어(변경)시에만 설정을 변경합니다.
 • aurora_enhanced_binlog가 활성화된 경우 비활성화(0)하고 aurora_enhanced_binlog가 비활성화된 경우 활성화(1)해야 합니다.

binlog_replication_globaldb
 • 기본값 : 1
 • 향상된 binlog를 켜려면 해당 파라미터를 비활성화(0)을 해야 합니다.

binlog_backup 및 binlog_replication_globaldb 파라미터는 향상된 binlog를 사용할 경우에만 비활성화 할 수 있습니다.


4개 파라미터 모두 Apply type 이 Static 이고, 그에 따라서 파라미터 그룹 변경 후 Writer 인스턴스의 재시작이 필요 합니다.

Writer 인스턴스의 재시작은 크게 두가지 방법으로 Writer 인스턴스 자체를 재시작하는 방법과 Failover를 통한 재시작이 있습니다.

2.10 버전 이전에는 Writer 인스턴스를 재시작하면 Reader 인스턴스도 재시작 되었으나 2.10 버전 이후 부터는 Writer인스턴스 재시작해도 Reader인스턴스는 재시작 되지 않습니다.


Other related parameters
enhanced binlog이 활성화되면 변경하지 않아도 영향받는 파라미터는 다음과 같습니다.

max_binlog_size
 - max_binlog_size는 변경이 불가능하며, 기본값은 134217728 이지만, 향상된 binlog 기능이 활성화되면 268435456 으로 자동적으로 조정됩니다.

binlog_checksum
 - binlog_checksum 파라미터는 동적으로 적용되는 파라미터이지만 향상된 binlog가 활성화되면 파라미터의 변경 적용은 DB 클러스터를 수동으로 재부팅 해야 적용됩니다.
            

enhanced binlog 성능

enhanced binlog를 사용하게 되었을 때 당연한 가장 이점은 성능 증가입니다.

향상된 binlog 기능 사용으로 인하여 성능 저하 요소를 줄임으로써 초당 더 많은 트랜잭션을 처리할 수 있게 됩니다.

다음은 AWS에서 sysbench를 사용하여 db.r10g.6xlarge 및 db.r6xlarge 인스턴스 클래스에 대해서 16번 반복 테스트의 평균 처리량에 대해서 벤치마크한 결과입니다.

테스트시 25에서 4000 사이의 스레드 수를 반복하였으며, 벤치마크 테스트 결과에 따르면 성능이 정말 중요한 트랜잭션 처리량 요구 사항이 높은 대규모 인스턴스에서 향상된 binlog는 Writer 인스턴스의 경합을 줄여서 트랜잭션 처리량을 개선되었습니다.

다음 차트는 커뮤니티 binlog와 향상된 binlog 사용 간의 비교와 향상된 binlog를 사용할 때의 트랜잭션 처리 성능 향상을 보여줍니다.

[db.r6g.8xlarge의 TPS(초당 트랜잭션 수) 비교]

[db.r6g.16xlarge의 TPS(초당 트랜잭션 수)]

이런 성능 증가에 두 번째 부분은 데이터베이스 복구 부분입니다. 다음 결과는 커뮤니티 binlog 사용 시 데이터베이스 복구 결과의 차이를 비교되어 있으며 다양한 워크로드의 복구 시간 차이를 확인할 수 있습니다.

binlog 트랜잭션 크기가 커질수록 커뮤니티 binlog는 복구하는 데 시간이 더 오래 걸리는 반면 향상된 binlog 에서는 복구 시간이 1초 이내에 일정하게 유지되는 것을 확인할 수 있습니다.

[binlog 복구 시간 개선]

향상된 binlog와 커뮤니티 binlog의 차이점

향상된 binlog를 활성화하면 데이터베이스 성능이 향상될 수 있습니다. 그러나 binlog 쓰는 방식의 변경에 따라서 커뮤니티 binlog를 사용하는 환경과 차이가 있을수 있으며 그에 따라서 몇 가지 제한 사항이 있습니다

향상된 binlog는 커뮤니티 MySQL binlog와 비교할 때 클론, 백업 및 Aurora Global Database와 다르게 상호 작용합니다.

Aurora Global Database 또는 스냅샷에서 클러스터를 복원하거나 데이터베이스를 복제한 경우 binlog 파일은 복제본에 복제되지 않아 사용할 수 없다는 공통적인 제한 사항이 존재합니다.

• 소스 DB 클러스터의 향상된 binlog 파일은 복제된 DB 클러스터에서 사용할 수 없습니다.
• 향상된 binlog 파일은 Aurora 백업에 포함되지 않습니다. 따라서 DB 클러스터를 복원한 후에는 보존 기간이 설정되어 있더라도 소스 DB 클러스터의 향상된 binlog 파일을 사용할 수 없습니다.
• Aurora 글로벌 데이터베이스와 함께 사용하면 프라이머리 DB 클러스터의 향상된 binlog 파일이 보조 리전의 DB 클러스터에 복제되지 않습니다.

복제 및 복원되는 클러스터 환경에서
다음은 향상된 binlog와 커뮤니티 MySQL binlog 간의 차이점에 대한 예시입니다.

Source 인스턴스에서 향상된 binlog가 활성화되어 있는 상태에서 복원 또는 복제된 클러스터에서 binlog가 활성화되어 인스턴스가 시작될 경우 새로운 DB 클러스터에서는 1(mysql-bin-changelog.000001)부터 고유한 binlog 파일 시퀀스를 쓰기 시작합니다.

위의 내용은 복제 또는 복원된 Replica 인스턴스에서 향상된 binlog와 커뮤니티 binlog 모두에 해당합니다.

• Source 인스턴스

mysql> show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+

• Replica 인스턴스
복원되거나 복제된 DB 클러스터에서는 향상된 binlog가 켜져 있을 때 binlog 파일이 백업되지 않습니다. binlog 데이터의 불연속성을 방지하기 위해 향상된 binlog를 켜기 전에 작성한 binlog 파일도 사용할 수 없습니다.

mysql> show binary logs;
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
+----------------------------+-----------+-----------+

참고로 기본 사용 방식인 커뮤니티 binlog를 사용할 경우 다음과 같이 동작합니다.

• Source 인스턴스

mysql> show binary logs;
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000003 |       732 | No        |
| mysql-bin-changelog.000004 |       156 | No        |
| mysql-bin-changelog.000005 |       156 | No        |
| mysql-bin-changelog.000006 | 269275121 | No        |
| mysql-bin-changelog.000007 | 269268487 | No        |
| mysql-bin-changelog.000008 | 269271905 | No        |
| mysql-bin-changelog.000009 | 269269570 | No        |
| mysql-bin-changelog.000010 |  93119116 | No        |
| mysql-bin-changelog.000011 |  98270473 | No        |
| mysql-bin-changelog.000012 | 572443316 | No        |
| mysql-bin-changelog.000013 |       156 | No        |
+----------------------------+-----------+-----------+

• 복구 후 Replica 인스턴스

mysql> show binary logs;
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000011 |  98270473 | No        |
| mysql-bin-changelog.000012 | 572443316 | No        |
| mysql-bin-changelog.000013 |       156 | No        |
| mysql-bin-changelog.000014 |       156 | No        |
| mysql-bin-changelog.000015 |       156 | No        |
| mysql-bin-changelog.000016 |       156 | No        |
+----------------------------+-----------+-----------+

참고로 향상된 binlog를 활성화시에도 Aurora MySQL 에서 다른 Aurora MySQL 또는 RDS for MySQL 또는 설치형 MySQL(EC2 등) 으로 복제를 설정하는 External Replication은 여전히 구성 및 사용할 수 있습니다.


향상된 binlog를 위한 CloudWatch 지표
향상된 binlog가 활성화되었을 경우 별도의 CloudWatch 지표에서 관련 성능 정보를 확인할 수 있습니다.

향상된 binlog의 제한 사항

향상된 binlog가 켜져 있는 경우 Amazon Aurora DB 클러스터에 다음과 같은 제한 사항이 적용됩니다.

Reference

Reference URL
• amazon.com/performance-failover-recovery-time-binlog-enabled
• amazon.com/introducing-aurora-mysql-enhanced-binary-log-binlog
• amazon.com/#AuroraMySQL.Enhanced.binlog
• amazon.com/binlog-io-cache-aurora-mysql


연관된 다른 포스팅

MySQL - Binary Log Group Commit - 바이너리 로그 그룹 커밋 - Two-Phase Commit

안녕하세요 이번 포스팅에서는 MySQL의 Binary Log Group Commit 와 관련된 트랜잭션의 Commit 에 관련된 내용을 확인 해 보도록 하겠습니다.

Multi-Threaded Replication - 병렬 복제 - 멀티 스레드 리플리케이션 - MTS

MySQL의 Multi-Threaded Replication(병렬 복제) 에 대해서 내용으로 MySQL 5.7과 MySQL 8.0 기준으로 작성 되어 있습니다.

AWS Aurora MySQL 업그레이드 - Aurora 3.0 Upgrade

안녕하세요 이번 포스팅에서는 AWS 의 Aurora MySQL 의 업그레이드 관련 해서 내용을 전반적으로 확인해보려고 합니다.해당 포스팅은 Aurora 2.0 버전에서 3.0 버전으로의 업그레이드 내용을 다루고 있습니다.

MySQL 마이그레이션 - Xtrabackup - mysql shell - mysqldump - Migration 방법 비교

안녕하세요 이번 포스팅에서는 On-premises의 MySQL 을 클라우드(AWS) 또는 다른 서버로의 마이그레이션(또는 복제를 위한 이관) 가 관련 된 사용 가능한 방법 및 속도 등에 대해서 살펴보려고 합니다.

Amazon RDS Optimized Writes - MySQL 쓰기 처리량 최대 2배 증가

Amazon RDS for MySQL 에서 새롭게 추가된 기능인 Optimized Writes 에 대해서 확인 해보려고 합니다. Amazon RDS Optimized Writes AWS RDS 에서는 이제 Optimized Writes 라는 기능을 지원하기 시작하였으며, 추가 비용 없이 쓰기 처리량을 최대 2배 가량 높일 수 있게 되었습니다.

Jade(정현호)

Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중

Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io

hoing.io