MySQL용 Amazon RDS FAQ

Amazon Relational Database(Amazon RDS) for MySQL은 현재 MySQL Community Edition 5.7 및 8.0을 지원합니다. 지원되는 마이너 버전에 대한 정보는 Amazon RDS 사용 설명서를 참조하세요.

MySQL의 버전 번호는 다음과 같이 구성되어 있습니다.
MySQL 버전 = X.Y.Z

X = 메이저 버전, Y = 릴리스 레벨, Z = 릴리스 시리즈의 버전 번호.
Amazon RDS에서는 메이저 버전 또는 릴리스 레벨이 변경될 경우 메이저 버전 변경으로 간주합니다. 예: 5.6.X에서 5.7.X로 변경.

릴리스 내 버전 번호가 변경되면 마이너 버전 변경으로 간주합니다. 예: 5.6.27에서 5.6.29로 변경.

예. Amazon RDS FAQ를 참조하세요.

Amazon RDS for MySQL의 Amazon Redshift 기능을 사용한 특정 시점 복원, 스냅샷 복원 및 제로 ETL 통합에는 충돌 복구 가능한 스토리지 엔진이 필요하며 InnoDB 스토리지 엔진만 지원됩니다. MySQL은 다양한 기능을 가진 여러 스토리지 엔진을 지원하지만, 모든 엔진이 중단 복구와 데이터 내구성에 최적화되어 있지는 않습니다. 예를 들어, MyISAM 스토리지 엔진은 안정적인 충돌 복구를 지원하지 않으며 충돌 후 MySQL을 다시 시작할 때 데이터 손실이나 데이터 손상을 초래할 수 있어 특정 시점 복원이나 스냅샷 복원이 의도한 대로 작동하지 못하게 됩니다. 그럼에도 불구하고 Amazon RDS에서 MyISAM을 사용하는 경우 이러한 단계를 수행하면 특정 시나리오에서 DB 스냅샷 복원 기능에 도움이 될 수 있습니다. Federated Storage Engine은 현재 RDS for MySQL에서 지원되지 않습니다.

새로운 DB 인스턴스를 생성할 때, 사용되는 기본 사용자는 특정 권한을 갖습니다. 권한 목록은 Amazon RDS 사용 설명서에서 기본 사용자 계정 권한 섹션을 참조하세요.

RDS for MySQL 읽기 전용 복제본은 트랜잭션 스토리지 엔진이 필요하며, InnoDB 스토리지 엔진에서만 지원됩니다. MyISAM과 같은 비트랜잭션 MySQL 스토리지 엔진에서는 읽기 전용 복제본이 정상적으로 작동하지 않을 수 있습니다. 그래도 MyISAM에서 읽기 전용 복제본을 사용하려면 Amazon CloudWatch의 “복제 지연” 메트릭(AWS Management Console 또는 Amazon CloudWatch API를 통해)을 주의 깊게 모니터링하고 복제 오류로 인해 읽기 전용 복제본이 지연되는 경우 다시 만드십시오. 임시 테이블이나 다른 비트랜잭션 엔진을 사용할 때도 같은 주의 사항이 적용됩니다.

MySQL 버전 5.6 이상에서는 바이너리 로깅 형식을 행 기반으로 설정할 수 있습니다. 기본적으로 복제는 혼합 형식(행 기반 및 문 기반 복제 모두 포함)으로 설정되며 대부분의 사용 사례 요구 사항을 충족해야 합니다. 혼합 형식과 행 기반 복제의 차이점에 대한 자세한 내용은 MySQL 설명서에서 확인할 수 있습니다.

Amazon RDS 블루/그린 배포는 RDS for MySQL 버전 5.7 이상에서 사용할 수 있습니다. RDS for MySQL 설명서에서 사용 가능한 버전에 대해 자세히 알아보세요.

Amazon RDS 블루/그린 배포는 모든 AWS 리전과 AWS GovCloud 리전에서 사용할 수 있습니다.

Amazon RDS 블루/그린 배포에서는 메이저 또는 마이너 버전 업그레이드, 스키마 변경, 인스턴스 크기 조정, 엔진 파라미터 변경 및 유지 관리 업데이트와 같은 데이터베이스 변경을 더 안전하고 더 간단하며 더 빠르게 수행할 수 있습니다.

Amazon RDS 블루/그린 배포를 사용하면 더 안전하고 단순하며 빠르게 데이터베이스를 변경할 수 있습니다. 블루/그린 배포는 메이저 또는 마이너 버전 데이터베이스 엔진 업그레이드, 운영 체제 업데이트, 논리적 복제를 중단하지 않는 그린 환경의 스키마 변경(예: 테이블 끝에 새 열 추가) 또는 데이터베이스 파라미터 설정 변경과 같은 사용 사례에 적합합니다. 블루/그린 배포를 사용하면 한 번의 전환으로 여러 데이터베이스를 동시에 업데이트할 수 있습니다. 이를 통해, 예측 가능한 짧은 가동 중지 시간으로 보안 패치를 최신 상태로 유지하고, 데이터베이스 성능을 개선하고, 최신 데이터베이스 기능에 액세스할 수 있습니다.

블루 인스턴스에서 워크로드를 실행할 때와 동일한 비용이 그린 인스턴스에 대해 발생합니다. 블루 및 그린 인스턴스에서 실행할 때의 비용에는 db.instances에 대한 현재 표준 요금, 스토리지 비용, 읽기/쓰기 I/O 비용 및 사용된 기능에 대한 비용(예: 백업 비용 및 Amazon RDS 성능 개선 도우미 비용)이 포함됩니다. 실질적으로 블루 및 그린 배포가 진행되는 동안 db.instance에서 워크로드를 실행할 때의 약 2배에 해당하는 비용이 발생합니다.

예제: us-east-1 AWS 리전에서 다중 AZ(MAZ) 구성으로 RDS for MySQL 5.7 데이터베이스를 2개의 r5.2xlarge db.instances(프라이머리 데이터베이스 인스턴스와 읽기 전용 복제본)에서 실행하고 있습니다. 각 r5.2xlarge db.instances는 20GiB 범용 Amazon Elastic Block Store(Amazon EBS)에 대해 구성되어 있습니다. Amazon RDS 블루/그린 배포를 사용하여 블루 인스턴스 토폴로지의 클론을 생성하고 15일(360시간) 동안 실행한 다음 성공적인 전환 후에 블루 인스턴스를 삭제합니다. 블루 인스턴스의 비용은 시간당 1.926 USD의 온디맨드 요금으로 15일간 1,387 USD입니다(인스턴스 + EBS 비용). 이 15일간 블루/그린 배포를 사용한 데 대한 총 비용은 2,774 USD입니다. 이는 해당 기간에 블루 인스턴스를 실행하는 비용의 2배입니다.

Amazon RDS 블루/그린 배포에서는 메이저 또는 마이너 버전 업그레이드, 스키마 변경, 인스턴스 크기 조정, 엔진 파라미터 변경 및 유지 관리 업데이트와 같은 데이터베이스 변경을 더 안전하고 더 간단하며 더 빠르게 수행할 수 있습니다.

Amazon RDS 블루/그린 배포에서 전환이 시작되면 전환이 완료될 때까지 블루 환경과 그린 환경 모두에 대한 쓰기가 차단됩니다. 전환 중에 스테이징 환경 또는 그린 환경은 블루 환경을 캐치업하여 블루 환경과 그린 환경의 데이터가 일치할 수 있도록 합니다. 블루 환경과 그린 환경이 완벽하게 동기화되면 블루 및 그린 배포에서 그린 환경으로 트래픽을 리디렉션하여 그린 환경을 새로운 블루 환경으로 승격합니다. 블루 및 그린 배포는 전환이 완료된 후 그린 환경에서의 쓰기를 활성화하도록 설계되었으며, 이를 통해 전환 프로세스 중에 데이터 손실이 발생하지 않도록 보장합니다.

블루 환경이 자체 관리형 논리적 복제본 또는 구독자인 경우 전환이 차단됩니다. 먼저 블루 환경으로의 복제를 중단하고, 전환을 진행한 다음 복제를 재개하는 것이 좋습니다. 반대로 블루 환경이 자체 관리형 논리적 복제본이나 게시자의 소스인 경우에는 계속 전환할 수 있습니다. 하지만 전환 후 친환경 환경에서 복제하려면 자체 관리형 복제본을 업데이트해야 합니다.

Amazon RDS 블루/그린 배포는 이전 프로덕션 환경을 삭제하지 않습니다. 필요한 경우 추가 검증 및 성능/회귀 테스트를 위해 이전 환경에 액세스할 수 있습니다. 이전 프로덕션 환경이 더 이상 필요하지 않다면 삭제해도 됩니다. 이전 프로덕션 인스턴스에는 인스턴스를 삭제하기 전까지 표준 결제 요금이 적용됩니다.

Amazon RDS 블루/그린 배포의 전환 가드레일은 전환 전에 그린 환경이 캐치업될 때까지 블루 및 그린 환경에 대한 쓰기를 차단합니다. 블루/그린 배포는 블루 및 그린 환경에 있는 프라이머리 및 복제본의 상태 확인도 수행합니다. 또한 복제 상태 확인도 수행하는데, 예를 들어 복제가 중지되었는지, 오류가 있는지 여부를 확인합니다. 블루 환경과 그린 환경 사이에 오래 실행되는 트랜잭션이 있는 경우 이를 감지합니다. 사용자는 허용 가능한 최대 가동 중단 시간을 최소 30초로 지정할 수 있으며, 진행 중인 트랜잭션이 이 값을 초과할 경우 전환 제한 시간이 초과됩니다.

아니요. Amazon RDS 블루 및 그린 배포는 Amazon RDS 프록시, 크로스 리전 읽기 전용 복제본 또는 캐스케이드된 읽기 전용 복제본을 지원하지 않습니다.

아니요. 지금은 Amazon RDS 블루 및 그린 배포를 사용하여 변경 사항을 롤백할 수 없습니다.

MySQL은 데이터를 16KiB 페이지의 메모리로 내구성 있는 스토리지에 두 번 기록하는 방법으로 데이터 손실로부터 사용자를 보호합니다. 처음에 ‘이중 쓰기 버퍼’에 기록한 다음 테이블 스토리지에 기록합니다. Amazon RDS 최적화된 쓰기는 AWS Nitro System의 Torn Write Prevention 기능을 사용하여 한 번에 안정적이고 지속적으로 16KiB 데이터 페이지를 데이터 파일에 직접 기록합니다.

Amazon RDS 최적화된 쓰기는 MySQL 메이저 버전 8.0.30 이상에서 사용할 수 있습니다.

Amazon RDS 최적화된 쓰기는 db.r6i 및 db.r5b 인스턴스에서 사용할 수 있습니다. AWS 중국 리전을 제외하고 이러한 인스턴스가 제공되는 모든 리전에서 사용할 수 있습니다.

최대 2배의 개선된 쓰기 트랜잭션 처리량을 원하는 모든 RDS for MySQL 사용자는 Amazon RDS 최적화된 쓰기를 구현해야 합니다. 이 기능은 디지털 결제, 금융 거래 및 온라인 게임 애플리케이션과 같이 워크로드가 쓰기 집약적인 애플리케이션에 특히 유용합니다.

아니요. Amazon Aurora MySQL 호환 버전은 이미 ‘이중 쓰기 버퍼’의 사용을 방지하고 있습니다. 대신, Aurora는 3개 가용 영역에 걸쳐 6가지 방법으로 데이터를 복제하고 쿼럼 기반 접근 방식을 사용하여 데이터를 내구성 있는 방식으로 쓰고 이후에 올바르게 읽습니다.

현재 이 초기 릴리스는 인스턴스 클래스가 최적화된 쓰기를 지원하더라도 Amazon RDS 최적화된 쓰기를 기존 데이터베이스 인스턴스에 사용하는 것을 지원하지 않습니다.

Amazon RDS 최적화된 쓰기는 RDS for MySQL 고객에게 추가 비용 없이 제공됩니다.

MySQL의 임시 객체를 쿼리 처리에 사용하는 워크로드의 경우 Amazon RDS 최적화된 읽기의 이점을 누릴 수 있습니다. 최적화된 읽기는 Amazon EBS 볼륨 대신, 데이터베이스 인스턴스의 NVMe 기반 인스턴스 스토리지에 임시 객체를 배치합니다. 이렇게 하면 복잡한 쿼리의 처리 속도가 최대 50% 더 빨라집니다.

Amazon RDS 최적화된 읽기는 RDS for MySQL의 경우 MySQL 버전 8.0.28 이상에서 사용할 수 있습니다.

Amazon RDS 최적화된 읽기는 db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn, X2iedn 인스턴스가 제공되는 모든 리전에서 사용할 수 있습니다. 자세한 내용은 Amazon RDS DB 인스턴스 클래스 설명서를 참조하세요.

복잡한 쿼리 또는 범용 분석이 필요한 워크로드 또는 복잡한 그룹, 정렬, 해시 집계, 높은 로드 조인 및 공통 테이블 표현식(CTE)이 필요한 워크로드가 있는 경우 고객은 Amazon RDS 최적화된 읽기를 사용해야 합니다. 이러한 사용 사례에서는 임시 테이블이 생성되므로 최적화된 읽기를 통해 워크로드의 쿼리 처리 속도를 높일 수 있습니다.

예. 워크로드를 Optimized Reads 사용 인스턴스로 이동하는 방법으로 Amazon RDS Optimized Reads를 사용하도록 기존 Amazon RDS 데이터베이스를 전환할 수 있습니다. 지원되는 모든 인스턴스 클래스에서는 Optimized Reads를 기본적으로 사용할 수도 있습니다. db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn, X2iedn 인스턴스에서 워크로드를 실행하고 있다면 이미 Optimized Reads의 이점을 누리고 있는 것입니다.

복잡한 데이터 파이프라인을 구축하고 관리할 필요가 없도록 하려면 Amazon Redshift와 Amazon RDS for MySQL 제로 ETL 통합을 사용해야 합니다. 데이터가 Amazon Redshift에 저장되면 RDS for MySQL에서 트랜잭션 데이터에 대해 거의 실시간으로 분석 및 기계 학습(ML) 기능에 액세스할 수 있습니다.

Amazon Redshift와 RDS for MySQL 제로 ETL 통합은 지원되는 AWS 리전의 MySQL 버전 8.0.32 이상에서 사용할 수 있습니다.

Amazon Redshift와 RDS for MySQL 제로 ETL 통합을 사용하면 페타바이트 규모의 트랜잭션 데이터에 대한 거의 실시간 분석 및 기계 학습(ML)이 가능하고 복잡한 데이터 파이프라인을 구축하고 관리할 필요가 없습니다. 데이터가 RDS for MySQL에 기록된 후 몇 초 내에 Amazon Redshift에 복제됩니다. RDS for MySQL에서 Amazon Redshift로 여러 데이터베이스 및 테이블의 데이터를 통합할 수 있습니다. 분석 요구 사항을 기반으로 특정 데이터베이스 및 테이블의 데이터를 필터링하면 데이터를 선택적으로 Amazon Redshift로 가져올 수 있습니다.

제로 ETL 통합을 생성하고 그 일부로 생성되는 변경 데이터를 처리하는 데 사용한 RDS for MySQL 및 Amazon Redshift 리소스에 대한 요금이 부과됩니다. 이러한 리소스에는 Amazon Redshift 데이터 웨어하우스를 시드 및 재동기화하기 위한 Amazon RDS 스냅샷 내보내기 비용, 소스에서 타겟으로 데이터 변경 사항을 지속적으로 복제하기 위한 변경 데이터 캡처(CDC) 데이터 전송 비용, 변경 데이터를 처리하는 데 사용되는 일반 RDS I/O 및 스토리지, 복제된 데이터에 대한 일반 Amazon Redshift 스토리지 및 컴퓨팅 비용이 포함됩니다. 자세한 내용은 RDS for MySQL 요금 페이지를 참조하세요.

예를 들어, RDS for MySQL 8.0.32 데이터베이스와 미국 동부(버지니아 북부) 리전에서 실행 중인 Amazon Redshift 데이터 웨어하우스가 있습니다. 이 RDS for MySQL DB 인스턴스는 현재 50GB의 범용 SSD(gp3) 스토리지 용량을 사용하며, 여기에는 프로비저닝된 기준 IOPS가 포함되고, 자동 백업이 활성화되어 있으며, MySQL 바이너리 로깅이 설정되어 있습니다.

RDS for MySQL DB 인스턴스를 위해 Amazon Redshift와 제로 ETL 통합을 생성하면 데이터 스냅샷(50GB)이 생성되어 Amazon Redshift 데이터 웨어하우스를 시드하기 위해 내보내집니다. 다음 날 RDS for MySQL DB 인스턴스에 있는 테이블의 기본 키를 변경하면 Amazon Redshift로 내보낸 스냅샷이 재동기화됩니다. 30일 동안 데이터베이스는 5GB의 데이터 변경을 처리합니다.

이 예시에서는 30일 동안 미국 동부(버지니아 북부)에서 Amazon Redshift와 RDS for MySQL 제로 ETL 통합을 사용하는 데 드는 비용은 50GB x (0.10 USD/GB) 초기 보내보기 비용에 50GB x (0.10 USD/GB) 재동기화 비용과 5GB x (2.00 USD/GB) CDC 데이터 전송을 더한 금액으로 총 20.00 USD입니다. 제로 ETL 통합에 드는 이러한 비용 외에도 Amazon RDS 및 Amazon Redshift를 정상적으로 사용하여 복제된 데이터를 처리하는 데 드는 비용(예: I/O, 스토리지, 컴퓨팅 비용)도 부담해야 합니다.

예. 기본 인스턴스의 리소스 소비를 줄이기 위해 Amazon Redshift와의 제로 ETL 통합을 위한 소스 Amazon RDS 인스턴스로 Amazon RDS 읽기 전용 복제본을 사용할 수 있습니다.

예. AWS CloudFormation을 사용하여 Amazon Redshift와의 RDS for MySQL 제로 ETL 통합에 필요한 리소스의 구성 및 배포를 관리하고 자동화할 수 있습니다. 자세한 내용은 AWS CloudFormation 사용자 가이드를 참조하세요.

Amazon Redshift로의 RDS for MySQL 제로 ETL 통합은 트랜잭션을 원자적으로 복제하여 소스 RDS for MySQL 데이터베이스와 대상 Amazon Redshift 클러스터 간의 데이터 일관성을 보장합니다.

이 통합에서 트랜잭션의 원자성에 대한 몇 가지 핵심 사항은 다음과 같습니다.

• RDS for MySQL에서 커밋된 트랜잭션만 Amazon Redshift에 복제됩니다. 커밋되지 않았거나 롤백된 트랜잭션은 해당되지 않습니다.
• 통합에서는 2단계 커밋 프로세스를 사용하여 각 트랜잭션을 Amazon Redshift에 원자적으로 적용합니다. 트랜잭션의 모든 데이터 변경 사항이 적용되거나, 오류가 발생하는 경우 아무 것도 적용되지 않습니다.
• 소스와 대상 간에 트랜잭션 일관성이 유지됩니다. 복제 후에는 특정 트랜잭션의 데이터가 RDS for MySQL과 Amazon Redshift에서 모두 일관되게 유지됩니다.
• DDL 또는 DML을 통한 스키마 변경도 무결성을 유지하기 위해 원자적으로 적용됩니다.
• 트랜잭션이 원자적으로 적용되면 데이터베이스 간에 부분 트랜잭션이나 일관되지 않은 데이터 상태가 발생하지 않습니다.

Amazon Redshift와의 RDS for MySQL 제로 ETL 통합은 소스 RDS for MySQL 데이터베이스와 대상 Amazon Redshift 클러스터 간의 완전한 트랜잭션 일관성을 유지합니다.

다음은 스키마 변경이 처리되는 방법에 대한 몇 가지 핵심 사항입니다.

• CREATE TABLE, ALTER TABLE, DROP TABLE 등과 같은 DDL 문은 RDS for MySQL에서 Amazon Redshift로 자동으로 복제됩니다.
• 통합하면 복제된 스키마 변경에 맞게 Amazon Redshift 테이블이 확인되고 조정됩니다. 예를 들어 RDS for MySQL에 열을 추가하면 Amazon Redshift에 해당 열이 추가됩니다.
• 복제 및 스키마 동기화는 소스 데이터베이스와 대상 데이터베이스 간의 지연을 최소화하면서 거의 실시간으로 자동으로 수행됩니다.
• DML 변경이 DDL 변경과 동시에 발생하는 경우에도 스키마 일관성이 유지됩니다.