Aurora MySQL의 이진수 로그 복제 최적화
다음으로 Aurora MySQL에서 이진 로그 복제 성능을 최적화하고 관련 문제를 해결하는 방법을 배울 수 있습니다.
작은 정보
이 논의에서는 MySQL 이진 로그 복제 메커니즘과 작동 방식에 대해 잘 알고 있다고 가정합니다. 배경 정보는 MySQL 설명서의 복제 구현
다중 스레드 이진 로그 복제
다중 스레드 이진 로그 복제를 사용하면 SQL 스레드가 릴레이 로그에서 이벤트를 읽고 SQL 작업자 스레드에서 적용하도록 이벤트를 대기열에 넣습니다. SQL 작업자 스레드는 코디네이터 스레드에서 관리합니다. 가능한 경우 이진 로그 이벤트가 병렬로 적용됩니다.
다중 스레드 이진 로그 복제는 Aurora MySQL 버전 3, Aurora MySQL 버전 2.12.1 이상에서 지원됩니다.
Aurora MySQL DB 인스턴스가 binlog 복제를 사용하도록 구성된 경우 복제본 인스턴스는 Aurora MySQL 3.04 미만 버전에 기본적으로 단일 스레드 복제를 사용합니다. 다중 스레드 복제를 사용 설정하려면 replica_parallel_workers 파라미터를 사용자 정의 파라미터 그룹에서 0보다 큰 값으로 업데이트합니다.
Aurora MySQL 버전 3.04 이상에서는 복제가 기본적으로 다중 스레드로 설정되며 replica_parallel_workers가 4로 설정됩니다. 사용자 지정 파라미터 그룹에서 이 파라미터를 수정할 수 있습니다.
다음 구성 옵션을 사용하면 다중 스레드 복제를 세부 조정할 수 있습니다. 사용 정보는 MySQL 참조 설명서의 복제, 이진 로깅 옵션 및 변수
최적의 구성은 여러 요인에 따라 달라집니다. 예를 들어 이진 로그 복제의 성능은 데이터베이스 워크로드 특성과 복제본이 실행 중인 DB 인스턴스 클래스의 영향을 받습니다. 따라서 프로덕션 인스턴스에 새 파라미터 설정을 적용하기 전에 이러한 구성 파라미터에 대한 모든 변경 사항을 철저히 테스트하는 것이 좋습니다.
-
binlog_group_commit_sync_delay -
binlog_group_commit_sync_no_delay_count -
binlog_transaction_dependency_history_size -
binlog_transaction_dependency_tracking -
replica_preserve_commit_order -
replica_parallel_type -
replica_parallel_workers
Aurora MySQL 버전 3.06 이상에서는 보조 인덱스가 두 개 이상인 대규모 테이블의 트랜잭션을 복제할 때 binlog 복제본의 성능을 개선할 수 있습니다. 이 기능은 binlog 복제본에서 보조 인덱스 변경 사항을 병렬로 적용하는 스레드 풀을 도입합니다. 이 기능은 보조 인덱스 변경 사항을 적용하는 데 사용할 수 있는 총 병렬 스레드 수를 제어하는 aurora_binlog_replication_sec_index_parallel_workers DB 클러스터 파라미터에 의해 제어됩니다. 기본적으로 파라미터는 0(비활성화됨)로 설정됩니다. 이 기능을 활성화해도 인스턴스를 다시 시작할 필요가 없습니다. 이 기능을 활성화하려면 진행 중인 복제를 중지하고 원하는 수의 병렬 작업자 스레드를 설정한 다음 복제를 다시 시작하세요.
binlog 복제 최적화
Aurora MySQL 2.10 이상에서 Aurora는 binlog I/O 캐시라는 최적화를 바이너리 로그 복제에 자동으로 적용합니다. 이 최적화는 가장 최근에 커밋된 binlog 이벤트를 캐싱하여 binlog 덤프 스레드 성능을 개선하고 binlog 소스 인스턴스에 대한 포그라운드 트랜잭션에 미치는 영향을 제한하도록 설계되었습니다.
참고
이 기능에 사용되는 메모리는 MySQL binlog_cache 설정과 독립적입니다.
이 기능은 db.t2 및 db.t3 인스턴스 클래스를 사용하는 Aurora DB 인스턴스에는 적용되지 않습니다.
이 최적화를 켜기 위해 구성 파라미터를 조정할 필요가 없습니다. 특히 이전 Aurora MySQL 버전에서 구성 파라미터 aurora_binlog_replication_max_yield_seconds를 0이 아닌 값으로 조정한 경우 현재 사용 가능한 버전에서 0으로 다시 설정하세요.
상태 변수 aurora_binlog_io_cache_reads 및 aurora_binlog_io_cache_read_requests는 binlog I/O 캐시의 데이터를 읽는 빈도를 모니터링하는 데 도움이 됩니다.
-
aurora_binlog_io_cache_read_requests는 캐시의 binlog I/O 읽기 요청 수를 보여줍니다. -
aurora_binlog_io_cache_reads는 캐시의 정보를 검색하는 binlog I/O 읽기 수를 보여줍니다.
다음 SQL 쿼리는 캐시된 정보를 활용하는 binlog 읽기 요청의 백분율을 계산합니다. 이 경우 비율이 100에 가까울수록 더 좋습니다.
mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+
binlog I/O 캐시 기능에는 binlog 덤프 스레드와 관련된 새로운 지표도 포함됩니다. 덤프 스레드는 새로운 binlog 복제본이 binlog 소스 인스턴스에 연결될 때 생성되는 스레드입니다.
덤프 스레드 지표는 60초 간격으로 접두사 [Dump thread
metrics]를 사용하여 데이터베이스 로그에 인쇄됩니다. 지표에는 Secondary_id, Secondary_uuid, binlog 파일 이름 및 각 복제본에서 읽는 중인 위치와 같은 각 binlog 복제본에 대한 정보가 포함됩니다. 지표에는 복제 소스와 복제본 간의 거리(바이트)를 나타내는 Bytes_behind_primary도 포함됩니다. 이 지표는 복제본 I/O 스레드의 지연을 측정합니다. 이 수치는 binlog 복제본에서 seconds_behind_master 지표로 표시되는 복제본 SQL 적용자 스레드의 지연과 다릅니다. 이 거리의 감소 또는 증가를 확인하여 binlog 복제본이 소스를 따라 잡고 있는지, 뒤쳐지지 않는지 확인할 수 있습니다.
