Amazon RDS용 다중 AZ DB 클러스터 장애 조치
다중 AZ DB 클러스터의 라이터 DB 인스턴스에 계획되거나 계획되지 않은 중단이 발생하면 Amazon RDS는 자동으로 다른 가용 영역에 있는 리더 DB 인스턴스로 장애 조치합니다. 이를 통해 중단 시간을 최소화하면서 고가용성을 보장할 수 있습니다. 장애 조치는 하드웨어 장애, 네트워크 문제 또는 수동 요청 중에 발생할 수 있습니다. 이 주제에서는 실패 자동 감지, 장애 조치 중 이벤트 시퀀스, 읽기 및 쓰기 작업에 미치는 영향을 간략하게 설명합니다. 또한 장애 조치 시간을 모니터링하고 최소화하기 위한 모범 사례를 제공합니다.
장애 조치가 완료되는 데 걸리는 시간은 라이터 DB 인스턴스를 사용할 수 없게 된 데이터베이스 활동 및 기타 조건에 따라 달라집니다. 장애 조치에 소요되는 시간은 일반적으로 35초 아래입니다. 장애 조치는 두 리더 DB 인스턴스에 모두 장애가 발생한 라이터의 처리되지 않은 트랜잭션이 적용되면 완료됩니다. 장애 조치가 완료되면 RDS 콘솔에 새 가용 영역이 반영되는 데 시간이 더 걸릴 수 있습니다.
자동 장애 조치
Amazon RDS는 자동으로 장애 조치를 취하여 관리자의 개입 없이 데이터베이스 작업을 신속하게 재개할 수 있도록 합니다. 장애 조치를 수행하려면 라이터 DB 인스턴스가 자동으로 리더 DB 인스턴스로 전환합니다.
다중 AZ DB 클러스터 수동 장애 조치
다중 AZ DB 클러스터를 수동으로 장애 조치하는 경우 RDS는 먼저 기본 DB 인스턴스를 종료합니다. 그러면 내부 모니터링 시스템이 기본 DB 인스턴스가 비정상임을 감지하고 읽기 가능한 복제 DB 인스턴스로 승격합니다. 장애 조치에 소요되는 시간은 일반적으로 35초 아래입니다.
AWS Management Console, AWS CLI 또는 RDS API를 사용하여 다중 AZ DB 클러스터를 수동으로 장애 조치할 수 있습니다.
다중 AZ DB 클러스터를 수동으로 장애 조치하는 방법
AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/
에서 Amazon RDS 콘솔을 엽니다. -
탐색 창에서 Databases(데이터베이스)를 선택합니다.
-
장애 조치하려는 다중 AZ DB 클러스터를 선택합니다.
-
작업(Actions)으로 장애 조치(Failover)를 선택합니다.
DB 클러스터 장애 조치 페이지가 표시됩니다.
-
장애 조치(Failover)를 선택하여 수동 장애 조치를 확인합니다.
다중 AZ DB 클러스터를 수동으로 장애 조치하려면 AWS CLI 명령 failover-db-cluster를 사용하세요.
aws rds failover-db-cluster --db-cluster-identifier
mymultiazdbcluster
다중 AZ DB 클러스터를 수동으로 장애 조치하려면 Amazon RDS API FailoverDBCluster를 호출하고 DBClusterIdentifier
를 지정하면 됩니다.
다중 AZ DB 클러스터가 장애 조치되었는지 여부 확인
다음 단계에 따라 다중 AZ DB 클러스터가 장애 조치를 수행했는지 확인할 수 있습니다.
장애 조치가 시작되었음을 이메일 또는 SMS로 사용자에게 알리도록 DB 이벤트 구독을 설정합니다. 이벤트에 대한 자세한 내용은 Amazon RDS 이벤트 알림 작업 단원을 참조하세요.
Amazon RDS 콘솔 또는 API 작업을 사용하여 DB 이벤트를 확인합니다.
Amazon RDS 콘솔, AWS CLI 및 RDS API를 사용하여 다중 AZ DB 클러스터의 현재 상태를 확인합니다.
장애 조치, 복구 시간 절감 및 기타 Amazon RDS 모범 사례에 대한 자세한 내용은 Amazon RDS의 모범 사례 단원을 참조하세요.
DNS 이름 조회를 위한 JVM TTL 설정
장애 조치 메커니즘은 리더 DB 인스턴스로 연결되도록 DB 인스턴스의 도메인 이름 시스템(DNS) 레코드를 자동으로 변경합니다. 그 결과 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을 설정하는 것이 중요합니다.
참고
기본 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");