Amazon Aurora에서 읽기 전용 복제본을 사용할 때 발생하는 일반적인 문제를 해결하려면 어떻게 해야 하나요?

4분 분량

Amazon Aurora MySQL DB 인스턴스가 있는데 읽기 전용 복제본으로 작업할 때 문제가 발생합니다. Amazon Aurora에서 읽기 전용 복제본을 사용할 때 발생하는 일반적인 문제를 해결하려면 어떻게 해야 하나요?

간략한 설명

Amazon Aurora MySQL은 동일한 AWS 리전에 있는 라이터 DB 인스턴스와 공통 기본 볼륨을 공유하는 읽기 전용 복제본을 지원합니다. 라이터 DB 인스턴스를 변경하면 DB 클러스터의 복제본 인스턴스에 업데이트가 표시됩니다. 리전 간 MySQL 읽기 전용 복제본을 생성할 수도 있습니다. 이러한 기능은 MySQL binlog 기반 복제 엔진을 사용하여 구현됩니다.

읽기 작업을 확장할 때 Aurora 복제본을 사용하는 것이 가장 좋습니다. 이 작업은 라이터에서의 읽기 워크로드를 줄임으로써 수행할 수 있습니다. 그런 다음 확장을 느리게 하거나 차단하는 이벤트를 처리할 수 있도록 가용성을 높입니다.

해결 방법

Aurora 읽기 전용 복제본을 승격하려면 어떻게 해야 하나요?

수동 장애 조치 - 수동 장애 조치를 수행하여 다음 단계에 따라 다른 읽기 전용 복제본 인스턴스를 라이터 인스턴스로 승격시킵니다.

Amazon Relational Database Service(Amazon RDS) 콘솔에 로그인합니다.
탐색 창에서 [데이터베이스]를 선택합니다.
Aurora DB 클러스터의 라이터 인스턴스를 선택합니다.
[작업]을 선택한 후 [장애 조치]를 선택합니다.

자동 장애 조치 - 라이터 인스턴스를 사용할 수 없게 되면 Aurora가 자동으로 읽기 전용 복제본 인스턴스로 장애 조치를 취합니다. 이 문제는 리소스 경합 및 유지 관리 작업 등 여러 가지 이유로 발생할 수 있습니다. 리더가 여러 개인 경우 클러스터의 각 인스턴스에 승격 우선순위 티어를 부여할 수 있습니다. 라이터 인스턴스가 실패하면 Aurora는 우선 순위가 가장 높은 복제본을 새 라이터로 승격합니다.

교차 리전 Aurora 복제본을 독립 실행형 DB 클러스터로 승격할 수도 있습니다. 승격 프로세스를 시작하면 교차 리전 복제가 중단됩니다. 새로 승격된 클러스터는 독립 DB 클러스터로 작동하며 읽기 및 쓰기 작업을 모두 처리합니다.

복제 지연을 어떻게 측정할 수 있나요?

단일 DB 클러스터의 모든 Aurora DB 인스턴스는 공통 데이터 볼륨을 공유하므로 복제 지연이 최소화됩니다. 일반적으로 지연 시간은 수십 밀리초 단위입니다. 그러나 몇 가지 특정 상황에서 리더의 지연이 약간 증가하는 것을 관찰할 수 있습니다.

참고: 교차 리전 복제본은 논리적 복제를 사용하기 때문에 변경률/적용률과 선택한 특정 리전 간의 네트워크 통신 지연의 영향을 받습니다. Aurora 데이터베이스를 사용한 교차 리전 복제본은 일반적으로 지연 시간이 1초 미만입니다.

다음과 같은 Amazon CloudWatch 지표를 사용하여 복제 지연을 측정할 수 있습니다.

AuroraReplicaLag를 사용하여 라이터와 리더 노드 간의 복제 지연을 밀리초 단위로 측정합니다(동일한 리전).
이진 로그를 사용하는 Aurora DB 클러스터 간의 복제본 지연을 측정하려면 AuroraBinlogReplicaLag를 사용합니다.

복제 성능을 향상시키려면 어떻게 해야 하나요?

복제 지연을 개선하려면 다음 권장 사항을 따르세요.

리더 인스턴스가 라이터 인스턴스보다 작은 경우 변경 볼륨이 너무 커서 리더가 처리할 수 없을 수 있습니다. 리더 인스턴스의 워크로드 과부하를 방지하기 위해 클러스터의 모든 인스턴스가 동일한 크기를 갖는 것이 가장 좋습니다.
라이터에 많은 워크로드가 있는 경우 임시 읽기 전용 복제본이 지연될 수 있습니다. 리더 인스턴스가 라이터 인스턴스를 따라 잡으면 지연이 줄어듭니다.
진행 중인 장기 실행 트랜잭션이 있는 경우 리더에서 복제 지연을 관찰할 수 있습니다. 복제 지연을 방지하려면 트랜잭션을 더 작은 일괄 처리로 실행하고 커밋을 더 자주 실행합니다.

네이티브 binlog 기반 MySQL 복제를 사용하여 높은 복제본 지연 문제를 해결하는 방법에 대한 자세한 내용은 Aurora DB 클러스터 백업 및 복원 개요를 참조하세요.

Global Transaction Identifier(GTID)를 사용할 수 있나요?

Global Transaction Identifier는 커밋의 트랜잭션에 연결된 고유 문자열입니다. GTID는 모든 서버에서 고유하며 변경 사항은 GTID 값에 따라 대상에 적용됩니다. 자세한 내용은 GTID 개념에 대한 MySQL 설명서를 참조하세요.

Aurora는 네이티브 binlog 복제를 사용하여 데이터를 읽기 전용 복제본 인스턴스로 복제하지 않습니다. GTID를 사용하여 동일한 클러스터의 인스턴스 간에 데이터를 복제할 수는 없습니다. 그러나 특정 시나리오에서 GTID 기반 복제를 설정할 수 있습니다. Aurora MySQL에서 GTID 기반 복제를 사용하는 방법에 대한 자세한 내용은 GTID에 대한 AWS 블로그를 참조하세요.

참고: Amazon RDS MySQL과 Aurora 클러스터 간 및 Aurora 클러스터 간에 GTID 기반 복제를 설정할 수 있습니다(소스가 외부 마스터라고 가정). 복제 프로세스를 시작하기 전에 소스에서 binlog를 사용하도록 설정해야 합니다.