RDS Custom for Oracle 다중 AZ 배포에 대한 장애 조치 프로세스
계획되거나 계획되지 않은 DB 인스턴스의 운영 중단으로 인해 인프라 장애가 발생한 경우, 다중 AZ를 설정하면 Amazon RDS는 자동으로 다른 가용 영역의 대기 복제본으로 전환됩니다. 장애 조치가 완료되는 데 소요되는 시간은 프라이머리 DB 인스턴스를 사용할 수 없게 된 시점의 데이터베이스 활동 및 기타 조건에 따라 달라집니다. 장애 조치에 소요되는 시간은 일반적으로 60~120초입니다. 그러나 트랜잭션의 규모가 크거나 복구 프로세스가 복잡한 경우 장애 조치에 소요되는 시간이 증가할 수 있습니다. 장애 조치가 완료되면 Amazon RDS 콘솔에 새 가용 영역이 표시되는 데 시간이 더 걸릴 수 있습니다.
참고
DB 인스턴스를 사용할 수 있는 동안 기본 EC2 호스트를 중지하고 시작할 때 장애 조치를 수동으로 수행할 수 있습니다.
Amazon RDS는 자동으로 장애 조치를 취하여 관리자의 개입 없이 데이터베이스 작업을 신속하게 재개할 수 있도록 합니다. 다음 표에 설명된 조건 중 하나가 발생하면 기본 DB 인스턴스는 자동으로 예비 복제본으로 전환됩니다. 이 장애 조치 이유는 Amazon RDS 이벤트 로그에서 확인할 수 있습니다.
| 장애 조치 이유 | 설명 |
|---|---|
| RDS 데이터베이스 인스턴스 기반의 운영 체제가 오프라인 작업에서 패치되고 있습니다. | OS 패치 또는 보안 업데이트를 위한 유지 관리 기간 동안 장애 조치가 트리거되었습니다. 자세한 내용은 DB 인스턴스 유지 관리 섹션을 참조하세요. |
| RDS 다중 AZ 인스턴스의 기본 호스트가 비정상입니다. | 다중 AZ DB 인스턴스 배포에서 손상된 프라이머리 DB 인스턴스를 감지하여 장애 조치를 수행했습니다. |
| 네트워크 연결 손실로 인해 RDS 다중 AZ 인스턴스의 기본 호스트에 연결할 수 없습니다. | RDS 모니터링이 기본 DB 인스턴스에 대한 네트워크 연결 실패를 감지하여 장애 조치를 트리거했습니다. |
| RDS 인스턴스를 고객이 수정했습니다. | RDS DB 인스턴스 수정 때문에 장애 조치가 트리거되었습니다. 자세한 내용은 RDS Custom for Oracle DB 인스턴스 수정 섹션을 참조하세요. |
| RDS 다중 AZ 인스턴스의 기본 호스트 기반의 스토리지 볼륨에 오류가 발생했습니다. | 다중 AZ DB 인스턴스 배포가 프라이머리 DB 인스턴스에서 스토리지 문제를 감지하여 장애 조치를 수행했습니다. |
| RDS 다중 AZ 기본 인스턴스가 사용 중이며 응답하지 않습니다. | 기본 DB 인스턴스가 응답하지 않습니다. CPU, 메모리 또는 스왑 공간이 과도하게 사용되는지 이벤트 및 CloudWatch 로그에서 조사하는 것이 좋습니다. 자세한 내용은 Amazon RDS 이벤트 알림 작업 및 Amazon RDS 이벤트에서 트리거되는 규칙 생성 단원을 참조하십시오. 워크로드를 평가하여 적절한 DB 인스턴스 클래스를 사용 중인지 확인합니다. 자세한 내용은 DB 인스턴스 클래스 섹션을 참조하세요. |
다음 단계에 따라 다중 AZ DB 인스턴스가 장애 조치를 수행했는지 확인할 수 있습니다.
-
장애 조치가 시작되었음을 이메일 또는 SMS로 사용자에게 알리도록 DB 이벤트 구독을 설정합니다. 이벤트에 대한 자세한 내용은 Amazon RDS 이벤트 알림 작업 단원을 참조하세요.
-
Amazon RDS 콘솔 또는 API 작업을 사용하여 DB 이벤트를 확인합니다.
-
Amazon RDS 콘솔, CLI 또는 API 작업을 사용하여 RDS Custom for Oracle 다중 AZ DB 인스턴스 배포의 현재 상태를 확인합니다.
RDS Custom for Oracle 다중 AZ 배포를 사용하는 애플리케이션의 유지 시간(TTL) 설정
장애 조치 메커니즘은 DB 인스턴스의 Domain Name System(DNS) 레코드가 예비 DB 인스턴스를 가리키도록 자동으로 변경합니다. 그 결과 DB 인스턴스의 기존 연결을 모두 재설정해야 합니다. DNS 캐시 TTL(Time-to-Live) 구성 값이 낮은지 확인하고, 애플리케이션이 오랜 시간 동안 DNS를 캐시하지 않는지 확인합니다. TTL 값이 높으면 장애 조치 후 애플리케이션이 DB 인스턴스에 빠르게 다시 연결되지 않을 수 있습니다.
