Aurora 읽기 전용 복제본이 지연되고 재시작되는 문제를 해결하려면 어떻게 해야 합니까?

해결 방법

참고: 다음 해결 방법은 단일 AWS 리전 및 글로벌 데이터베이스 기본 클러스터의 Aurora 클러스터에 적용되며 글로벌 데이터베이스 보조 클러스터에는 적용되지 않습니다.

AuroraReplicaLag 측정

Aurora 복제본은 라이터 인스턴스와 동일한 스토리지 볼륨에 연결됩니다. Aurora는 변경 사항을 공유 스토리지 볼륨에 동기식으로 기록하지만 변경 사항을 리더 인스턴스에 비동기식으로 복제합니다. 읽기 일관성을 위해 Aurora는 변경 사항과 관련한 메모리에 캐시된 데이터를 무효화합니다. 데이터 캐시는 버퍼 풀 또는 페이지 캐시를 포함합니다.

경우에 따라 변경 사항을 리더 인스턴스 전체에 전파할 때 지연이 발생할 수 있습니다. 이 지연은 Amazon CloudWatch의 AuroraReplicaLag 지표가 증가함에 따라 나타나며, 이로 인해 재시작이 발생할 수 있으며 다음과 같은 오류 메시지가 표시될 수 있습니다.

"Read Replica has fallen behind the master too much. Restarting".

Amazon Aurora MySQL 호환 버전의 경우 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 테이블에서 다음 쿼리를 실행하여 AuroraReplicaLag를 측정합니다.

select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID', 'writer', 'reader') as Role, replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

출력 예시:

+---------------------+--------+-------------------+  
| Instance_Identifier | Role   | AuroraReplicaLag  |  
+---------------------+--------+-------------------+  
| myamscluster-aza-1  | writer |                 0 |  
| myamscluster-azb-1  | reader | 5.150000095367432 |  
| myamscluster-aza-2  | reader | 5.033999919891357 |  
+---------------------+--------+-------------------+

Amazon Aurora PostgreSQL 호환 버전의 경우 다음 쿼리를 실행하여 aurora_replica_status() 함수를 가져오고 결과를 필터링합니다.

select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

출력 예시:

server_id          | role   | aurorareplicalag  
-------------------+--------+------------------  
myapgcluster-aza-1 | Reader | 19.641  
myapgcluster-azb-1 | Reader | 19.752  
myapgcluster-aza-2 | Writer |  
(3 rows)

클러스터의 모든 인스턴스에 동일한 사양이 있는지 확인

리더 인스턴스의 DB 인스턴스 클래스 구성이 라이터 DB 인스턴스보다 낮으면 변경 횟수가 너무 많을 수 있습니다. 그러면 캐시에서 리더 인스턴스를 무효화할 수 없습니다. 이 문제를 방지하려면 Aurora 클러스터의 모든 DB 인스턴스에 대해 동일한 사양을 유지하는 것이 좋습니다.

지표와 향상된 모니터링을 통한 세션 모니터링

여러 세션을 동시에 실행하는 경우 리더 인스턴스가 지연될 수 있습니다. 사용 가능한 리소스가 부족하기 때문에 Aurora 복제본은 리더의 필요한 변경 사항을 느리게 적용할 수 있습니다. 지연을 확인하려면 CPUUtilization, DBConnections 및 NetworkReceiveThroughput 지표를 확인하십시오. 1초 또는 5초 단위로 향상된 모니터링을 활성화하여 리더의 리소스 사용량을 확인할 수도 있습니다. 또는 Performance Insights를 활성화하고 Database Insights를 사용하여 리더의 워크로드를 시각화합니다. Aurora PostgreSQL 호환의 경우 ReadIOPS 지표를 사용할 수 있습니다.

중요: Performance Insights는 2026년 6월 30일에 서비스가 종료됩니다. 2026년 6월 30일 이전에 Database Insights의 고급 모드로 업그레이드할 수 있습니다. 업그레이드하지 않으면 Performance Insights를 사용하는 DB 클러스터는 Database Insights의 표준 모드로 기본 설정됩니다. Database Insights의 고급 모드만 실행 계획과 온디맨드 분석을 지원합니다. 클러스터가 표준 모드로 기본 설정된 경우 콘솔에서 이러한 기능을 사용하지 못할 수 있습니다. 고급 모드를 활성화하려면 Amazon RDS용 Database Insights의 고급 모드 활성화 및 Amazon Aurora용 Database Insights의 고급 모드 활성화를 참조하십시오.

CloudWatch를 사용하여 쓰기 활동 시각화

이미 쓰기 작업이 많은 프로덕션 클러스터에서 쓰기 활동이 갑자기 급증하면 라이터 DB 인스턴스에 과부하가 걸릴 수 있습니다. 과부하로 인해 리더 인스턴스가 지연될 수 있습니다. CloudWatch를 사용하여 갑작스러운 버스트를 보여주는 DMLThroughput, DDLThroughput 및 Queries 지표를 확인할 수 있습니다. Aurora PostgreSQL 호환의 경우 WriteThroughput 지표를 확인하십시오.

Aurora MySQL 호환의 장기 실행 트랜잭션 문제 해결

MySQL InnoDB 엔진은 기본적으로 다중 버전 동시성 제어(MVCC)를 사용합니다. 따라서 트랜잭션 기간 동안 발생한 행의 모든 변경 사항을 추적해야 합니다. 장기 실행 트랜잭션이 완료되면 제거 스레드 활동이 급증하기 시작합니다. 갑작스러운 제거로 인해 장기 실행 트랜잭션이 만드는 백로그의 볼륨에 따라 Aurora 복제본이 지연될 수 있습니다.

Aurora MySQL 호환의 경우 CloudWatch에 있는 RollbackSegmentHistoryListLength 지표를 확인하여 제거의 급증을 확인하십시오. SHOW ENGINE INNODB STATUS 명령을 실행하여 제거를 볼 수 있습니다. 또는 다음 쿼리를 실행하십시오.

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

출력 예시:

+----------------------------------+-------+  
| RollbackSegmentHistoryListLength | COUNT |  
+----------------------------------+-------+  
| trx_rseg_history_len             |   358 |  
+----------------------------------+-------+  
1 row in set (0.00 sec)

높은 수치에 도달하지 않도록 CloudWatch 경보를 설정하여 RollbackSegmentHistoryListLength를 모니터링합니다. 관계형 데이터베이스에서는 장기 실행 트랜잭션을 방지하는 것이 좋습니다.

일시적인 네트워크 중단 방지

드물긴 하지만 라이터와 리더 인스턴스 간 또는 인스턴스와 Aurora 스토리지 계층 간에 일시적인 네트워킹 통신 장애가 발생할 수 있습니다. 리더 인스턴스는 네트워킹이 잠시 중단되어 지연되거나 다시 시작될 수 있습니다. 변경 횟수가 많아 인스턴스의 네트워크 대역폭에 과부하가 걸리기 때문에 Aurora 복제본이 지연될 수도 있습니다. 이 문제를 방지하려면 DB 인스턴스의 크기를 변경 횟수를 처리할 수 있는 크기로 수정하는 것이 좋습니다.

관련 정보

DB 클러스터에 Aurora 복제본 추가

Amazon Aurora MySQL 호환과 복제

Amazon Aurora 클러스터의 지표 모니터링

Amazon Aurora의 인스턴스 수준 지표