Amazon Aurora를 사용한 복제 - Amazon Aurora

Amazon Aurora를 사용한 복제

Aurora에서는 몇 가지 복제 옵션이 제공됩니다. 각 Aurora DB 클러스터에는 동일한 클러스터에 있는 여러 DB 인스턴스 간의 기본 제공 복제본이 있습니다. Aurora 클러스터를 소스 또는 타겟으로 하여 복제를 설정할 수도 있습니다. 클러스터에서 데이터를 복제하거나 Aurora 클러스터 외부로 복제할 때 Aurora 글로벌 데이터베이스와 같은 기본 제공 기능이나 MySQL 또는 PostgreSQL DB 엔진의 기존 복제 메커니즘 중에서 선택할 수 있습니다. 필요에 따라 고가용성, 편의성 및 성능을 적절하게 조합한 옵션을 선택할 수 있습니다. 다음 단원에서는 각 기법을 선택하는 방법과 시기를 설명합니다.

Aurora 복제본

Aurora 프로비저닝된 DB 클러스터에서 두 번째, 세 번째 등의 DB 인스턴스를 생성하면 Aurora는 라이터 DB 인스턴스에서 다른 모든 DB 인스턴스로의 복제를 자동으로 설정합니다. 이러한 다른 DB 인스턴스는 읽기 전용이며 Aurora 복제본이라고 합니다. 또한 클러스터 내에서 라이터 DB 인스턴스와 리더 DB 인스턴스를 결합할 수 있는 방법에 대해 논의할 때, 이 인스턴스를 리더 인스턴스라고 합니다.

Aurora 복제본에는 두 가지 주요 목적이 있습니다. 애플리케이션에 대한 읽기 작업을 확장하기 위해 쿼리를 실행할 수 있습니다. 일반적으로 클러스터의 읽기 장치 엔드포인트에 연결하여 이 작업을 수행합니다. 이렇게 하면 Aurora 는 읽기 전용 연결에 대한 로드를 클러스터에 있는 여러 Aurora 복제본에 분산할 수 있습니다. 또한 Aurora 복제본은 가용성을 높이는 데 도움이 됩니다. 클러스터의 작성기 인스턴스를 사용할 수 없게 되면 Aurora는 읽기 장치 인스턴스 중 하나를 자동으로 승격하여 새 작성기로 사용합니다.

Aurora DB 클러스터는 최대 15 개의 Aurora 복제본을 포함할 수 있습니다. Aurora 복제본을 AWS 리전 내 DB 클러스터에 포함된 가용 영역에 배포할 수 있습니다.

DB 클러스터의 데이터에는 클러스터 내 DB 인스턴스와 무관하게 자체 고가용성 및 안정성 기능이 있습니다. Aurora 스토리지 기능에 익숙하지 않은 경우 Aurora 스토리지 개요 단원을 참조하십시오. DB 클러스터 볼륨은 물리적으로 DB 클러스터에 대한 데이터의 여러 복사본으로 구성됩니다. DB 클러스터의 기본 인스턴스 및 Aurora 복제본에는 클러스터 볼륨 데이터가 단 하나의 논리 볼륨으로 표시됩니다.

따라서 모든 Aurora 복제본은 쿼리 결과에 대해 동일한 데이터를 반환하며 복제본 지연이 최소화됩니다. 이러한 지연은 대개 기본 인스턴스에서 업데이트를 쓴 후 100밀리초를 넘지 않습니다. 데이터베이스 변경률에 따라 달라집니다. 즉, 데이터베이스의 쓰기 연산이 많은 기간에는 복제본 지연 시간이 증가할 수 있습니다.

Aurora 복제본은 클러스터 볼륨의 읽기 연산에 전적으로 사용되므로 읽기 조정에 유용합니다. 쓰기 연산은 기본 인스턴스에서 관리합니다. 클러스터 볼륨은 DB 클러스터의 모든 DB 인스턴스가 공유하기 때문에 각 Aurora 복제본의 데이터 사본을 추가로 복제할 필요가 거의 없습니다.

가용성을 높이려면 Aurora 복제본을 장애 조치 대상으로 사용할 수 있습니다. 즉 기본 인스턴스에 장애가 발생하면 Aurora 복제본이 기본 인스턴스로 승격됩니다. 기본 인스턴스에 대한 읽기/쓰기 요청이 예외로 인해 장애가 발생하는 동안에는 시스템이 짧게 중단됩니다. 이 경우 DB 엔진 버전에 따라 일부 Aurora 복제본이 재부팅될 수 있습니다. 서로 다른 Aurora DB 엔진 버전의 재부팅 동작에 대한 자세한 내용은 Amazon Aurora DB 클러스터 또는 Amazon Aurora DB 인스턴스 재부팅 섹션을 참조하세요. 하지만 Aurora 복제본을 승격시키는 것이 기본 인스턴스를 재생성하는 것보다 훨씬 빠릅니다. Aurora DB 클러스터에 Aurora 복제본이 포함되어 있지 않으면 DB 인스턴스가 장애에서 복구되는 동안 DB 클러스터를 사용할 수 없습니다.

고가용성 시나리오에서는 Aurora 복제본을 1개 이상 생성하는 것이 좋습니다. 이때 복제본은 DB 인스턴스 클래스가 기본 인스턴스의 클래스와 동일해야 하고, 가용 영역이 Aurora DB 클러스터의 가용 영역과 달라야 합니다. 장애 조치 대상인 Aurora 복제본에 대한 자세한 내용은 Aurora DB 클러스터의 내결함성 섹션을 참조하세요.

암호화되지 않은 Aurora DB 클러스터의 암호화된 Aurora 복제본을 생성할 수 없습니다. 암호화된 Aurora DB 클러스터의 암호화되지 않은 Aurora 복제본을 생성할 수 없습니다.

작은 정보

Aurora 클러스터 내 Aurora 복제본을 유일한 복제 형식으로 사용하여 데이터의 고가용성을 유지할 수 있습니다. 기본 제공 Aurora 복제본을 다른 유형의 복제본과 결합할 수도 있습니다. 이렇게 하면 데이터의 고가용성과 지리적 분포를 한층 더 높일 수 있습니다.

Aurora 복제본 생성 방법에 대한 자세한 내용은 DB 클러스터에 Aurora 복제본 추가 단원을 참조하십시오.

Aurora MySQL를 사용한 복제

Aurora 복제본 외에도 다음과 같이 Aurora MySQL로 복제에 사용할 수 있는 옵션이 있습니다:

  • 여러 다른 AWS 리전에 있는 Aurora MySQL DB 클러스터

    • Aurora 전역 데이터베이스를 사용하여 여러 리전에서 데이터를 복제할 수 있습니다. 자세한 내용은 Aurora Global Database를 사용한 AWS 리전 간 고가용성 섹션을 참조하세요.

    • MySQL 이진 로그(binlog) 복제를 사용하여 다른 AWS 리전에 Aurora MySQL DB 클러스터의 Aurora 읽기 전용 복제본을 생성할 수 있습니다. 각 클러스터는 서로 다른 각 리전에 최대 5개의 읽기 전용 복제본을 생성할 수 있습니다.

  • MySQL 이진 로그(binlog) 복제를 사용하여 동일한 리전에 있는 Aurora MySQL DB 클러스터 2개

  • RDS for MySQL DB 인스턴스의 Aurora 읽기 전용 복제본을 생성하여 데이터의 소스인 RDS for MySQL DB 인스턴스와 Aurora MySQL DB 클러스터를 설정합니다. 일반적으로 이 방법은 진행 중인 복제보다는 Aurora MySQL으로의 마이그레이션에 사용됩니다.

Aurora MySQL을 사용한 복제에 대한 자세한 내용은 Amazon Aurora MySQL를 사용하는 단일 마스터 복제 단원을 참조하십시오.

Aurora PostgreSQL를 사용한 복제

Aurora 복제본 외에도 다음과 같이 Aurora PostgreSQL로 복제에 사용할 수 있는 옵션이 있습니다:

  • Aurora Global Database를 사용하여 한 리전의 Aurora 프라이머리 DB 클러스터와 서로 다른 리전의 최대 5개의 읽기 전용 세컨더리 DB 클러스터. 즉, Aurora PostgreSQL은 교차 리전 Aurora 복제본을 지원하지 않습니다. 하지만 Aurora Global Database를 사용하여 Aurora PostgreSQL DB 클러스터의 읽기 기능을 둘 이상의 AWS 리전으로 확장하고 가용성 목표를 달성할 수 있습니다. 자세한 정보는 Amazon Aurora 글로벌 데이터베이스 사용을 참조하십시오.

  • PostgreSQL의 논리적 복제 기능을 사용하여 2개의 Aurora PostgreSQL DB 클러스터는 동일한 리전에 위치합니다.

  • RDS for PostgreSQL DB 인스턴스의 Aurora 읽기 전용 복제본을 생성하여 데이터의 소스인 RDS for PostgreSQL DB 인스턴스와 Aurora PostgreSQL DB 클러스터를 설정합니다. 일반적으로 이 방법은 진행 중인 복제보다는 Aurora PostgreSQL으로의 마이그레이션에 사용됩니다.

Aurora PostgreSQL을 사용한 복제에 대한 자세한 내용은 Amazon Aurora PostgreSQL를 사용한 복제 단원을 참조하십시오.