메뉴
Amazon Relational Database Service
사용 설명서 (API Version 2014-10-31)

Amazon Aurora를 사용한 복제

Aurora 복제본은 Aurora DB 클러스터에서 독립된 엔드포인트이며, 읽기 연산을 조정하여 가용성을 높이는 데 가장 적합합니다. 단일 리전 내에서 DB 클러스터에 포함된 가용 영역에 배포할 수 있는 최대 Aurora 복제본 수는 15개입니다. DB 클러스터 볼륨은 DB 클러스터의 여러 데이터 사본으로 구성되어 있지만, DB 클러스터의 기본 인스턴스 및 Aurora 복제본에는 클러스터 볼륨 데이터가 단 하나의 논리 볼륨으로 표시됩니다.

그 결과, 모든 Aurora 복제본은 복제본 지연 시간을 최소화하여 쿼리 결과에 대한 데이터를 동일하게 반환합니다. 이 지연 시간은 기본 인스턴스가 업데이트를 적용한 후 100밀리초 미만이지만 데이터베이스 변경률에 따라 달라집니다. 즉, 데이터베이스의 쓰기 연산이 많은 기간에는 복제본 지연 시간이 증가할 수 있습니다.

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

가용성을 높이려면 Aurora 복제본을 장애 조치 대상으로 사용할 수 있습니다. 즉, 기본 인스턴스에 결함이 발생하면 기본 인스턴스에 대한 읽기 및 쓰기 요청이 예외적으로 실패하면서 인스턴스가 아주 잠시 중단되고, 이때 Aurora 복제본이 기본 인스턴스로 승격됩니다. Aurora DB 클러스터에 Aurora 복제본이 없는 경우에는 기본 인스턴스가 장애 조치 이벤트를 통해 재생성됩니다. 하지만 Aurora 복제본을 승격시키는 것이 기본 인스턴스를 재생성하는 것보다 훨씬 빠릅니다. 고가용성 시나리오에서는 DB 인스턴스 클래스가 기본 인스턴스와 동일한 Aurora 복제본을 하나 이상 Aurora DB 클러스터의 다른 가용 영역에 생성하는 것이 바람직합니다. 장애 조치 대상인 Aurora 복제본에 대한 자세한 내용은 Aurora DB 클러스터의 내결함성을(를) 참조하십시오.

중요

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

Aurora 복제본 생성 방법에 대한 세부 정보는 콘솔을 사용한 Aurora 복제본 생성을(를) 참조하십시오.

서로 다른 AWS 리전에 속하는 두 Amazon Aurora DB 클러스터 간의 복제를 설정할 수 있습니다. 자세한 내용은 여러 AWS 리전에 걸쳐 Amazon Aurora DB 클러스터 복제을(를) 참조하십시오.

MySQL 이진 로그(binlog) 복제를 사용하여 두 Amazon Aurora DB 클러스터 간의 복제를 설정할 수 있습니다. 자세한 내용은 Aurora와 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터 간의 복제을(를) 참조하십시오.

MySQL DB 인스턴스의 Aurora 읽기 복제본을 생성하여 마스터인 RDS MySQL DB 인스턴스와 Aurora DB 클러스터 간 복제를 설정할 수 있습니다. 일반적으로 이 방법은 진행 중인 복제보다는 Aurora로의 마이그레이션에 사용됩니다. 자세한 내용은 읽기 전용 복제본을 사용하여 MySQL DB 인스턴스에서 Amazon Aurora DB 클러스터로 데이터 마이그레이션을(를) 참조하십시오.

참고

Amazon Aurora DB 클러스터의 기본 인스턴스를 재부팅하면 해당 DB 클러스터의 Aurora 복제본도 자동으로 재부팅됩니다.

Aurora 복제 모니터링

읽기 조정과 고가용성은 최소 지연 시간에 따라 달라집니다. Amazon CloudWatch ReplicaLag 지표를 모니터링하면 Aurora 복제본의 Aurora DB 클러스터 기본 인스턴스 지연 시간을 모니터링할 수 있습니다. Aurora 복제본은 기본 인스턴스와 동일한 클러스터 볼륨에서 읽혀지므로 ReplicaLag 지표가 Aurora DB 클러스터에서와 다른 의미를 갖습니다. Aurora 복제본의 ReplicaLag 지표는 기본 인스턴스 대비 Aurora 복제본의 페이지 캐시 지연 시간을 나타냅니다.

Aurora 복제본 지연 시간의 최신 값이 필요할 경우 Aurora DB 클러스터의 mysql.ro_replica_status 테이블을 쿼리하여 Replica_lag_in_msec 열의 값을 확인할 수 있습니다. 이 열 값은 Amazon CloudWatch에 ReplicaLag 지표 값으로 제공됩니다. mysql.ro_replica_status의 값은 Aurora DB 클러스터의 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 테이블에도 제공됩니다.

RDS 인스턴스 및 CloudWatch 지표 모니터링에 대한 자세한 내용은 Amazon RDS 모니터링 단원을 참조하십시오.

이 페이지에서: