Amazon RDS에 대한 다중 AZ DB 인스턴스 장애 조치 - Amazon Relational Database Service
DNS 이름 조회를 위한 JVM TTL 설정

Amazon RDS에 대한 다중 AZ DB 인스턴스 장애 조치

계획되거나 계획되지 않은 다중 AZ DB 인스턴스의 운영 중단으로 인해 인프라 장애가 발생한 경우, Amazon RDS는 자동으로 다른 가용 영역의 대기 복제본으로 전환됩니다.

장애 조치가 완료되는 데 소요되는 시간은 프라이머리 DB 인스턴스를 사용할 수 없게 된 시점의 데이터베이스 활동 및 기타 조건에 따라 달라집니다. 장애 조치에 소요되는 시간은 일반적으로 60–120초입니다. 그러나 트랜잭션의 규모가 크거나 복구 프로세스가 복잡한 경우 장애 조치에 소요되는 시간이 증가할 수 있습니다. 장애 조치가 완료되면 RDS 콘솔에 새 가용 영역이 반영되는 데 시간이 더 걸릴 수 있습니다.

참고

다중 AZ DB 인스턴스를 재부팅할 때 장애 조치를 수동으로 강제할 수 있습니다. 자세한 내용은 DB 인스턴스 재부팅 단원을 참조하십시오.

Amazon RDS는 자동으로 장애 조치를 취하여 관리자의 개입 없이 데이터베이스 작업을 신속하게 재개할 수 있도록 합니다. 다음 표에 설명된 조건 중 하나가 발생하면 기본 DB 인스턴스는 자동으로 예비 복제본으로 전환됩니다. 이 장애 조치 이유는 이벤트 로그에서 확인할 수 있습니다.

장애 조치 이유 설명
RDS 데이터베이스 인스턴스 기반의 운영 체제가 오프라인 작업에서 패치되고 있습니다.

OS 패치 또는 보안 업데이트를 위한 유지 관리 기간 동안 장애 조치가 트리거되었습니다.

자세한 내용은 DB 인스턴스 유지 관리 섹션을 참조하세요.
RDS 다중 AZ 인스턴스의 기본 호스트가 비정상입니다. 다중 AZ DB 인스턴스 배포에서 손상된 프라이머리 DB 인스턴스를 감지하여 장애 조치를 수행했습니다.
네트워크 연결 손실로 인해 RDS 다중 AZ 인스턴스의 기본 호스트에 연결할 수 없습니다.

RDS 모니터링이 기본 DB 인스턴스에 대한 네트워크 연결 실패를 감지하여 장애 조치를 트리거했습니다.
RDS 인스턴스를 고객이 수정했습니다.

RDS DB 인스턴스 수정 때문에 장애 조치가 트리거되었습니다.

자세한 내용은 Amazon RDS DB 인스턴스 수정 섹션을 참조하세요.
RDS 다중 AZ 기본 인스턴스가 사용 중이며 응답하지 않습니다.

기본 DB 인스턴스가 응답하지 않습니다. 다음을 수행하는 것이 좋습니다.

이러한 권장 사항에 대한 자세한 내용은 Amazon RDS의 모니터링 도구 및 Amazon RDS의 모범 사례 단원을 참조하세요.
RDS 다중 AZ 인스턴스의 기본 호스트 기반의 스토리지 볼륨에 오류가 발생했습니다. 다중 AZ DB 인스턴스 배포가 프라이머리 DB 인스턴스에서 스토리지 문제를 감지하여 장애 조치를 수행했습니다.
사용자가 DB 인스턴스의 장애 조치를 요청했습니다.

사용자가 DB 인스턴스를 재부팅하고 장애 조치를 사용하여 재부팅을 선택했습니다.

자세한 내용은 DB 인스턴스 재부팅을 참조하세요.

다음 단계에 따라 다중 AZ DB 인스턴스가 장애 조치를 수행했는지 확인할 수 있습니다.

  • 장애 조치가 시작되었음을 이메일 또는 SMS로 사용자에게 알리도록 DB 이벤트 구독을 설정합니다. 이벤트에 대한 자세한 내용은 Amazon RDS 이벤트 알림 작업 단원을 참조하세요.

  • RDS 콘솔 또는 API 작업을 사용하여 DB 이벤트를 확인합니다.

  • RDS 콘솔 또는 API 작업을 사용하여 다중 AZ DB 인스턴스 배포의 현재 상태를 확인합니다.

장애 조치, 복구 시간 절감 및 기타 Amazon RDS 모범 사례에 대한 자세한 내용은 Amazon RDS의 모범 사례 단원을 참조하세요.

DNS 이름 조회를 위한 JVM TTL 설정

장애 조치 메커니즘은 DB 인스턴스의 Domain Name System(DNS) 레코드가 예비 DB 인스턴스를 가리키도록 자동으로 변경합니다. 그 결과 DB 인스턴스의 기존 연결을 모두 재설정해야 합니다. Java 가상 머신(JVM) 환경에서 Java DNS 캐싱 메커니즘이 작동하는 방식 때문에 JVM 설정을 다시 구성해야 할 수 있습니다.

JVM은 DNS 이름 조회를 캐시합니다. JVM은 호스트 이름을 IP 주소로 확인하는 경우 유지 시간(TTL)이라고 하는 지정된 기간 동안 IP 주소를 캐싱합니다.

AWS 리소스는 간헐적으로 변경되는 DNS 이름 항목을 사용하므로 TTL 값을 60초 이하로 하여 JVM을 구성하는 것이 좋습니다. 이렇게 하면 리소스의 IP 주소가 변경될 때 애플리케이션이 DNS를 다시 쿼리하여 리소스의 새 IP 주소를 수신하고 사용할 수 있습니다.

일부 Java 구성에서는 JVM이 재시작될 때까지 DNS 항목을 새로 고치지 않도록 JVM 기본 TTL이 설정됩니다. 따라서 애플리케이션이 여전히 실행되는 동안 AWS 리소스의 IP 주소가 변경되는 경우 JVM을 수동으로 재시작하여 캐시된 IP 정보가 새로 고쳐질 때까지는 해당 리소스를 사용할 수 없습니다. 이 경우 캐시된 IP 정보를 정기적으로 새로 고치도록 JVM의 TTL을 설정하는 것이 중요합니다.

networkaddress.cache.ttl 속성 값을 검색하여 JVM 기본 TTL을 가져올 수 있습니다.

String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
참고

기본 TTL은 JVM 버전과 보안 관리자 설치 여부에 따라 다를 수 있습니다. 대부분의 JVM은 60초 미만의 기본 TTL을 제공합니다. 이러한 JVM을 사용 중이며 보안 관리자는 사용하지 않는 경우 이 주제의 나머지 내용을 무시해도 좋습니다. Oracle의 보안 관리자에 대한 자세한 내용은 Oracle 설명서의 The Security Manager를 참조하십시오.

JVM의 TTL을 수정하려면 networkaddress.cache.ttl 속성 값을 설정합니다. 필요에 따라 다음 방법 중 하나를 사용합니다.

  • JVM을 사용하는 모든 애플리케이션에 대해 전역적으로 속성 값을 설정하려면 networkaddress.cache.ttl 파일에서 $JAVA_HOME/jre/lib/security/java.security을 설정합니다.

    networkaddress.cache.ttl=60

  • 애플리케이션에만 로컬로 속성을 설정하려면 네트워크 연결이 설정되기 전에 애플리케이션의 초기화 코드에서 networkaddress.cache.ttl을 설정합니다.

    java.security.Security.setProperty("networkaddress.cache.ttl" , "60");