Amazon Aurora MySQL을 사용한 복제 - Amazon Aurora

Amazon Aurora MySQL을 사용한 복제

Aurora MySQL 복제 기능은 클러스터의 고가용성과 성능을 위한 핵심 기능입니다. Aurora에서는 최대 15개의 Aurora 복제본을 사용하여 클러스터를 손쉽게 생성하거나 크기를 조정할 수 있습니다.

모든 복제본은 동일한 기반 데이터에서 작동합니다. 일부 데이터베이스 인스턴스가 오프라인으로 전환되는 경우 다른 인스턴스는 쿼리를 계속 처리하거나 필요한 경우 라이터 역할을 대신할 수 있습니다. Aurora는 읽기 전용 연결을 여러 데이터베이스 인스턴스에 자동으로 분산시켜 Aurora 클러스터에서 쿼리 집약적인 워크로드를 지원할 수 있도록 지원합니다.

다음 주제에서는 Aurora MySQL 복제의 작동 방식과 최적의 가용성 및 성능을 위해 복제 설정을 미세 조정하는 방법에 대한 정보를 확인할 수 있습니다.

Aurora 복제본 사용

Aurora 복제본은 Aurora DB 클러스터의 독립 엔드포인트로서, 읽기 작업을 조정하고 가용성을 높이기 위해 사용하기에 가장 적합합니다. 최대 15개의 Aurora 복제본을 AWS 리전 내 DB 클러스터에 포함된 가용 영역에 배포할 수 있습니다. DB 클러스터 볼륨은 DB 클러스터의 여러 데이터 사본으로 구성되어 있지만, DB 클러스터의 기본 인스턴스 및 Aurora 복제본에는 클러스터 볼륨 데이터가 단 하나의 논리 볼륨으로 표시됩니다. Aurora 복제본에 대한 자세한 내용은 Aurora 복제본 단원을 참조하십시오.

Aurora 복제본은 클러스터 볼륨의 읽기 연산에 전적으로 사용되므로 읽기 조정에 유용합니다. 쓰기 연산은 기본 인스턴스에서 관리합니다. 클러스터 볼륨은 Aurora MySQL DB 클러스터의 모든 인스턴스가 공유하기 때문에 각 Aurora 복제본의 데이터 사본을 추가로 복제할 필요는 없습니다. 이와는 대조적으로 MySQL 읽기 전용 복제본은 소스 DB 인스턴스부터 로컬 데이터 스토어에 이르는 모든 쓰기 작업을 단일 스레드에서 재실행해야 합니다. 이러한 제한은 대용량 읽기 트래픽을 지원하는 MySQL 읽기 전용 복제본의 기능에 영향을 끼칠 수 있습니다.

Aurora MySQL을 사용하여 Aurora 복제본이 삭제될 때 인스턴스 엔드포인트가 즉시 제거되고, Aurora 복제본은 리더(Reader) 엔드포인트에서 제거됩니다. 삭제되는 Aurora 복제본을 실행하는 문이 있는 경우 3분의 유예 기간이 있습니다. 기존 문은 유예 기간 동안 정상적으로 완료할 수 있습니다. 유예 기간이 종료되면 Aurora 복제본이 종료 및 삭제됩니다.

중요

Aurora MySQL용 Aurora 복제본은 InnoDB 테이블의 작업에 대해 항상 기본 트랜잭션 격리 수준 REPEATABLE READ를 사용합니다. SET TRANSACTION ISOLATION LEVEL 명령을 사용하여 Aurora MySQL DB 클러스터의 기본 인스턴스에 대한 트랜잭션 수준만 변경할 수 있습니다. 이렇게 제한함에 따라 Aurora 복제본의 사용자 수준 잠금이 방지되고, 복제 지연 시간을 최소화하는 동시에 Aurora 복제본을 확장하여 수천 개의 활성 사용자 연결을 지원할 수 있습니다.

참고

기본 인스턴스에서 실행되는 DDL 문은 연결된 Aurora 복제본의 데이터베이스 연결을 중단할 수 있습니다. Aurora 복제본 연결에서 테이블 등 데이터베이스 객체를 적극적으로 사용 중이고 DDL 문을 사용하여 해당 객체를 기본 인스턴스에서 수정하는 경우 Aurora 복제본 연결이 중단됩니다.

참고

중국(닝샤) 리전은 리전 간 읽기 전용 복제본을 지원하지 않습니다.

Amazon Aurora MySQL의 복제 옵션

다음 옵션들 중에서 복제를 설정할 수 있습니다.

참고

Amazon Aurora DB 클러스터의 기본 인스턴스를 재부팅하면 DB 클러스터 전체에서 읽기/쓰기 일관성을 보장하는 진입점을 다시 설정하기 위해 해당 DB 클러스터에 대한 Aurora 복제본도 자동으로 재부팅됩니다.

Amazon Aurora MySQL 복제를 위한 성능 고려 사항

다음 기능을 사용하여 Aurora MySQL 복제본의 성능을 세부 조정할 수 있습니다.

복제본 로그 압축 기능은 복제 메시지에 대한 네트워크 대역폭을 자동으로 줄입니다. 각 메시지는 Aurora 복제본에 전송되기 때문에 크기가 큰 클러스터에 매우 유용한 기능입니다. 이 기능은 압축을 수행하기 위해 라이터(Writer) 노드에서 약간의 CPU 오버헤드가 발생합니다. Aurora MySQL 버전 2와 버전 3에서는 항상 활성화되어 있습니다.

binlog 필터링 기능은 복제 메시지에 대한 네트워크 대역폭을 자동으로 줄입니다. Aurora 복제본은 복제 메시지에 포함된 binlog 정보를 사용하지 않기 때문에 해당 노드로 전송된 메시지에서 이 데이터가 제외됩니다.

Aurora MySQL 버전 2에서 aurora_enable_repl_bin_log_filtering 파라미터를 변경하여 이 기능을 제어할 수 있습니다. 이 파라미터는 기본적으로 활성화됩니다. 이 최적화는 투명성을 위한 것이기 때문에 복제 관련 문제에 대한 진단이나 문제 해결 중에만 이 설정을 비활성화할 수 있습니다. 예를 들어 이 기능이 제공되지 않은 이전 버전 Aurora MySQL 클러스터의 동작과 일치시키기 위해 이 설정을 비활성화할 수 있습니다.

Aurora MySQL 버전 3에서는 Binlog 필터링이 항상 활성화되어 있습니다.

Amazon Aurora MySQL 복제 모니터링

읽기 조정과 고가용성은 최소 지연 시간에 따라 달라집니다. Amazon CloudWatch AuroraReplicaLag 지표를 모니터링하여 Aurora 복제본이 Aurora MySQL DB 클러스터의 기본 인스턴스보다 얼마나 지연되는지 모니터링할 수 있습니다. AuroraReplicaLag 지표는 각 Aurora 복제본에 기록됩니다.

기본 DB 인스턴스는 AuroraReplicaLagMaximumAuroraReplicaLagMinimum Amazon CloudWatch 지표도 기록합니다. AuroraReplicaLagMaximum 메트릭은 기본 DB 인스턴스와 DB 클러스터의 각 Aurora 복제본 간의 최대 지연 정도를 기록합니다. AuroraReplicaLagMinimum 메트릭은 기본 DB 인스턴스와 DB 클러스터의 각 Aurora 복제본 간의 최소 지연 정도를 기록합니다.

Aurora 복제본 지연의 최신 값이 필요할 경우 Amazon CloudWatch에서 AuroraReplicaLag 지표를 확인할 수 있습니다. Aurora 복제본 지연은 information_schema.replica_host_status 테이블에 있는 Aurora MySQL DB 클러스터의 각 Aurora 복제본에도 기록됩니다. 이 테이블에 대한 자세한 내용은 information_schema.replica_host_status 섹션을 참조하세요.

RDS 인스턴스 및 CloudWatch 지표 모니터링에 대한 자세한 내용은 Amazon Aurora 클러스터에서 지표 모니터링 단원을 참조하세요.