다중 AZ DB 클러스터 배포

다중 AZ DB 클러스터 배포는 읽을 수 있는 복제 DB 인스턴스가 2개 있는 Amazon RDS의 반동기식 고가용성 배포 모드입니다. 다중 AZ DB 클러스터에는 동일한 AWS 리전에 있는 세 개의 개별 가용 영역에 라이터 DB 인스턴스와 두 개의 리더 DB 인스턴스가 있습니다. 다중 AZ DB 클러스터는 다중 AZ DB 인스턴스 배포에 비해 고가용성, 높은 읽기 워크로드 용량, 낮은 쓰기 대기 시간을 지원합니다.

가동 중지 시간을 단축하여 Amazon RDS MariaDB 또는 MySQL 데이터베이스로 데이터 가져오기의 지침에 따라 온프레미스 데이터베이스의 데이터를 다중 AZ DB 클러스터로 가져올 수 있습니다.

다중 AZ DB 클러스터에 대한 예약 DB 인스턴스를 구매할 수 있습니다. 자세한 내용은 다중 AZ DB 클러스터에 대한 예약 DB 인스턴스 단원을 참조하십시오.

기능 가용성 및 해당 지원은 각 데이터베이스 엔진의 특정 버전 및 AWS 리전 리전에 따라 다릅니다. 다중 AZ DB 클러스터가 포함된 Amazon RDS의 버전 및 리전 가용성에 대한 자세한 내용은 Amazon RDS에서 다중 AZ DB 클러스터를 지원하는 리전 및 DB 엔진 단원을 참조하세요.

주제

• 다중 AZ DB 클러스터에서 사용 가능한 인스턴스 클래스
• 다중 AZ DB 클러스터의 개요
• AWS Management Console을 사용하여 다중 AZ DB 클러스터 관리
• 다중 AZ DB 클러스터용 파라미터 그룹 작업
• 다중 AZ DB 클러스터의 엔진 버전 업그레이드
• RDS 프록시를 다중 AZ DB 클러스터와 함께 사용
• 복제본 지연 시간 및 다중 AZ DB 클러스터
• 다중 AZ DB 클러스터의 장애 조치 프로세스
• 다중 AZ DB 클러스터 생성
• 다중 AZ DB 클러스터에 연결
• AWS 컴퓨팅 리소스와 다중 AZ DB 클러스터 자동 연결
• 다중 AZ DB 클러스터 수정
• 다중 AZ DB 클러스터 이름 바꾸기
• 다중 AZ DB 클러스터 및 리더 DB 인스턴스 재부팅
• 다중 AZ DB 클러스터 읽기 전용 복제본 사용
• 다중 AZ DB 클러스터에서 PostgreSQL 논리적 복제 사용
• 다중 AZ DB 클러스터 삭제
• 다중 AZ DB 클러스터의 제한 사항

중요

다중 AZ DB 클러스터는 Aurora DB 클러스터와 동일하지 않습니다. Aurora DB 클러스터에 대한 자세한 내용은 Amazon Aurora 사용 설명서를 참조하세요.

다중 AZ DB 클러스터에서 사용 가능한 인스턴스 클래스

다중 AZ DB 클러스터 배포는 db.m5d, db.m6gd, db.m6id, db.m6idn, db.r5d, db.r6gd, db.x2iedn, db.r6id, db.r6idn 및 db.c6gd DB 인스턴스 클래스에 지원됩니다.

참고

c6gd 인스턴스 클래스는 medium 인스턴스 크기를 지원하는 유일한 인스턴스 클래스입니다.

DB 인스턴스 클래스에 대한 자세한 내용은 DB 인스턴스 클래스 섹션을 참조하세요.

다중 AZ DB 클러스터의 개요

다중 AZ DB 클러스터에서는 Amazon RDS가 DB 엔진의 네이티브 복제 기능을 사용하여 라이터 DB 인스턴스의 데이터를 두 리더 DB 인스턴스로 복제합니다. 라이터 DB 인스턴스가 변경되면 각 리더 DB 인스턴스로 전송됩니다.

다중 AZ DB 클러스터 배포에서는 변경 사항을 커밋하려면 하나 이상의 리더 DB 인스턴스의 승인을 받아야 하는 반동기식 복제를 사용합니다. 모든 복제본에서 이벤트가 완전히 실행되고 커밋되었음을 승인하는 작업은 필요하지 않습니다.

리더 DB 인스턴스는 자동 장애 조치 대상 역할을 하며 읽기 트래픽을 제공하여 애플리케이션 읽기 처리량을 높입니다. 라이터 DB 인스턴스에서 중단이 발생하는 경우 RDS는 어느 리더 DB 인스턴스가 장애 조치 대상이 되는지를 관리합니다. RDS는 어느 리더 DB 인스턴스의 가장 최근 변경 기록을 기준으로 이를 수행합니다.

다음 다이어그램은 다중 AZ DB 클러스터를 보여줍니다.

일반적으로 다중 AZ DB 클러스터는 다중 AZ DB 인스턴스 배포에 비해 쓰기 대기 시간이 짧습니다. 또한 읽기 전용 워크로드가 리더 DB 인스턴스에서 실행되도록 허용합니다. RDS 콘솔에는 라이터 DB 인스턴스의 가용 영역과 리더 DB 인스턴스의 가용 영역이 표시됩니다. describe-db-clusters CLI 명령이나 DescribeDBClusters API 작업을 사용하여 이 정보를 찾아볼 수도 있습니다.

중요

RDS for MySQL 다중 AZ DB 클러스터의 복제 오류를 방지하려면 모든 테이블에 프라이머리 키가 있는 것이 좋습니다.

AWS Management Console을 사용하여 다중 AZ DB 클러스터 관리

콘솔을 사용하여 다중 AZ DB 클러스터를 관리할 수 있습니다.

콘솔을 사용하여 다중 AZ DB 클러스터를 관리하는 방법

1. https://console.aws.amazon.com/rds/에서 AWS Management Console에 로그인한 후 Amazon RDS 콘솔을 엽니다.

2. 탐색 창에서 데이터베이스(Databases)를 선택한 다음 관리하려는 다중 AZ DB 클러스터를 선택합니다.

다음 이미지는 콘솔의 다중 AZ DB 클러스터를 보여줍니다.

작업(Actions) 메뉴에서 사용할 수 있는 작업은 다중 AZ DB 클러스터를 선택했는지 아니면 클러스터의 DB 인스턴스를 선택했는지에 따라 달라집니다.

다중 AZ DB 클러스터를 선택하여 클러스터 세부 정보를 보고 클러스터 수준에서 작업을 수행합니다.

다중 AZ DB 클러스터에서 DB 인스턴스를 선택하여 DB 인스턴스 세부 정보를 보고 DB 인스턴스 수준에서 작업을 수행합니다.

다중 AZ DB 클러스터용 파라미터 그룹 작업

다중 AZ DB 클러스터에서 DB 클러스터 파라미터 그룹은 다중 AZ DB 클러스터의 모든 DB 인스턴스에 적용되는 엔진 구성 값에 대한 컨테이너 역할을 합니다.

다중 AZ DB 클러스터에서 DB 파라미터 그룹은 DB 엔진 및 DB 엔진 버전에 대한 기본 DB 파라미터 그룹으로 설정됩니다. DB 클러스터 파라미터 그룹의 설정은 클러스터의 모든 DB 인스턴스에 사용됩니다.

파라미터 그룹에 대한 자세한 내용은 다중 AZ DB 클러스터용 DB 클러스터 파라미터 그룹 작업 단원을 참조하세요.

다중 AZ DB 클러스터의 엔진 버전 업그레이드

Amazon RDS는 지원되는 각 데이터베이스 엔진의 최신 버전을 제공하여 다중 AZ DB 클러스터를 최신 상태로 유지합니다. Amazon RDS가 새로운 버전의 데이터베이스 엔진을 지원하는 경우, 다중 AZ DB 클러스터를 업그레이드할 방법과 시기를 선택할 수 있습니다.

수행할 수 있는 업그레이드에는 2가지 종류가 있습니다.

메이저 버전 업그레이드

메이저 엔진 버전 업그레이드에는 기존 애플리케이션과 호환되지 않는 변경 사항이 도입될 수 있습니다. 메이저 버전 업그레이드를 시작하면 Amazon RDS가 리더 및 라이터 인스턴스를 동시에 업그레이드합니다. 따라서 업그레이드가 완료될 때까지 DB 클러스터를 사용할 수 없습니다.

마이너 버전 업그레이드

마이너 버전 업그레이드에는 기존 애플리케이션과 호환되는 변경 사항만 포함됩니다. 마이너 버전 업그레이드를 시작하면 Amazon RDS는 먼저 리더 DB 인스턴스를 한 번에 하나씩 업그레이드합니다. 그러면 리더 DB 인스턴스 중 하나가 새 라이터 DB 인스턴스로 전환됩니다. 그러면 Amazon RDS가 이전 라이터 인스턴스(현재는 리더 인스턴스)를 업그레이드합니다.

업그레이드 중의 가동 중지 시간이 리더 DB 인스턴스가 새 라이터 DB 인스턴스가 되는 데 걸리는 시간으로 제한됩니다. 이 가동 중지는 자동 장애 조치와 같은 역할을 합니다. 자세한 내용은 다중 AZ DB 클러스터의 장애 조치 프로세스 단원을 참조하십시오. 다중 AZ DB 클러스터의 복제 지연이 가동 중지 시간에 영향을 줄 수 있습니다. 자세한 내용은 복제본 지연 시간 및 다중 AZ DB 클러스터 단원을 참조하십시오.

RDS for PostgreSQL 다중 AZ DB 클러스터 읽기 전용 복제본의 경우 Amazon RDS는 클러스터 멤버 인스턴스를 한 번에 하나씩 업그레이드합니다. 리더 및 라이터 클러스터 역할은 업그레이드 중에 전환되지 않습니다. 따라서 Amazon RDS가 클러스터 라이터 인스턴스를 업그레이드하는 동안 DB 클러스터에 가동 중지가 발생할 수 있습니다.

참고

다중 AZ DB 클러스터 마이너 버전 업그레이드의 가동 중지 시간은 일반적으로 35초입니다. RDS 프록시와 함께 사용하면 가동 중지 시간을 1초 이하로 더 줄일 수 있습니다. 자세한 내용은 Amazon RDS 프록시 사용 단원을 참조하십시오. ProxySQL, PgBouncer 또는 MySQL용 AWS JDBC 드라이버와 같은 오픈 소스 데이터베이스 프록시를 사용할 수 있습니다.

현재 Amazon RDS는 RDS for PostgreSQL 다중 AZ DB 클러스터에 대해서만 메이저 버전 업그레이드를 지원합니다. Amazon RDS는 다중 AZ DB 클러스터를 지원하는 모든 DB 엔진의 마이너 버전 업그레이드를 지원합니다.

Amazon RDS는 다중 AZ DB 클러스터 읽기 전용 복제본을 자동으로 업그레이드하지 않습니다. 마이너 버전 업그레이드 시 먼저 모든 읽기 전용 복제본을 수동으로 업그레이드한 다음 클러스터를 업그레이드해야 합니다. 그렇지 않으면 업그레이드가 차단됩니다. 클러스터의 메이저 버전 업그레이드를 수행할 때 모든 읽기 전용 복제본의 복제 상태가 종료로 변경됩니다. 업그레이드가 완료된 다음, 읽기 전용 복제본을 삭제하고 재생성해야 합니다. 자세한 내용은 읽기 전용 복제본 모니터링 단원을 참조하십시오.

다중 AZ DB 클러스터의 엔진 버전을 업그레이드하는 프로세스는 DB 인스턴스 엔진 버전을 업그레이드하는 프로세스와 동일합니다. 지침은 DB 인스턴스 엔진 버전 업그레이드 단원을 참조하십시오. 유일한 차이점은 AWS Command Line Interface(AWS CLI)를 사용할 때 modify-db-cluster 명령을 사용하고 --allow-major-version-upgrade 파라미터와 함께 --db-cluster-identifier 파라미터를 지정한다는 것입니다.

메이저 및 마이너 버전 업그레이드에 대한 자세한 내용은 다음 DB 엔진 설명서를 참조하세요.

• Amazon RDS용 PostgreSQL DB 엔진 업그레이드

• MySQL DB 엔진 업그레이드

RDS 프록시를 다중 AZ DB 클러스터와 함께 사용

Amazon RDS 프록시를 사용하여 다중 AZ DB 클러스터의 프록시를 만들 수 있습니다. RDS 프록시를 사용하면 애플리케이션이 데이터베이스 연결을 풀링하고 공유할 수 있어 확장 기능을 향상할 수 있습니다. 각 프록시는 연결 재사용이라고도 하는 연결 멀티플렉싱을 수행합니다. 멀티플렉싱을 사용하면 RDS 프록시가 하나의 기본 데이터베이스 연결을 사용하여 한 트랜잭션에 대한 모든 작업을 수행합니다. 또한, RDS 프록시는 다중 AZ DB 클러스터의 마이너 버전 업그레이드로 인한 가동 중지 시간을 1초 이하로 줄일 수 있습니다. RDS 프록시의 이점에 대한 자세한 내용은 Amazon RDS 프록시 사용 섹션을 참조하세요.

다중 AZ DB 클러스터에 프록시를 설정하려면 클러스터를 생성할 때 RDS 프록시 생성을 선택합니다. RDS 프록시 엔드포인트를 생성하고 관리하는 방법에 대한 지침은 Amazon RDS 프록시 엔드포인트 작업 섹션을 참조하세요.

복제본 지연 시간 및 다중 AZ DB 클러스터

복제본 지연 시간은 리더 DB 인스턴스에서 가장 최근에 적용된 트랜잭션과 라이터 DB 인스턴스에서 가장 최근 트랜잭션 사이의 시간 차이입니다. Amazon CloudWatch 지표 ReplicaLag는 이 시차를 나타냅니다. CloudWatch 지표에 대한 자세한 내용은 Amazon CloudWatch로 Amazon RDS 지표 모니터링 섹션을 참조하세요.

다중 AZ DB 클러스터는 높은 쓰기 성능을 허용하지만 엔진 기반 복제의 특성으로 인해 복제본 지연이 계속 발생할 수 있습니다. 모든 장애 조치는 새 라이터 DB 인스턴스를 승격하기 전에 먼저 복제본 지연을 해결해야 하므로 이 복제본 지연을 모니터링하고 관리하는 것이 고려 사항입니다.

RDS for MySQL 다중 AZ DB 클러스터용 장애 조치 시간은 나머지 리더 DB 인스턴스의 복제본 지연에 따라 달라집니다. 두 리더 DB 인스턴스는 모두 적용되지 않은 트랜잭션을 적용해야 그 중 하나가 새 라이터 DB 인스턴스로 승격됩니다.

RDS for PostgreSQL 다중 AZ DB 클러스터용 장애 조치 시간은 가장 낮은 나머지 리더 DB 인스턴스의 복제본 지연에 따라 달라집니다. 가장 낮은 복제본 지연을 가진 리더 DB 인스턴스는 모두 적용되지 않은 트랜잭션을 적용해야 새 라이터 DB 인스턴스로 승격됩니다.

복제본 지연이 설정된 시간을 초과할 때 CloudWatch 경보를 생성하는 방법을 보여주는 자습서는 자습서: 다중 AZ DB 클러스터 복제본 지연에 대한 Amazon CloudWatch 경보 생성 섹션을 참조하세요.

복제본 지연의 일반적인 원인

일반적으로 복제본 지연은 쓰기 워크로드가 너무 높아 리더 DB 인스턴스가 트랜잭션을 효율적으로 적용할 수 없을 때 발생합니다. 다양한 워크로드로 인해 일시적 또는 지속적인 복제본 지연이 발생할 수 있습니다. 다음은 몇 가지 일반적인 원인의 예입니다.

• 라이터 DB 인스턴스의 높은 쓰기 동시성 또는 대량 일괄 업데이트로 인해 리더 DB 인스턴스의 적용 프로세스가 뒤쳐집니다.

• 하나 이상의 리더 DB 인스턴스의 리소스를 사용하는 대량 읽기 워크로드입니다. 느리거나 큰 쿼리를 실행하면 적용 프로세스에 영향이 있고 복제본 지연이 발생할 수 있습니다.

• 데이터베이스가 커밋 순서를 유지해야 하기 때문에 대량의 데이터 또는 DDL 문을 수정하는 트랜잭션으로 인해 복제본 지연 시간이 일시적으로 증가하는 경우가 있습니다.

복제본 지연 완화

RDS for MySQL 및 RDS for PostgreSQL용 다중 AZ DB 클러스터의 경우 라이터 DB 인스턴스의 로드를 줄여 복제본 지연을 완화할 수 있습니다. 흐름 제어를 사용하여 복제본 지연을 줄일 수도 있습니다. 흐름 제어는 라이터 DB 인스턴스에서 쓰기를 제한하여 작동하므로 복제본 지연 시간이 계속해서 무제한으로 증가하지 않도록 합니다. 쓰기 제한은 트랜잭션 끝에 지연을 추가하여 수행되며, 이로 인해 라이터 DB 인스턴스의 쓰기 처리량이 감소합니다. 흐름 제어가 지연 제거를 보장하지는 않지만 많은 워크로드에서 전반적인 지연을 줄이는 데 도움이 될 수 있습니다. 다음 섹션에서는 RDS for MySQL 및 RDS PostgreSQL로 흐름 제어를 사용하는 방법을 제공합니다.

RDS for MySQL에 대한 흐름 제어를 통해 복제본 지연 완화

RDS for MySQL 다중 AZ DB 클러스터를 사용하는 경우 동적 파라미터 rpl_semi_sync_master_target_apply_lag을 사용하면 흐름 제어가 기본적으로 활성화됩니다. 이 파라미터는 복제본 지연에 대해 원하는 상한을 지정합니다. 복제본 지연이 구성된 제한에 가까워지면 흐름 제어는 라이터 DB 인스턴스의 쓰기 트랜잭션을 제한하여 지정된 값보다 낮은 복제본 지연을 포함하려고 시도합니다. 경우에 따라 복제본 지연이 지정된 제한을 초과할 수 있습니다. 기본적으로 이 파라미터는 120초로 설정됩니다. 흐름 제어를 비활성화하려면 이 파라미터를 최대 값 86,400초(하루)로 설정합니다.

흐름 제어에 의해 주입된 현재 지연을 보려면 다음 쿼리를 실행하여 Rpl_semi_sync_master_flow_control_current_delay 파라미터를 표시하세요.

SHOW GLOBAL STATUS like '%flow_control%';

출력은 다음과 비슷한 형태가 됩니다.

+-------------------------------------------------+-------+
| Variable_name                                   | Value |
+-------------------------------------------------+-------+
| Rpl_semi_sync_master_flow_control_current_delay | 2010  |
+-------------------------------------------------+-------+
1 row in set (0.00 sec)

참고

지연은 마이크로초 단위로 표시됩니다.

RDS for MySQL Multi-AZ DB 클러스터에서 성능 개선 도우미를 활성화하면 흐름 제어에 의해 쿼리가 지연되었음을 나타내는 해당 SQL 문 대기 이벤트를 모니터링할 수 있습니다. 흐름 제어에 의해 지연이 발생했을 때 성능 개선 도우미 대시보드의 해당 SQL 문에서 /wait/synch/cond/semisync/semi_sync_flow_control_delay_cond 대기 이벤트를 볼 수 있습니다. 이러한 지표를 보려면 성능 스키마가 켜져 있는지 확인합니다. 성능 개선 도우미에 대한 자세한 내용은 성능 개선 도우미를 통한 Amazon RDS 모니터링 섹션을 참조하세요.

RDS for PostgreSQL에 대한 흐름 제어를 통해 복제본 지연 완화

RDS for PostgreSQL용 다중 AZ DB 클러스터를 사용하면 흐름 제어가 확장으로 배포됩니다. 이는 DB 클러스터의 모든 DB 인스턴스에 대해 백그라운드 작업자를 켭니다. 기본적으로 리더 DB 인스턴스의 백그라운드 작업자는 현재 복제본 지연을 라이터 DB 인스턴스의 백그라운드 작업자에게 알립니다. 리더 DB 인스턴스에서 지연이 2분을 초과하면 라이터 DB 인스턴스의 백그라운드 작업자가 트랜잭션 종료 시 지연을 추가합니다. 지연 임계값을 제어하려면 flow_control.target_standby_apply_lag 파라미터를 사용합니다.

흐름 제어가 PostgreSQL 프로세스를 제한하면 pg_stat_activity 및 성능 개선 도우미의 Extension 대기 이벤트가 이를 나타냅니다. 함수 get_flow_control_stats는 현재 추가되고 있는 지연 시간에 대한 세부 정보를 표시합니다.

흐름 제어는 짧지만 동시 트랜잭션이 많은 대부분의 온라인 트랜잭션 처리(OLTP) 워크로드에 이상적입니다. 배치 작업과 같은 장기 실행 트랜잭션으로 인해 지연이 발생하는 경우 흐름 제어는 큰 이점을 제공하지 않습니다.

shared_preload_libraries에서 확장을 제거하고 DB 인스턴스를 재부팅하여 흐름 제어를 해제할 수 있습니다.

다중 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 클러스터를 수동으로 장애 조치하는 방법

1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

2. 탐색 창에서 Databases(데이터베이스)를 선택합니다.

3. 장애 조치하려는 다중 AZ DB 클러스터를 선택합니다.

4. 작업(Actions)으로 장애 조치(Failover)를 선택합니다.

   DB 클러스터 장애 조치 페이지가 표시됩니다.

5. 장애 조치(Failover)를 선택하여 수동 장애 조치를 확인합니다.

AWS CLI

다중 AZ DB 클러스터를 수동으로 장애 조치하려면 AWS CLI 명령 failover-db-cluster를 사용하세요.

aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster

RDS API

다중 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");