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

Amazon Aurora 개요

Amazon Aurora(Aurora)는 완전 관리 형태로 MySQL과 호환되는 관계형 데이터베이스 엔진으로서 고사양 상업용 데이터베이스의 속도 및 안정성이 오픈 소스 데이터베이스의 간편성 및 비용 효율성과 결합되었습니다. 대부분 기존 애플리케이션을 변경할 필요 없이 그대로 사용하더라도 MySQL 성능이 최대 5배까지 향상됩니다.

Amazon Aurora는 새로 배포하는 MySQL이든, 혹은 기존에 배포한 MySQL이든 상관없이 설치, 조작 및 조정이 간편하고 비용 효율적이기 때문에 비즈니스와 애플리케이션에 더욱 많은 시간을 투자할 수 있습니다. Amazon Relational Database Service(Amazon RDS)는 프로비저닝, 패치, 백업, 복구, 결함 감지, 수리 등 일상적인 데이터베이스 작업을 처리할 수 있는 Amazon Aurora 관리 기능을 지원합니다. 또한 Amazon RDS는 기존 MySQL 애플리케이션용 Amazon RDS를 Amazon Aurora로 전환할 수 있는 푸시 버튼식 마이그레이션 도구도 제공합니다.

Amazon Aurora는 MySQL을 즉시 대체할 수 있는 엔진입니다. 오늘날 기존 MySQL 데이터베이스에 사용되는 코드, 도구 및 애플리케이션 모두 Amazon Aurora에서도 사용할 수 있습니다.

Amazon Aurora 인스턴스를 생성하면 DB 클러스터가 만들어집니다. DB 클러스터는 하나 이상의 인스턴스와 이 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성됩니다. Aurora 클러스터 볼륨은 다중 가용 영역을 모두 아우르는 가상 데이터베이스 스토리지 볼륨으로서, 각 가용 영역에는 클러스터 데이터의 사본이 복사됩니다. Aurora DB 클러스터는 다음과 같이 두 가지 유형의 인스턴스로 구성됩니다.

  • 기본 인스턴스 – 읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨의 모든 데이터 변경을 실행합니다. 각 Aurora DB 클러스터마다 기본 인스턴스가 하나씩 있습니다.

  • Aurora 복제본 – 읽기 연산만 지원합니다. 각 Aurora DB 클러스터는 기본 인스턴스에 더하여 최대 15개까지 Aurora 복제본을 구성할 수 있습니다. 다수의 Aurora 복제본이 읽기 워크로드를 분산시키면 Aurora 복제본을 별도의 가용 영역으로 이동시켜 데이터베이스 가용성을 높이는 것도 가능합니다.

다음은 Amazon Aurora 클러스터 볼륨과 기본 인스턴스, 그리고 Aurora DB 클러스터에 속한 Aurora 복제본의 관계를 나타낸 다이어그램입니다.

 Amazon Aurora 아키텍처

가용성

다음 표에서는 현재 Amazon Aurora를 사용할 수 있는 리전을 보여 줍니다.

Aurora 엔드포인트

DB 클러스터에 대한 여러 엔드포인트 중 하나를 사용하여 Aurora DB 클러스터의 인스턴스에 연결할 수 있습니다. 엔드포인트는 도메인 이름과 콜론으로 구분된 포트로 구성됩니다. 예를 들면 다음과 같습니다. mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306. 다음에서 각 시나리오에 가장 적합한 엔드포인트를 선택합니다.

클러스터 엔드포인트

각 Aurora DB 클러스터에는 연결할 수 있는 클러스터 엔드포인트가 하나씩 있습니다. 클러스터 엔드포인트는 DB 클러스터의 기본 인스턴스에 연결하는 데 사용되며, 이를 통해 읽기 및 쓰기 연산을 실행할 수 있습니다.

기본 인스턴스에도 고유의 엔드포인트가 있습니다. 이 두 가지 엔드포인트 간의 차이점은 클러스터 엔드포인트가 항상 현재 기본 인스턴스를 향한다는 것입니다. 다시 말해서, 기본 인스턴스에 결함이 발생하면 클러스터 엔드포인트는 새로운 기본 인스턴스로 향하게 됩니다. 기본 인스턴스에 결함이 발생하면 연결을 다시 설정해야 합니다. 장애 조치에 대한 자세한 내용은 Aurora DB 클러스터의 내결함성을(를) 참조하십시오.

고가용성 시나리오에서는 클러스터 엔드포인트에 연결하는 것이 좋습니다. 이렇게 하면 장애 조치가 완료 된 후 애플리케이션이 새 기본 인스턴스에 다시 연결됩니다. 장애 조치 중 Aurora는 장애 인스턴스를 대체하는 새로 승격된 기본 인스턴스에서 클러스터 엔드포인트로 요청을 계속 처리합니다. Aurora는 서비스 중단을 최소화하면서 클러스터 엔드포인트를 제공합니다.

클러스터 엔드포인트 사용 방법에 대한 예로, 기본 인스턴스와 다른 가용 영역에 두 개의 Aurora 복제본이 있는 Aurora DB 클러스터를 가정하겠습니다. 이때 클러스터 엔드포인트에 연결하면 기본 인스턴스에 읽기 트래픽과 쓰기 트래픽을 모두 전송할 수 있습니다. 또한 각 Aurora 복제본의 엔드포인트에 연결하여 이러한 DB 인스턴스에 쿼리를 직접 보낼 수도 있습니다. 만약의 경우 기본 인스턴스나 기본 인스턴스가 배포된 가용 영역에 장애가 발생하면 RDS는 Aurora 복제본 하나를 새로운 기본 인스턴스로 승격하고 클러스터 엔드포인트가 새로운 기본 인스턴스로 향하도록 DNS(도메인 이름 서비스) 레코드를 업데이트합니다. 애플리케이션은 서비스 중단을 최소화하면서 클러스터 엔드포인트를 사용하여 읽기 및 쓰기 트래픽을 Aurora DB 클러스터에 계속 전송합니다.

리더 엔드포인트

각 Aurora DB 클러스터에는 DB 클러스터의 Aurora 중 하나에 연결하는 데 사용할 수 있는 리더 엔드포인트가 있습니다. DB 인스턴스에 대한 리더 엔드포인트(reader endpoint)는 DB 클러스터에서 사용 가능한 Aurora 복제본 간에 연결을 로드 밸런싱합니다. 클라이언트가 리더 엔드포인트에 대한 새로운 연결을 요청하면 Aurora는 DB 클러스터 내의 Aurora 복제본 간에 연결 요청을 분배합니다. 이 기능은 DB 클러스터 내의 여러 Aurora 복제본 간에 읽기 워크로드의 균형을 유지하는 데 도움이 됩니다.

Aurora DB 클러스터에 Aurora 복제본 없이 기본 인스턴스만 포함된 경우 리더 엔드포인트가 기본 인스턴스에 트래픽을 전달합니다. Aurora 복제본이 DB 클러스터에 추가되면, 리더 엔드포인트가 서비스 중단을 최소화하여 Aurora 복제본으로 트래픽을 전달합니다.

장애 조치가 발생하고 연결된 Aurora 복제본이 기본 인스턴스로 승격되면 연결이 끊어집니다. 클러스터 내의 다른 Aurora 복제본으로 읽기 워크로드를 계속 전송하려면 리더 엔드포인트에 다시 연결해야 합니다. 장애 조치에 대한 자세한 내용은 Aurora DB 클러스터의 내결함성을(를) 참조하십시오.

리더 엔드포인트를 사용하여 DB 클러스터의 읽기 전용 쿼리에 높은 가용성을 제공할 수 있습니다. 이 접근 방식을 사용하려면 다양한 가용 영역에 여러 Aurora 복제본을 배치한 다음 읽기 워크로드를 위한 리더 엔드포인트에 연결합니다. 만약의 경우 가용 영역에 장애가 발생하면 애플리케이션은 서비스 중단을 최소화하면서 리더 엔드포인트를 사용하여 Aurora DB 클러스터 내의 Aurora 복제본으로 읽기 트래픽을 계속 전송합니다.

리더 엔드포인트는 DB 클러스터 내의 Aurora 복제본에 대한 연결을 로드 밸런싱할 뿐입니다. 쿼리를 로드 밸런싱하여 클러스터에 대한 읽기 워크로드를 분산하려는 경우 애플리케이션에서 이 작업을 관리해야 합니다.

장애 조치 중 리더 엔드포인트는 Aurora 복제본이 기본 인스턴스로 승격되는 짧은 시간 동안 DB 클러스터의 기본 인스턴스에 직접 연결할 수 있습니다.

클라이언트가 DNS 정보를 캐싱할 경우 클라이언트가 캐시된 연결 설정을 사용하여 동일한 Aurora 복제본에 연결할 때 연결 로드 밸린싱에 일부 불일치가 나타날 수 있습니다.

인스턴스 엔드포인트

DB 클러스터 내의 기본 인스턴스와 Aurora 복제본에는 모두 인스턴스 엔드포인트가 있습니다. 인스턴스 엔드포인트는 특정 인스턴스에 직접 연결하는 데 사용할 수 있는 고유의 엔드포인트입니다. 인스턴스 엔드포인트는 식별자에 cluster-를 포함시키지 않습니다. 예를 들어, 클러스터 엔드포인트는 mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306일 수 있으며, 기본 인스턴스에 대한 인스턴스 엔드포인트는 mydbcluster-primary.123456789012.us-east-1.rds.amazonaws.com:3306일 수 있습니다.

여러 클라이언트를 구성하여 Aurora DB 클러스터 내의 각기 다른 Aurora 복제본에 연결하는 방법으로 애플리케이션의 읽기 워크로드를 분산시킬 수 있습니다. 고가용성 시나리오의 경우 Aurora 복제본을 별도의 가용 영역에 배치할 수도 있습니다. Aurora 복제본을 별도의 가용 영역에 배치하면 가용 영역에 장애가 발생할 경우 애플리케이션이 Aurora DB 클러스터에서 데이터를 읽을 수 있습니다.

인스턴스 엔드포인트를 사용하여 인스턴스에 연결하기 전에 클러스터 엔드포인트를 사용하거나 DB 클러스터의 리더 엔드포인트를 사용해 보십시오. DB 클러스터에 대한 장애 조치가 발생할 경우 클러스터 엔드포인트를 사용하여 새로 승격된 기본 인스턴스에 연결할 수 있으며 리더 엔드포인트를 사용하여 DB 클러스터에서 사용 가능한 모든 Aurora 복제본에 연결할 수 있습니다.

Amazon Aurora 스토리지

Aurora 데이터는 솔리드 스테이트 디스크(SSD) 드라이브를 사용하는 단일 가상 볼륨인 클러스터 볼륨에 저장됩니다. 클러스터 볼륨은 동일한 리전에 속한 다중 가용 영역의 데이터 사본으로 구성되어 있습니다. 이러한 가용 영역에서 데이터가 자동으로 복제되기 때문에 데이터 손실 가능성은 줄고 오히려 내구성이 크게 높아집니다. 이러한 복제를 통해 데이터 사본이 이미 나머지 가용 영역에 존재하여 DB 클러스터의 인스턴스에 대한 데이터 요청을 처리할 수 있다는 점에서 장애 조치 중에도 데이터베이스의 가용성이 높아집니다.

데이터베이스의 데이터 용량이 늘어날수록 Aurora 클러스터 볼륨도 자동 확장됩니다. 확장할 수 있는 Aurora 클러스터 볼륨의 최대 크기는 64테라바이트(TB)입니다. 테이블 크기는 클러스터 볼륨 크기로 제한됩니다. 즉 Aurora DB 클러스터의 테이블에 대한 최대 크기는 64TB입니다. Aurora 클러스터 볼륨은 최대 64TB까지 증가할 수 있지만 요금은 Aurora 클러스터 볼륨에서 사용한 공간에 대해서만 청구됩니다. 요금에 대한 자세한 내용은 Aurora용 Amazon RDS 요금을(를) 참조하십시오.

Amazon Aurora 복제

Aurora 복제본은 Aurora DB 클러스터에 있는 독립적인 엔드포인트입니다. 이러한 복제본을 사용하면 DB 클러스터 볼륨의 데이터에 읽기 전용으로 액세스할 수 있으며 여러 복제 인스턴스에서 데이터 관련 읽기 작업의 규모를 조정하여 데이터 읽기 성능과 Aurora DB 클러스터의 데이터 가용성을 모두 향상시킬 수 있습니다. Aurora 복제본은 장애 조치 대상이기도 하며 Aurora DB 클러스터의 기본 인스턴스가 실패하는 경우 신속히 승격됩니다.

Aurora 복제본 및 Aurora DB 클러스터의 데이터 복제와 관련된 기타 옵션에 대한 자세한 내용은 Amazon Aurora를 사용한 복제을(를) 참조하십시오.

Amazon Aurora 안정성

Aurora는 안정성, 내구성 및 내결함성을 고려하여 설계되었습니다. Aurora DB 클러스터는 Aurora 복제본을 추가하여 다른 가용 영역에 배포하는 등의 방법으로 가용성을 높이도록 설계할 수 있습니다. 그 밖에도 Aurora에는 안정적인 데이터베이스 솔루션을 위한 자동 기능이 몇 가지 포함되어 있습니다.

스토리지 자동 복구

Aurora는 3개의 가용 영역에 데이터 사본을 다수 배포하기 때문에 디스크 결함으로 인한 데이터 손실 가능성이 최소화됩니다. Aurora가 클러스터 볼륨을 구성하는 디스크 볼륨에서 결함을 자동 감지합니다. 예를 들어 디스크 볼륨 세그먼트에 결함이 발생하면 Aurora가 즉시 해당 세그먼트를 복구합니다. Aurora가 디스크 세그먼트를 복구할 때는 동일한 클러스터 볼륨을 구성하는 나머지 디스크 볼륨의 데이터를 사용하기 때문에 복구 세그먼트의 데이터도 이용 가능합니다. 결과적으로 Aurora는 데이터 손실을 방지할 뿐만 아니라 특정 시점으로 복구 기능을 사용해 디스크 결함을 복구할 필요성도 줄어듭니다.

"유지 가능한" 캐시 워밍

Aurora는 전원이 꺼진 데이터베이스를 가동하거나 결함 발생 이후 다시 시작할 때 버퍼 풀 캐시를 "워밍"합니다. 즉, Aurora가 인 메모리 페이지 캐시에 저장된 기존 공통 쿼리 페이지를 이용해 버퍼 풀을 미리 로드합니다. 이 경우 일반적인 데이터베이스 사용과 달리 버퍼 풀의 "웜 업" 필요성을 우회할 수 있기 때문에 성능이 향상되는 이점이 있습니다.

Aurora 페이지 캐시는 데이터베이스가 아닌 별도의 프로세스를 통해 관리되기 때문에 데이터베이스와 상관없이 "유지됩니다". 예상과 달리 데이터베이스에 결함이 발생하더라도 페이지 캐시가 메모리에 남아있기 때문에 데이터베이스를 재시작할 때 버퍼 풀이 가장 최신 상태로 워밍됩니다.

충돌 복구

Aurora는 거의 실시간으로 충돌을 복구하여 애플리케이션 데이터를 지속적으로 처리할 수 있도록 설계되었습니다. Aurora가 비동기 방식으로 병렬 스레드에서 충돌 복구를 실행하기 때문에 충돌 직후에도 데이터베이스를 열어두고 사용할 수 있습니다. 자세한 내용은 Aurora DB 클러스터의 내결함성을(를) 참조하십시오.

Aurora 성능 개선 사항

Amazon Aurora에는 고급 상용 데이터베이스의 다양한 필요를 지원하는 성능 향상이 포함되어 있습니다.

빠른 입력 기능

빠른 입력 기능은 기본 키에 의해 정렬되는 병렬 입력을 빠르게 처리해 주며, 특히 LOAD DATAINSERT INTO ... SELECT ... 문 사용 시 유용합니다. 빠른 입력 기능은 문을 실행할 때 인덱스 순회에서 커서의 위치를 캐싱합니다. 이에 따라 인덱스를 불필요하게 다시 순회하지 않도록 해줍니다.

다음 측정치를 모니터링하면 DB 클러스터에서 빠른 입력 기능의 효과를 확인할 수 있습니다.

  • aurora_fast_insert_cache_hits: 캐싱된 커서가 성공적으로 검색 및 확인되면 증가하는 카운터입니다.

  • aurora_fast_insert_cache_misses: 캐싱된 커서가 더 이상 유효하지 않고 Aurora가 정상적인 인덱스 순회를 수행하면 증가하는 카운터입니다.

다음 명령을 사용하면 빠른 입력 측정치의 현재 값을 검색할 수 있습니다.

Copy
mysql> show global status like 'Aurora_fast_insert%';

출력은 다음과 비슷합니다.

Copy
+---------------------------------+-----------+ | Variable_name | Value | +---------------------------------+-----------+ | Aurora_fast_insert_cache_hits | 3598300 | | Aurora_fast_insert_cache_misses | 436401336 | +---------------------------------+-----------+

Amazon Aurora 보안

Amazon Aurora 보안은 다음과 같이 세 가지 수준에서 관리됩니다.

  • Aurora DB 클러스터 및 DB 인스턴스에 대한 Amazon RDS 관리 작업자를 통제하려면 AWS Identity and Access Management(IAM)를 사용합니다. IAM 자격 증명을 사용하여 AWS에 연결할 때는 Amazon RDS 관리 작업에 필요한 권한을 부여할 수 있는 IAM 정책이 IAM 계정에 반드시 필요합니다. 자세한 내용은 Amazon RDS에 대한 인증 및 액세스 제어을(를) 참조하십시오.

    IAM 계정을 사용해 Amazon Aurora 콘솔에 액세스하려면 먼저 IAM 계정으로 AWS Management Console에 로그인한 다음 https://console.aws.amazon.com/rds에서 Aurora 콘솔로 이동합니다.

  • Aurora DB 클러스터는 Amazon Virtual Private Cloud(VPC)에서 생성해야 합니다. VPC에서 Aurora DB 클러스터에 대한 DB 인스턴스의 엔드포인트 및 포트에 연결할 수 있는 디바이스와 Amazon EC2 인스턴스를 제어하려면 VPC 보안 그룹을 사용합니다. 이 엔드포인트와 포트는 Secure Sockets Layer(SSL) 방식으로 연결할 수 있습니다. 그 밖에도 기업의 방화벽 규칙을 통해 기업에서 이용하는 디바이스의 DB 인스턴스 연결 여부를 제어하는 것도 가능합니다. VPC에 대한 자세한 내용은 Amazon Virtual Private Cloud(VPC) 및 Amazon RDS을(를) 참조하십시오.

  • Amazon Aurora DB 클러스터에 대한 로그인 및 권한을 인증하기 위해서는 다음 접근 방식 중 하나를 따르거나 두 방식을 조합할 수 있습니다.

    독립형 MySQL 인스턴스와 동일한 접근법을 사용할 수 있습니다. CREATE USER, RENAME USER, GRANT, REVOKESET PASSWORD 등의 명령은 온프레미스 데이터베이스에서 작동하는 것과 마찬가지로 작동하며, 데이터베이스 스키마 테이블을 직접 수정할 때도 동일합니다. 자세한 내용은 MySQL 설명서의 MySQL 사용자 계정 관리을(를) 참조하십시오.

    또한 IAM 데이터베이스 인증을 사용할 수도 있습니다. IAM 데이터베이스 인증의 경우, IAM 사용자 또는 IAM 역할 및 인증 토큰을 이용해 DB 클러스터에 인증합니다. 인증 토큰은 서명 버전 4 서명 프로세스를 통해 생성하는 고유 값입니다. IAM 데이터베이스 인증을 사용하면 동일한 자격 증명을 사용해 AWS 리소스 및 데이터베이스에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 MySQL 및 Amazon Aurora를 위한 IAM 데이터베이스 인증 섹션을 참조하십시오.

Amazon Aurora DB 인스턴스를 생성할 때 마스터 사용자는 다음과 같은 기본 권한을 갖습니다.

  • ALTER

  • ALTER ROUTINE

  • CREATE

  • CREATE ROUTINE

  • CREATE TEMPORARY TABLES

  • CREATE USER

  • CREATE VIEW

  • DELETE

  • DROP

  • EVENT

  • EXECUTE

  • GRANT OPTION

  • INDEX

  • INSERT

  • LOAD FROM S3

  • LOCK TABLES

  • PROCESS

  • REFERENCES

  • RELOAD

  • REPLICATION CLIENT

  • REPLICATION SLAVE

  • SELECT

  • SHOW DATABASES

  • SHOW VIEW

  • TRIGGER

  • UPDATE

DB 클러스터를 생성할 때는 각 DB 클러스터의 관리 서비스를 위해 rdsadmin 사용자가 만들어집니다. rdsadmin 계정을 삭제하려고 하거나, 계정 이름 및 암호를 변경하려고 하거나, 혹은 계정 권한을 변경하려고 하면 오류가 발생합니다.

DB 클러스터 관리를 위해 기본 killkill_query 명령은 사용이 제한됩니다. 대신에 Amazon RDS 명령으로 rds_killrds_kill_query를 사용하여 DB 인스턴스의 사용자 세션이나 쿼리를 종료할 수 있습니다.

SSL을 이용한 Aurora 데이터 보안

Amazon Aurora DB 클러스터는 Amazon RDS MySQL DB 인스턴스와 동일한 프로세스 및 퍼블릭 키를 사용하여 애플리케이션의 Secure Sockets Layer(SSL) 연결을 지원합니다.

Amazon RDS가 SSL 인증서를 생성한 후 Amazon RDS가 인스턴스를 프로비저닝할 때 DB 인스턴스에 인증서를 설치합니다. 인증 기관이 서명하는 SSL 인증서에는 스푸핑 공격으로부터 보호해주는 SSL 인증서를 위한 일반 이름(CN)으로 DB 인스턴스 엔드포인트가 포함되어 있습니다. 그 결과 클라이언트가 Subject Alternative Names(SAN)를 지원할 경우 SSL을 이용한 DB 클러스터 연결의 유일한 방법은 DB 클러스터 엔드포인트를 이용하는 것입니다. 그렇지 않으면 기본 인스턴스의 엔드포인트를 사용해야 합니다. SAN과 SSL을 지원하는 클라이언트로서 MariaDB Connector/J 클라이언트를 권장합니다. 자세한 내용은 MariaDB Connector/J 다운로드 페이지을(를) 참조하십시오.

퍼블릭 키는 https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem에 저장되어 있습니다.

기본 mysql 클라이언트를 사용하여 연결을 암호화하려면 --ssl-ca 파라미터를 사용하여 mysql 클라이언트를 시작하고 다음과 같은 퍼블릭 키 등을 참조합니다.

mysql -h mycluster-primary.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=[full path]rds-combined-ca-bundle.pem --ssl-verify-server-cert

GRANT 문을 사용하여 특정 사용자 계정에 대한 SSL 연결을 요구할 수 있습니다. 예를 들어, 다음 문을 사용하여 사용자 계정 encrypted_user:

GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL

참고

MySQL과의 SSL 연결에 대한 자세한 내용은 MySQL 문서을(를) 참조하십시오.

Amazon Aurora DB 클러스터의 현지 시간대

기본적으로 Amazon Aurora DB 클러스터의 시간대는 협정 세계시(UTC)입니다. 대신 DB 클러스터의 인스턴스 시간대를 애플리케이션의 현지 시간대로 설정할 수 있습니다.

DB 클러스터의 현지 시간대를 설정하려면 DB 클러스터의 클러스터 파라미터 그룹에서 time_zone 파라미터를 이 단원의 뒤에 나오는 지원되는 값 중 하나로 설정합니다. DB 클러스터에 대한 time_zone 파라미터를 설정하면 DB 클러스터의 모든 인스턴스가 새로운 현지 시간대를 사용하도록 변경됩니다. 다른 Aurora DB 클러스터가 동일한 클러스터 파라미터 그룹을 사용하면 해당 DB 클러스터의 모든 인스턴스도 새로운 현지 시간대를 사용하도록 변경됩니다. 클러스터 수준 파라미터에 대한 자세한 내용은 DB 클러스터와 DB 인스턴스 파라미터을(를) 참조하십시오.

현지 시간대를 설정하면 데이터베이스에 대한 모든 새 연결에 변경 사항이 반영됩니다. 현지 시간대를 변경할 때 데이터베이스에 대해 열린 연결이 있는 경우 연결을 닫고 새 연결을 열어야 현지 시간대 업데이트가 표시됩니다.

리전 간 복제를 사용 중인 경우 복제 마스터 DB 클러스터와 복제본이 서로 다른 파라미터 그룹을 사용합니다. 파라미터 그룹은 리전에 고유합니다. 각 인스턴스에 대해 동일한 현지 시간대를 사용하려면 복제본 마스터와 복제본 모두의 파라미터 그룹에서 time_zone 파라미터를 설정해야 합니다.

DB 클러스터 스냅샷에서 DB 클러스터를 복원할 경우 현지 시간대가 UTC로 설정됩니다. 복원이 완료된 후 시간대를 현지 시간대로 업데이트할 수 있습니다. DB 클러스터를 특정 시점으로 복원할 경우 복원된 DB 클러스터의 현지 시간대는 복원된 DB 클러스터의 파라미터 그룹에서 설정한 시간대입니다.

현지 시간대를 다음 표에 나열된 값 중 하나로 설정할 수 있습니다. 일부 시간대의 경우 표에 설명된 대로 특정 날짜 범위 시간 값이 잘못 보고될 수 있습니다. 호주 시간대의 경우 표에 설명된 대로 반환된 시간대 약어가 만료된 값입니다.

시간대

참고

Africa/Harare

시간대 설정이 1903년 2월 28일 21:49:40 GMT에서 1903년 2월 28일 21:55:48 GMT까지 잘못된 값을 반환할 수 있습니다.

Africa/Monrovia

Africa/Nairobi

시간대 설정이 1939년 12월 31일 21:30:00 GMT에서 1959년 12월 31일 21:15:15 GMT까지 잘못된 값을 반환할 수 있습니다.

Africa/Windhoek

America/Bogota

시간대 설정이 1914년 11월 23일 04:56:16 GMT에서 1914년 11월 23일 04:56:20 GMT까지 잘못된 값을 반환할 수 있습니다.

America/Caracas

America/Chihuahua

America/Cuiaba

America/Denver

America/Fortaleza

America/Guatemala

America/Halifax

시간대 설정이 1918년 10월 27일 05:00:00 GMT에서 1918년 10월 31일 05:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

America/Manaus

America/Matamoros

America/Monterrey

America/Montevideo

America/Phoenix

America/Tijuana

Asia/Ashgabat

Asia/Baghdad

Asia/Baku

Asia/Bangkok

Asia/Beirut

Asia/Calcutta

Asia/Kabul

Asia/Karachi

Asia/Kathmandu

Asia/Muscat

시간대 설정이 1919년 12월 31일 20:05:36 GMT에서 1919년 12월 31일 20:05:40 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Riyadh

시간대 설정이 1947년 3월 13일 20:53:08 GMT에서 1949년 12월 31일 20:53:08 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Seoul

시간대 설정이 1904년 11월 30일 15:30:00 GMT에서 1945년 9월 7일 15:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Shanghai

시간대 설정이 1927년 12월 31일 15:54:08 GMT에서 1940년 6월 2일 16:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Singapore

Asia/Taipei

시간대 설정이 1937년 9월 30일 16:00:00 GMT에서 1979년 9월 29일 15:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Tehran

Asia/Tokyo

시간대 설정이 1937년 9월 30일 15:00:00 GMT에서 1937년 12월 31일 15:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Asia/Ulaanbaatar

Atlantic/Azores

시간대 설정이 1911년 5월 24일 01:54:32 GMT에서 1912년 1월 1일 01:54:32 GMT까지 잘못된 값을 반환할 수 있습니다.

Australia/Adelaide

이 시간대의 약어는 ACDT/ACST가 아닌 CST로 반환됩니다.

Australia/Brisbane

이 시간대의 약어는 AEDT/AEST가 아닌 EST로 반환됩니다.

Australia/Darwin

이 시간대의 약어는 ACDT/ACST가 아닌 CST로 반환됩니다.

Australia/Hobart

이 시간대의 약어는 AEDT/AEST가 아닌 EST로 반환됩니다.

Australia/Perth

이 시간대의 약어는 AWDT/AWST가 아닌 WST로 반환됩니다.

Australia/Sydney

이 시간대의 약어는 AEDT/AEST가 아닌 EST로 반환됩니다.

Brazil/East

Canada/Saskatchewan

시간대 설정이 1918년 10월 27일 08:00:00 GMT에서 1918년 10월 31일 08:00:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Europe/Amsterdam

Europe/Athens

Europe/Dublin

Europe/Helsinki

시간대 설정이 1921년 4월 30일 22:20:08 GMT에서 1921년 4월 30일 22:20:11 GMT까지 잘못된 값을 반환할 수 있습니다.

Europe/Paris

Europe/Prague

Europe/Sarajevo

Pacific/Auckland

Pacific/Guam

Pacific/Honolulu

시간대 설정이 1933년 5월 21일 11:30:00 GMT에서 1945년 9월 30일 11:30:00 GMT까지 잘못된 값을 반환할 수 있습니다.

Pacific/Samoa

시간대 설정이 1911년 1월 1일 11:22:48 GMT에서 1950년 1월 1일 11:30:00 GMT까지 잘못된 값을 반환할 수 있습니다.

US/Alaska

US/Central

US/Eastern

US/East-Indiana

US/Pacific

UTC

Amazon Aurora와 MySQL용 Amazon RDS의 비교

Aurora 인스턴스는 MySQL 클라이언트 애플리케이션과 호환되지만, Aurora는 MySQL보다 많은 이점을 갖추고 있으며 Aurora가 지원하는 MySQL 기능에는 제한이 있습니다. 이러한 기능은 Amazon Aurora와 Amazon RDS의 MySQL 중 어떤 것이 솔루션에 가장 적합한 클라우드 데이터베이스인지를 결정하는 데 영향을 미칠 수 있습니다. 다음 표에서는 Amazon Aurora와 MySQL용 Amazon RDS의 차이점을 보여 줍니다.

기능 Amazon Aurora Amazon RDS for MySQL
읽기 확장 쓰기 연산 성능에 미치는 영향을 최소화하여 최대 15개까지 Aurora 복제본을 지원합니다. 쓰기 연산 성능에 상당한 영향을 미치면서 최대 5개까지 읽기 전용 복제본을 지원합니다.
장애 조치 대상 Aurora 복제본은 자동 장애 조치 대상으로서 데이터 손실이 전혀 없습니다. 읽기 전용 복제본은 마스터 DB 인스턴스 승격이 수동으로 이루어지기 때문에 잠재적 데이터 손실이 있습니다.
MySQL 버전 MySQL 5.6만 지원합니다. MySQL 5.5, 5.6 및 5.7을 지원합니다.
AWS 리전 Aurora DB 클러스터를 생성할 수 있는 리전: 미국 동부(버지니아 북부)(us-east-1), 미국 동부(오하이오)(us-east-2), 미국 서부(오레곤)(us-west-2), 아시아 태평양(뭄바이)(ap-south-1), 아시아 태평양(서울)(ap-northeast-2), 아시아 태평양(시드니)(ap-southeast-2), 아시아 태평양(도쿄)(ap-northeast-1), 캐나다(중부)(ca-central-1), EU(아일랜드)(eu-west-1), EU(런던)(eu-west-2). 모든 AWS 리전에서 사용할 수 있습니다.
MySQL 스토리지 엔진

InnoDB만 지원합니다. 다른 스토리지 엔진의 테이블은 InnoDB로 자동 전환됩니다.

기존 MySQL 테이블을 InnoDB로 전환한 후 Aurora 클러스터로 가져오는 방법에 대한 자세한 내용은 Amazon Aurora DB 클러스터로 데이터 마이그레이션을(를) 참조하십시오.

Amazon Aurora은 InnoDB 엔진만 지원하므로 SQL_MODE 데이터베이스 파라미터의 NO_ENGINE_SUBSTITUTION 옵션이 활성화되어 있습니다. 따라서 해당 테이블이 TEMPORARY로 지정되어 있지 않으면 인 메모리 테이블을 생성하는 기능이 비활성화됩니다.

MyISAM과 InnoDB를 모두 지원합니다.
마스터 인스턴스와 스토리지 엔진이 다른 읽기 전용 복제본 Aurora DB 클러스터를 복제하는 MySQL(non-RDS) 읽기 전용 복제본은 InnoDB만 사용할 수 있습니다. 읽기 전용 복제본은 MyISAM과 InnoDB를 모두 사용할 수 있습니다.
데이터베이스 엔진 파라미터 일부 파라미터는 전체 Aurora DB 클러스터에 적용되고 DB 클러스터 파라미터 그룹에서 관리합니다. 그 밖의 파라미터는 DB 클러스터의 개별 DB 인스턴스에 적용되고 DB 파라미터 그룹에서 관리합니다. 자세한 내용은 DB 클러스터와 DB 인스턴스 파라미터을(를) 참조하십시오. 파라미터는 개별 DB 인스턴스나 읽기 전용 복제본에 적용되고 DB 파라미터 그룹에서 관리합니다.