메뉴
Amazon Relational Database Service
사용 설명서 (API Version 2014-10-31)

Amazon Aurora DB 클러스터 관리

다음 단원에서는 Amazon Aurora DB 클러스터의 성능, 조정, 내결함성, 백업 및 복원 관리에 대해 설명합니다.

Aurora DB 클러스터의 성능 및 조정 관리

스토리지 조정

Aurora 스토리지는 클러스터 볼륨에 저장된 데이터에 따라 자동 조정됩니다. 데이터가 증가하면 클러스터 볼륨 스토리지도 최대 64TB까지 10GB씩 확장됩니다. 클러스터 볼륨 크기는 1시간 단위로 확인하여 스토리지 비용을 측정할 수 있습니다. 요금에 대한 자세한 내용은 Amazon RDS 제품 페이지을(를) 참조하십시오.

Aurora DB 인스턴스 조정

Aurora DB 인스턴스는 인스턴스 조정과 읽기 조정, 이렇게 두 가지 방식으로 조정할 수 있습니다.

인스턴스 조정

필요에 따라 클러스터의 DB 인스턴스마다 DB 인스턴스 클래스 설정을 변경하여 DB 클러스터를 조정할 수 있습니다. Aurora는 Aurora에 최적화된 DB 인스턴스 클래스를 몇 가지 지원합니다. 다음 표는 인스턴스 클래스 사양을 나타냅니다.

인스턴스 클래스 vCPU ECU 메모리(GB)

db.t2.small

1

1 2

db.t2.medium

2

2 4

db.r3.large

2

6.5 15.25

db.r3.xlarge

4

13 30.5

db.r3.2xlarge

8

26 61

db.r3.4xlarge

16

52 122

db.r3.8xlarge

32

104 244

읽기 조정

Aurora DB 클러스터는 Aurora 복제본을 최대 15개까지 생성하여 읽기 조정을 수행할 수 있습니다. 각 Aurora 복제본은 복제본 지연 시간을 최소화하여 클러스터 볼륨에서 동일한 데이터를 반환합니다. 일반적으로 이 지연 시간은 기본 인스턴스가 업데이트를 적용한 후 100밀리초 미만입니다. 읽기 트래픽이 증가하면 Aurora 복제본을 추가 생성하여 직접 연결함으로써 DB 클러스터의 읽기 부하를 분산시키는 것도 가능합니다. Aurora 복제본의 DB 인스턴스 클래스가 기본 인스턴스의 DB 인스턴스 클래스와 같을 필요는 없습니다.

Aurora DB 인스턴스에 대한 최대 연결

Aurora DB 인스턴스에 대해 허용되는 최대 연결 수는 DB 인스턴스의 인스턴스 수준 파라미터 그룹의 max_connections 파라미터로 결정됩니다. 기본적으로 이 값은 다음 수식에 설정됩니다(log 함수는 로그 기수 2를 나타냄).

GREATEST({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemory/8187281408)*1000}).

max_connections 파라미터를 이 수식으로 설정하면 허용되는 연결 수가 인스턴스 크기에 따라 조정됩니다. 예를 들어 DB 인스턴스 클래스가 db.r3.xlarge이고 메모리가 30.5GB일 경우, 허용되는 최대 연결 수는 다음 수식에서와 같이 2000입니다.

Copy
log( (30.5 * 1073741824) / 8187281408 ) * 1000 = 2000

다음 표에는 Aurora에서 사용 가능한 각 DB 인스턴스 클래스에 대한 max_connections의 결과 기본값이 나와 있습니다. 인스턴스를 메모리가 더 많은 DB 인스턴스로 조정하거나, max_connections 파라미터의 값을 최대 16,000까지 설정하여 Aurora DB 인스턴스의 최대 연결 수를 늘릴 수 있습니다.

인스턴스 클래스 max_connections 기본값

db.t2.small

45

db.t2.medium

90

db.r3.large

1000

db.r3.xlarge

2000

db.r3.2xlarge

3000

db.r3.4xlarge

4000

db.r3.8xlarge

5000

Aurora DB 클러스터의 내결함성

Aurora DB 클러스터는 내결함성을 고려하여 설계되었습니다. 클러스터 볼륨은 단일 리전에 속하는 다중 가용 영역을 모두 아우르며, 각 가용 영역에는 클러스터 볼륨 데이터의 사본이 복사됩니다. 이 기능은 가용 영역 한 곳에서 결함이 발생하더라도 DB 클러스터가 잠시 서비스가 중단될 뿐 전혀 데이터 손실 없이 결함을 견딜 수 있음을 의미합니다.

DB 클러스터의 기본 인스턴스에 결함이 발생하면, Aurora가 자동으로 다음 두 가지 방법 중 하나를 사용하여 새로운 기본 인스턴스로 장애 조치합니다.

  • 기존 Aurora 복제본을 새 기본 인스턴스로 승격시킴

  • 새로운 기본 인스턴스 만들기

DB 클러스터에 Aurora 복제본이 하나 이상인 경우에는 장애가 발생하더라도 Aurora 복제본이 기본 인스턴스로 승격됩니다. 이 실패 이벤트로 인해 예외적으로 실패하는 읽기 및 쓰기 작업 동안 짧은 중단이 발생합니다. 하지만, 일반적인 서비스 복구 시간은 120초 미만이지만 대부분 60초 미만에 복원됩니다. DB 클러스터의 가용성을 높이려면 최소 하나 이상의 Aurora 복제본을 둘 이상의 다른 가용 영역에 생성하는 것이 바람직합니다.

각 복제본에 우선 순위를 지정함으로써 장애 이후 기본 인스턴스로 승격할 Aurora 복제본 순서를 사용자 지정할 수 있습니다. 우선 순위 범위는 가장 높은 값인 0부터 가장 낮은 값인 15까지입니다. 기본 인스턴스에 결함이 발생하면 Amazon RDS는 우선 순위가 가장 높은 Aurora 복제본을 새로운 기본 인스턴스로 승격시킵니다. Aurora 복제본의 우선 순위는 언제든지 수정할 수 있습니다. 우선 순위 수정으로 인해 장애 조치가 트리거되지는 않습니다.

둘 이상의 Aurora 복제본이 동일한 우선 순위를 공유하여 승격 계층을 만들 수도 있습니다. 둘 이상의 Aurora 복제본이 동일한 우선 순위를 공유하면 Amazon RDS는 크기가 가장 큰 복제본을 승격시킵니다. 둘 이상의 Aurora 복제본이 동일한 우선 순위와 크기를 공유하면 Amazon RDS는 동일한 승격 티어에서 임의의 복제본을 승격시킵니다.

DB 클러스터에 Aurora 복제본이 포함되어 있지 않으면 기본 인스턴스가 실패 이벤트 중에 다시 생성됩니다. 이 실패 이벤트로 인해 예외적으로 실패하는 읽기 및 쓰기 작업 동안 중단이 발생합니다. 새로운 기본 인스턴스가 생성도면 서비스도 복구되지만 보통 10분 미만의 시간이 걸립니다. Aurora 복제본을 기본 인스턴스로 승격시키는 것이 기본 인스턴스를 새로 생성하는 것보다 훨씬 빠릅니다.

참고

Amazon Aurora는 외부 MySQL 데이터베이스 또는 RDS MySQL DB 인스턴스의 복제도 지원합니다. 자세한 내용은 Aurora와 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터 간의 복제을(를) 참조하십시오.

Aurora DB 클러스터 백업 및 복구

다음 단원에서는 AWS Management Console을 사용한 Aurora 백업과 Aurora DB 클러스터 복구 방법에 대해서 살펴보겠습니다.

백업

Aurora는 클러스터 볼륨을 자동으로 백업한 후 백업 보존 기간 동안 복구 데이터를 보관합니다. Aurora 백업은 지속적으로 누적되기 때문에 백업 보존 기간만 벗어나지 않는다면 어떤 시점으로든 신속히 복구할 수 있습니다. 백업 데이터를 쓰는 중에도 성능에 미치는 영향이나 데이터베이스 서비스 중단은 일어나지 않습니다. 백업 보존 기간은 DB 클러스터를 생성 또는 설정 변경할 때 1일에서 35일까지 지정할 수 있습니다.

백업 보존 기간을 넘겨서 백업을 보존하고 싶을 때는 클러스터 볼륨의 데이터 스냅샷을 캡처하는 것도 한 방법입니다. 스냅샷을 저장하면 Amazon RDS 표준 스토리지 비용이 발생합니다. RDS 스토리지 요금에 대한 자세한 내용은 Amazon Relational Database Service 요금을(를) 참조하십시오.

Aurora는 전체 백업 보존 기간 중 복구 데이터를 누적 보관하기 때문에 백업 보존 기간을 넘어서까지 보관하려는 데이터는 스냅샷을 생성만 하면 됩니다. 새로운 DB 클러스터를 스냅샷에서 생성할 수 있기 때문입니다.

데이터 복구

Aurora에서 유지되는 백업 데이터에서 또는 이전에 저장한 DB 클러스터 스냅샷에서 새 Aurora DB 클러스터를 생성하여 데이터를 복구할 수 있습니다. 백업 데이터에서 생성된 DB 클러스터의 새 사본을 백업 보존 기간 중 임의 시점으로 빨리 복원할 수 있습니다. 백업 보존 기간 중 Aurora 백업의 지속적인 누적 특성은 복구 횟수를 늘리기 위해 데이터 스냅샷을 자주 캡처할 필요가 없다는 것을 의미합니다.

DB 인스턴스의 최근 또는 가장 빠른 복구 시간을 알아보려면 RDS 콘솔에서 Latest Restorable Time 또는 Earliest Restorable Time 값을 확인합니다. DB 클러스터의 최근 복구 시간은 DB 클러스터를 복구할 수 있는 가장 최근 시점을 나타내며 일반적으로 현재 시간에서 5분 이내입니다. 가장 빠른 복구 시간은 백업 보존 기간 내에서 클러스터 볼륨을 복구하려면 얼마나 후행해야 하는지 나타냅니다.

DB 클러스터의 복원이 언제 완료되었는지는 Latest Restorable Time 또는 Earliest Restorable Time을 사용하여 확인할 수 있습니다. Latest Restorable Time 값과 Earliest Restorable Time 값은 복원 작업이 완료되기 전에는 NULL을 반환합니다. Latest Restorable Time 또는 Earliest Restorable Time 값이 NULL을 반환하면 백업 또는 복원 작업을 요청할 수 없습니다.

AWS Management Console을 사용하여 DB 클러스터를 지정 시간으로 복구하는 방법

  1. https://console.aws.amazon.com/rds에서 Amazon Aurora 콘솔을 엽니다.

  2. 좌측 탐색 창에서 [Instances]를 클릭합니다. 복구하려는 DB 클러스터의 기본 인스턴스를 클릭하여 선택합니다.

  3. [Instance Actions]와 [Restore To Point In Time]을 차례대로 클릭합니다.

    [Restore DB Cluster] 창에서 [Use Custom Restore Time] 옵션을 클릭하여 선택합니다.

  4. 복구하려는 날짜와 시간을 [Use Custom Restore Time] 상자에 입력합니다.

  5. 새로 복구된 DB 인스턴스의 이름을 [DB Instance Identifier] 상자에 입력합니다.

  6. [Launch DB Cluster] 버튼을 클릭하고 복구된 DB 클러스터를 실행합니다.

데이터베이스 복제

DB 클러스터 스냅샷을 새 DB 클러스터로 복원하는 대신, 데이터베이스 복제를 이용해 DB 클러스터의 데이터베이스를 복제할 수도 있습니다. 복제본 데이터베이스는 최초 생성 시 최소한의 추가 공간만 사용하며 원본 데이터베이스 또는 복제본 데이터베이스에서 데이터가 변경된 경우에만 데이터가 복사됩니다. 동일한 DB 클러스터에 대해 여러 복제본을 생성할 수 있고, 다른 복제본에서 추가 복제본을 추가할 수도 있습니다. 자세한 내용은 Aurora DB 클러스터에서 데이터베이스 복제 단원을 참조하십시오.

오류 삽입 쿼리를 사용하여 Amazon Aurora 테스트

오류 삽입 쿼리를 사용하여 Amazon Aurora DB 클러스터의 내결함성을 테스트할 수 있습니다. 오류 삽입 쿼리는 Amazon Aurora 인스턴스에 SQL 명령으로 실행되며 오류 삽입 쿼리를 통해 다음 이벤트 중 하나의 발생에 대한 시뮬레이션을 예약하는 데 사용됩니다.

  • 마스터 인스턴스 또는 Aurora 복제본의 충돌

  • Aurora 복제본의 실패

  • 디스크 실패

  • 디스크 정체

충돌을 지정하는 오류 삽입 쿼리가 Amazon Aurora 인스턴스의 충돌을 강제로 일으킵니다. 다른 오류 삽입 쿼리로 인해서도 오류 이벤트 시뮬레이션이 발생하지만 이 경우 이벤트는 발생하지 않습니다. 오류 삽입 쿼리를 제출할 때 실패 이벤트 시뮬레이션이 발생하는 시간 길이를 지정할 수도 있습니다.

Aurora 복제본의 엔드포인트에 연결하여 오류 삽입 쿼리를 Aurora 복제본 인스턴스 중 하나로 제출할 수 있습니다. 자세한 내용은 Aurora 엔드포인트을(를) 참조하십시오.

인스턴스 충돌 테스트

ALTER SYSTEM CRASH 오류 삽입 쿼리를 사용하여 Amazon Aurora 인스턴스의 충돌을 강제로 일으킬 수 있습니다.

이 오류 삽입 쿼리의 경우 장애 조치가 발생하지 않습니다. 장애 조치를 테스트하려면 RDS 콘솔의 DB 클러스터에 대한 Failover 인스턴스 작업을 선택하거나 failover-db-cluster AWS CLI 명령 또는 FailoverDBCluster RDS API 작업을 사용하십시오.

구문

Copy
ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];

옵션

이 오류 삽입 쿼리에는 다음 충돌 유형 중 하나가 사용됩니다.

  • INSTANCE - Amazon Aurora 인스턴스용 MySQL 호환 데이터베이스의 충돌이 시뮬레이션됩니다.

  • DISPATCHER - Aurora DB 클러스터용 마스터 인스턴스에서 디스패처 충돌이 시뮬레이션됩니다. 디스패처가 Amazon Aurora DB 클러스터용 클러스터 볼륨에 업데이트 쓰기 작업을 합니다.

  • NODE-MySQL 호환 데이터베이스 및 Amazon Aurora 인스턴스용 디스패처의 충돌이 모두 시뮬레이션됩니다. 이 오류 삽입 시뮬레이션의 경우 캐시도 삭제됩니다.

기본 충돌 유형은 INSTANCE입니다.

Aurora 복제본 실패 테스트

ALTER SYSTEM SIMULATE READ REPLICA FAILURE 오류 삽입 쿼리를 사용하여 Aurora 복제본의 실패를 시뮬레이션할 수 있습니다.

Aurora 복제본 실패가 발생하면 지정된 시간 간격 동안 DB 클러스터의 특정 Aurora 복제본 또는 모든 Aurora 복제본에 대한 요청이 모두 차단됩니다. 시간 간격이 경과되면 해당 Aurora 복제본이 마스터 인스턴스와 자동으로 동기화됩니다.

구문

Copy
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE [ TO ALL | TO "replica name" ] FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };

옵션

이 오류 삽입 쿼리에는 다음 파라미터가 사용됩니다.

  • percentage_of_failure - 실패 이벤트 도중 차단되는 요청 비율(%). 이 값은 0 ~ 100의 실수(Double)입니다. 0을 지정하면 요청이 차단되지 않습니다. 100을 지정하면 모든 요청이 차단됩니다.

  • Failure type - 시뮬레이션할 실패의 유형. DB 클러스터의 모든 Aurora 복제본에 대한 실패를 시뮬레이션하려면 TO ALL 을 지정합니다. 단일 Aurora 복제본의 실패를 시뮬레이션하려면 TO와 Aurora 복제본의 이름을 지정합니다. 기본 실패 유형은 TO ALL입니다.

  • quantity- Aurora 복제본 실패 시뮬레이션 시간 길이. 이 간격 값 뒤에 시간 단위를 지정해야 합니다. 지정된 단위의 시간 동안 시뮬레이션이 발생합니다. 예를 들어 20 MINUTE를 지정하면 20분 동안 시뮬레이션이 실행됩니다.

    참고

    Aurora 복제본 실패 이벤트에 대한 시간 간격을 지정할 때는 각별히 주의하십시오. 시간 간격을 너무 길게 지정하고 마스터 인스턴스가 실패 이벤트 중에 다량의 데이터를 기록하는 경우, Aurora DB 클러스터에서 Aurora 복제본이 충돌했다고 간주하여 해당 복제본을 교체할 수도 있습니다.

디스크 실패 테스트

ALTER SYSTEM SIMULATE DISK FAILURE 오류 삽입 쿼리를 사용하여 Aurora DB 클러스터에 대한 디스크 실패를 시뮬레이션할 수 있습니다.

디스크 실패 시뮬레이션 중에는 Aurora DB 클러스터에서 임의로 디스크 세그먼트를 오류 상태로 표시합니다. 시뮬레이션 기간 동안 이러한 세그먼트에 대한 요청이 차단됩니다.

구문

Copy
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE [ IN DISK index | NODE index ] FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };

옵션

이 오류 삽입 쿼리에는 다음 파라미터가 사용됩니다.

  • percentage_of_failure — 실패 이벤트 중에 오류 상태로 표시할 디스크의 비율(%). 이 값은 0 ~ 100의 실수(Double)입니다. 0을 지정하면 디스크의 어떤 부분도 오류 상태로 표시되지 않습니다. 100을 지정하면 전체 디스크가 오류 상태로 표시됩니다.

  • DISK index — 실패 이벤트를 시뮬레이션할 특정 논리 데이터 블록. 가용 논리 데이터 블록의 범위를 초과하는 경우, 지정할 수 있는 최대 인덱스 값을 알려주는 오류가 발생합니다. 자세한 내용은 Aurora DB 클러스터를 위한 볼륨 상태 표시 섹션을 참조하십시오.

  • NODE index — 실패 이벤트를 시뮬레이션할 특정 스토리지 노드. 가용 스토리지 노드의 범위를 초과하는 경우, 지정할 수 있는 최대 인덱스 값을 알려주는 오류가 발생합니다. 자세한 내용은 Aurora DB 클러스터를 위한 볼륨 상태 표시 섹션을 참조하십시오.

  • quantity — 디스크 실패를 시뮬레이션하는 시간 길이. 이 간격 값 뒤에 시간 단위를 지정해야 합니다. 지정된 단위의 시간 동안 시뮬레이션이 발생합니다. 예를 들어 20 MINUTE를 지정하면 20분 동안 시뮬레이션이 실행됩니다.

디스크 정체 테스트

ALTER SYSTEM SIMULATE DISK CONGESTION 오류 삽입 쿼리를 사용하여 Aurora DB 클러스터에 대한 디스크 실패를 시뮬레이션할 수 있습니다.

디스크 정체 시뮬레이션 중에는 Aurora DB 클러스터에서 임의로 디스크 세그먼트를 정체 상태로 표시합니다. 시뮬레이션 기간 동안 지정된 최소 지연 시간과 최대 지연 시간 사이에서 이러한 세그먼트에 대한 요청이 지연됩니다.

구문

Copy
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION BETWEEN minimum AND maximum MILLISECONDS [ IN DISK index | NODE index ] FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };

옵션

이 오류 삽입 쿼리에는 다음 파라미터가 사용됩니다.

  • percentage_of_failure - 실패 이벤트 중에 정체 상태로 표시할 디스크의 비율(%). 이 값은 0 ~ 100의 실수(Double)입니다. 0을 지정하면 디스크의 어떤 부분도 정체 상태로 표시되지 않습니다. 100을 지정하면 전체 디스크가 정체 상태로 표시됩니다.

  • DISK index 또는 NODE index - 실패 이벤트를 시뮬레이션할 특정 디스크 또는 노드. 디스크 또는 노드의 인덱스 범위를 초과할 경우 지정할 수 있는 최대 인덱스 값을 알려주는 오류가 발생합니다.

  • minimummaximum - 최대 및 최소 정체 지연 시간(밀리초). 정체 상태로 표시된 디스크 세그먼트가 시뮬레이션 기간 중에 최소 밀리초 시간부터 최대 밀리초 시간까지의 시간 범위 내에서 임의 시간 동안 지연됩니다.

  • quantity - 디스크 정체를 시뮬레이션하는 시간 길이. 이 간격 값 뒤에 시간 단위를 지정해야 합니다. 지정된 단위의 시간 동안 시뮬레이션이 발생합니다. 예를 들어 20 MINUTE를 지정하면 20분 동안 시뮬레이션이 실행됩니다.

빠른 DDL을 이용하는 Amazon Aurora에서의 테이블 수정

MySQL에서 많은 데이터 정의 언어(DDL) 작업이 상당한 성능 임팩트를 가집니다. 성능 임팩트는 최근의 온라인 DDL 개선에도 불구하고 발생합니다.

예를 들어 ALTER TABLE 작업을 이용해 열을 테이블에 추가한다고 가정해 보겠습니다. 지정된 알고리즘에 따라 이 작업은 다음을 포함할 수 있습니다.

  • 테이블의 전체 사본 생성

  • 동시에 발생하는 데이터 조작 언어(DML) 작업을 처리하는 임시 테이블 생성

  • 테이블용의 모든 인덱스 리빌드

  • 동시에 발생하는 DML 변경 사항을 적용하면서 테이블 록 적용

  • 동시에 발생하는 DML 처리량 표시

In Amazon Aurora에서 빠른 DDL을 이용해 ALTER TABLE 작업을 거의 동시에 실행할 수 있습니다. 이 작업은 테이블을 복사하거나 다른 DML 명령문에 영향을 거의 주지 않고 완료됩니다. 이 작업은 테이블 복사를 위해 임시 스토리지를 사용하지 않으므로 스몰 인스턴스 유형의 라지 테이블에 대해서도 DDL 문을 유용하게 만듭니다.

참고

빠른 DDL은 Aurora 버저 1.12 이상에서 사용할 수 있습니다. Aurora 버전에 대한 자세한 내용은 Amazon Aurora 데이터베이스 엔진 업데이트 섹션을 참조하십시오.

제한

현재 빠른 DDL에는 다음과 같은 제한 사항이 있습니다.

  • 빠른 DDL은 기존 테이블 끝까지 기본값 없이 null이 허용된 열 추가만 지원합니다.

  • 빠른 DDL은 분할된 테이블을 지원하지 않습니다.

  • 빠른 DDL은 중복 행 형식을 사용하는 InnoDB 테이블을 지원하지 않습니다.

구문

Copy
ALTER TABLE tbl_name ADD COLUMN col_name column_definition

옵션

이 명령문의 옵션은 다음과 같습니다.

  • tbl_name수정할 테이블 이름.

  • col_name추가할 열 이름.

  • col_definition추가할 열 정의.

    참고

    기본값 없이 null이 허용된 열 정의를 지정해야 합니다. 그렇지 않으면 빠른 DLL을 사용할 수 없습니다.

Aurora DB 클러스터를 위한 볼륨 상태 표시

Amazon Aurora에서 DB 클러스터 볼륨은 논리 블록의 모음으로 구성됩니다. 이 각각은 할당된 스토리지의 10기가바이트를 나타냅니다. 이러한 블록을 보호 그룹이라고 합니다.

각 보호 그룹의 데이터는 스토리지 노드로 불리는 6개의 물리 스토리지 장치에 복제됩니다. 이러한 스토리지 노드는 DB 클러스터가 상주하는 리전의 3개 가용 노드(AZ)에 할당됩니다. 또한 각 스토리지 노드에는 DB 클러스터 볼륨에 대해 1개 이상의 논리 데이터 블록이 포함됩니다. 보호 그룹 및 스토리지 노드에 대해 자세히 알아보려면, AWS 데이터베이스 블로그의 Aurora 스토리지 엔진 소개를 참조하십시오.

전체 스토리지 노드 또는 스토리지 노드 내부의 단일 논리 데이터 블록의 장애를 시뮬레이션할 수 있습니다. 이를 위해 ALTER SYSTEM SIMULATE DISK FAILURE 오류 삽입 쿼리를 이용합니다. 쿼리에서 특정 논리 데이터 블록 또는 스토리지 노드의 인덱스 값을 지정합니다. 그러나 DB 클러스터 볼륨이 사용하는 논리 데이터 블록 또는 스토리지 노드의 수보다 큰 인덱스 값을 지정하면, 쿼리는 오류를 반환합니다. 오류 삽입 쿼리에 대한 자세한 내용은 오류 삽입 쿼리를 사용하여 Amazon Aurora 테스트 단원을 참조하십시오.

SHOW VOLUME STATUS 쿼리를 사용하여 오류를 회피할 수 있습니다. 쿼리가 두 서버 상태 변수, DisksNodes을(를) 반환합니다. 이러한 변수는 DB 클러스터 블록에 대해 각각 논리 데이터 블록과 스토리지 노드의 총 수를 표시합니다.

참고

SHOW VOLUME STATUS 쿼리는 Aurora 버전 1.12 이상에서 사용할 수 있습니다. Aurora 버전에 대한 자세한 내용은 Amazon Aurora 데이터베이스 엔진 업데이트 섹션을 참조하십시오.

구문

Copy
SHOW VOLUME STATUS

다음 예는 전형적인 SHOW VOLUME STATUS 결과를 보여줍니다.

mysql> SHOW VOLUME STATUS;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Disks         | 96    |
| Nodes         | 74    |
+---------------+-------+