Aurora MySQL 호환 DB 인스턴스에서 읽기 전용 복제본을 사용할 때 발생하는 문제를 해결하려면 어떻게 해야 합니까?

3분 분량

Amazon Aurora MySQL 호환 버전 DB 인스턴스에서 읽기 전용 복제본을 사용할 때 문제가 발생합니다. 이러한 문제를 해결하고 싶습니다.

해결 방법

Aurora MySQL 호환 읽기 전용 복제본 승격

라이터 인스턴스를 재부팅하거나 유지 관리해야 하는 경우 수동 장애 조치를 수행하여 읽기 전용 복제본을 라이터 인스턴스로 승격시킵니다.

수동 장애 조치를 수행하려면 다음 단계를 완료하십시오.

Amazon RDS 콘솔을 엽니다.
탐색 창에서 데이터베이스를 선택합니다.
Aurora DB 클러스터의 라이터 인스턴스를 선택합니다.
작업을 선택하고 장애 조치를 선택합니다.

라이터 인스턴스를 사용할 수 없는 경우 Aurora MySQL 호환 기능이 자동으로 읽기 전용 복제본 인스턴스로 장애 조치를 수행합니다. 라이터 인스턴스는 리소스 경합 또는 유지 관리 활동 등 여러 가지 이유로 사용할 수 없게 될 수 있습니다.

여러 리더가 있는 경우 클러스터의 각 인스턴스에 대해 승격 우선 순위 티어를 지정하십시오. 라이터 인스턴스에 장애가 발생하면 Aurora MySQL 호환 기능에서 우선 순위가 가장 높은 복제본을 새 라이터로 승격합니다.

또한 AWS 리전 간 Aurora 복제본을 독립형 DB 클러스터로 승격할 수도 있습니다. 승격 프로세스를 시작하면 리전 간 복제가 중지됩니다. 승격된 클러스터는 독립적인 DB 클러스터로 기능하며 읽기 및 쓰기 작업을 모두 관리합니다.

복제 지연 시간 측정

DB 클러스터의 모든 Aurora DB 인스턴스는 공통 데이터 볼륨을 공유하므로 복제 지연 시간이 최소화됩니다. 그러나 일부 시나리오에서는 리더의 지연이 약간 증가할 수 있습니다.

참고: 리전 간 복제본은 바이너리 로그 복제를 사용합니다. 선택한 리전 간의 네트워크 통신 속도 및 지연을 변경하고 적용하면 리전 간 복제본에 영향을 미칠 수 있습니다. Aurora MySQL 데이터베이스를 사용하는 리전 간 복제본의 지연 시간은 일반적으로 1초 미만입니다.

복제 지연 시간을 측정하려면 다음 Amazon CloudWatch 지표를 사용하십시오.

AuroraReplicaLag 지표는 동일한 리전에서 라이터와 리더 노드 간의 복제 지연을 밀리초 단위로 측정합니다.
AuroraBinlogReplicaLag 지표는 바이너리 로그를 사용하는 Aurora DB 클러스터 간의 복제 지연을 측정합니다.

위 지표에 대한 자세한 내용은 Amazon Aurora의 인스턴스 수준 지표를 참조하십시오.

복제 성능 향상

다음 작업을 수행하십시오.

리더 인스턴스의 과중한 워크로드를 피하려면 클러스터의 모든 인스턴스를 같은 크기로 만드는 것이 좋습니다. 리더 인스턴스가 라이터 인스턴스보다 작으면 변경량이 너무 커서 리더가 따라잡을 수 없을 수 있습니다.
참고: 라이터 인스턴스에 과중한 워크로드가 있는 경우 일시적인 읽기 전용 복제본 지연이 발생할 수 있습니다. 리더 인스턴스가 라이터 인스턴스와 일치하면 지연이 줄어듭니다.
장기 실행 트랜잭션이 진행 중일 때 복제 지연 시간을 방지하려면 트랜잭션을 더 작은 배치로 실행하고 자주 커밋을 실행합니다.

네이티브 바이너리 로그 기반 MySQL 복제를 사용하여 복제 지연 문제를 해결하는 방법에 대한 자세한 내용은 Amazon Aurora MySQL 복제 문제를 참조하십시오.

높은 복제 지연 문제 해결

AuroraReplicaLag CloudWatch 지표를 사용하여 긴 복제 지연 시간을 확인하십시오. 복제 지연이 심하면 리더 인스턴스가 다시 시작될 수 있습니다. 이 문제를 해결하려면 Amazon Aurora 읽기 전용 복제본이 지연되어 다시 시작된 이유는 무엇입니까?를 참조하십시오.

GTID 기반 복제 설정

Aurora는 네이티브 바이너리 로그 복제를 사용하여 데이터를 읽기 전용 복제본 인스턴스에 복제하지 않습니다. 글로벌 트랜잭션 식별자(GTID)를 사용하여 동일한 클러스터의 인스턴스 간에 데이터를 복제할 수 없습니다. 그러나 일부 시나리오에서는 GTID 기반 복제를 설정할 수 있습니다. Aurora MySQL과 호환되는 환경에서 GTID 기반 복제를 사용하는 방법에 대한 자세한 내용은 전역 트랜잭션 식별자(GTID) 복제를 지원하는 Amazon Aurora for MySQL 호환성을 참조하십시오.

Aurora MySQL 호환 버전 3.04 이상에서는 멀티스레드 바이너리 로그 복제가 활성화되고 replica_parallel_workers는 기본적으로 4로 설정됩니다. 멀티스레드 바이너리 로그 복제가 활성화되므로 예기치 않은 중단에 대비하여 데이터베이스의 복원력을 높여야 합니다. 소스에서 GTID 복제를 활성화하고 복제본에서 GTID를 허용하는 것이 좋습니다.

참고: Amazon Relational Database Service(Amazon RDS) for MySQL과 Aurora 클러스터 간 및 Aurora 클러스터 간에 GTID 기반 복제를 설정할 수 있습니다. 소스는 외부 프라이머리 서버여야 합니다. 복제 프로세스를 시작하기 전에 소스에서 바이너리 로깅을 활성화해야 합니다.

GTID에 대한 자세한 내용은 MySQL 웹 사이트에서 GTID 형식 및 스토리지를 참조하십시오.