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

Amazon RDS의 MySQL

Amazon RDS는 여러 MySQL 버전을 실행하는 DB 인스턴스를 지원합니다. 사용자는 먼저 Amazon RDS 관리 도구 또는 인터페이스를 사용하여 Amazon RDS MySQL DB 인스턴스를 생성합니다. 그런 다음 DB 인스턴스 크기 조정, DB 인스턴스에 대한 연결 인증, 백업 또는 스냅샷 생성 및 복원, 다중 AZ 보조 생성, 읽기 전용 복제본 생성 및 DB 인스턴스의 성능 모니터링을 사용할 수 있습니다. 표준 MySQL 유틸리티 및 애플리케이션을 사용하여 DB 인스턴스에서 데이터를 저장하고 데이터에 액세스할 수 있습니다.

MySQL용 Amazon RDS는 다수의 산업 표준을 준수합니다. 예를 들면, MySQL 데이터베이스용 Amazon RDS를 사용하여 HIPAA 준수 애플리케이션을 구축하고 AWS와 체결한 이행필 비즈니스 제휴 계약(BAA)에 따라 보호 대상 건강 정보(PHI)를 비롯한 의료 관련 정보를 저장할 수 있습니다. 또한 MySQL용 Amazon RDS는 FedRAMP(연방 위험 및 인증 관리 프로그램) 보안 요건을 충족하며 FedRAMP 공동 승인 위원회(JAB)로부터 AWS GovCloud (US) 리전 내에서 행사할 수 있는 FedRAMP HIGH Baseline 수준의 잠정적 운영 권한(P-ATO)을 취득했습니다. 지원되는 규정 준수 표준에 대한 자세한 정보는 AWS 클라우드 규정 준수을(를) 참조하십시오.

다음은 Amazon RDS MySQL DB 인스턴스로 수행할 수 있는 일반적인 관리 작업과 각 작업에 해당하는 문서 링크입니다.

작업 영역 관련 문서

[Amazon Relational Database Service(Amazon RDS) 이해]

DB 인스턴스, 리전, 가용 영역, 보안 그룹, 파라미터 그룹, 옵션 그룹 등 Amazon RDS의 핵심 구성 요소를 이해합니다.

Amazon Relational Database Service(Amazon RDS)란 무엇입니까?

새 RDS MySQL DB 인스턴스 계획

모범 사례에 따라 MySQL 버전 업그레이드, 스토리지 엔진, 보안 및 Amazon RDS에서 지원되는 기타 기능을 포함해 새 RDS MySQL DB 인스턴스를 설계합니다.

Amazon RDS의 MySQL 계획 정보

[처음 사용 시 Amazon RDS 설정]

Amazon Web Services(AWS)에서 MySQL DB 인스턴스를 생성할 수 있도록 Amazon RDS를 설정합니다.

Amazon RDS 설정

[Amazon RDS DB 인스턴스 이해]

AWS에서 실행되는 가상 MySQL 서버 인스턴스를 생성합니다. DB 인스턴스는 Amazon RDS의 기본 구성 요소이므로 해당 원칙을 이해하는 것이 좋습니다.

Amazon RDS DB 인스턴스

프로덕션용 DB 인스턴스 만들기

프로덕션 목적으로 DB 인스턴스를 생성합니다. 인스턴스 생성 과정에서는 적절한 처리 기능과 메모리 용량을 가진 DB 인스턴스 클래스를 선택하고 데이터베이스 사용 방법에 맞는 스토리지 유형을 선택합니다.

DB 인스턴스 클래스

Amazon RDS 스토리지 유형

MySQL 데이터베이스 엔진 기반 DB 인스턴스 생성

DB 인스턴스의 보안 관리

기본적으로, DB 인스턴스와 함께 인스턴스에 대한 액세스를 막는 방화벽도 생성됩니다. 따라서 DB 인스턴스에 액세스하기 위한 알맞은 IP 주소와 네트워크 구성으로 보안 그룹을 만들어야 합니다. RDS 리소스를 관리할 수 있는 사용자를 결정하는 권한을 배정하는 데 AWS Identity and Access Management(IAM) 정책을 사용할 수도 있습니다.

Amazon RDS 보안

Amazon RDS 리소스에 대한 액세스 권한 관리 개요

Amazon RDS 보안 그룹

EC2-VPC 또는 EC2-Classic 플랫폼을 사용 중인지 확인

DB 인스턴스에 연결

MySQL 명령줄 유틸리티 또는 MySQL Workbench와 같은 표준 SQL 클라이언트 애플리케이션을 사용하여 DB 인스턴스에 연결합니다.

MySQL 데이터베이스 엔진 기반 DB 인스턴스에 연결하기

프로덕션 DB 인스턴스에 대해 고가용성 구성

다른 가용 영역의 동기식 예비 복제본, 자동 장애 조치, 다중 AZ 배포를 통한 DB 인스턴스의 내결함성, 읽기 전용 복제본 등을 통해 고가용성을 제공합니다.

고가용성(다중 AZ)

[Amazon Virtual Private Cloud에 DB 인스턴스 구성]

Amazon VPC 서비스에서 Virtual Private Cloud(VPC)를 구성합니다. Amazon VPC는 AWS 내 다른 가상 네트워크에서 논리적으로 격리된 가상 네트워크입니다.

EC2-VPC 또는 EC2-Classic 플랫폼을 사용 중인지 확인

VPC에서 Amazon RDS DB 인스턴스를 사용한 작업

특정 MySQL 데이터베이스 파라미터 및 기능 구성

많은 DB 인스턴스와 연결 가능한 파라미터 그룹을 사용하여 특정 MySQL 데이터베이스 파라미터를 구성합니다. 많은 DB 인스턴스와 연결 가능한 옵션 그룹을 사용하여 특정 MySQL 데이터베이스 기능을 구성할 수도 있습니다.

DB 파라미터 그룹 작업

옵션 그룹 작업

부록: MySQL 데이터베이스 엔진을 위한 옵션

MySQL 데이터베이스 엔진 기반 DB 인스턴스의 변경

추가 스토리지를 더하거나 DB 인스턴스 클래스를 변경하는 것과 같은 작업을 완수하기 위해 DB 인스턴스의 설정을 변경합니다.

MySQL 데이터베이스 엔진 기반 DB 인스턴스의 변경

Amazon RDS DB 인스턴스 수정 및 Apply Immediately 파라미터 사용

데이터베이스 백업 및 복원 구성

자동 백업을 수행하도록 DB 인스턴스를 구성합니다. 또한 전체 백업 파일을 사용하여 데이터베이스를 수동으로 백업 및 복원할 수도 있습니다.

백업 작업

Amazon RDS DB 인스턴스 백업 및 복원

데이터 가져오기 및 내보내기

다른 RDS MySQL DB 인스턴스, Amazon RDS 외부에서 실행 중인 MySQL 인스턴스 및 기타 유형의 데이터 소스에서 데이터를 가져오고, Amazon RDS 외부에서 실행 중인 MySQL 인스턴스로 데이터를 내보냅니다.

MySQL DB 인스턴스에서 데이터 가져오기 및 내보내기

MySQL DB 인스턴스 모니터링

Amazon CloudWatch RDS 측정치, 이벤트 및 향상된 모니터링 기능을 통해 RDS MySQL DB 인스턴스를 모니터링합니다. RDS MySQL DB 인스턴스에 대한 로그 파일을 봅니다.

Amazon RDS 모니터링

DB 인스턴스 측정치 보기

Amazon RDS 이벤트 보기

Amazon RDS 데이터베이스 로그 파일

MySQL 데이터베이스 로그 파일

데이터 복제

필요할 경우 로드 밸런싱, 재해 복구, 읽기 중심의 데이터베이스 워크로드 처리 등을 위해(예: 분석 및 보고를 위해) 다른 AWS 리전에서 MySQL 읽기 전용 복제본을 만듭니다.

PostgreSQL, MySQL 및 MariaDB 읽기 전용 복제본 작업

Amazon RDS 외부에서 실행 중인 MySQL 또는 MariaDB 인스턴스를 사용한 복제

또한 Amazon RDS MySQL DB 인스턴스 작업에 대한 유용한 정보가 포함된 여러 부록도 있습니다.

Amazon RDS의 MySQL 계획 정보

Amazon RDS의 MySQL 버전

MySQL의 경우, 버전 번호는 버전 = X.Y.Z로 구성됩니다. Amazon RDS 용어에서 X.Y는 메이저 버전을 나타내고 Z는 마이너 버전 번호를 나타냅니다. Amazon RDS 구현을 위해서, 메이저 버전 번호가 변경될 경우(예: 버전 5.6에서 5.7으로)— 이를 메이저 버전 변경으로 간주합니다. 단지 마이너 버전 번호가 변경된 경우(예: 버전 5.6.22에서 5.6.23으로)에는— 마이너 버전 변경으로 간주합니다.

Amazon RDS는 현재 MySQL 메이저 버전 5.5, 5.6 및 5.7을 지원합니다. MySQL 마이너 버전 지원은 AWS 리전에 따라 달라집니다. 다음 표를 사용하여 각 AWS 리전에서 어떤 MySQL 마이너 버전이 지원되는지 확인하십시오.

AWS 리전 지원되는 MySQL 5.5 마이너 버전 지원되는 MySQL 5.6 마이너 버전 지원되는 MySQL 5.7 마이너 버전
미국 동부(버지니아 북부) 지역 (us-east-1) 5.5.46, 5.5.53 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
미국 동부(오하이오) 리전 (us-east-2) 5.5.46, 5.5.53 5.6.29, 5.6.34 5.7.11, 5.7.16
미국 서부(캘리포니아 북부) 리전 (us-west-1) 5.5.46, 5.5.53 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
미국 서부(오레곤) 지역 (us-west-2) 5.5.46, 5.5.53 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
아시아 태평양(뭄바이) 리전(ap-south-1) 5.5.46, 5.5.53 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
아시아 태평양(서울) 리전 (ap-northeast-2) 5.5.46, 5.5.53 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
아시아 태평양(싱가포르) 리전 (ap-southeast-1) 5.5.46, 5.5.53 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
아시아 태평양(시드니) 리전 (ap-southeast-2) 5.5.46, 5.5.53 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
아시아 태평양(도쿄) 리전 (ap-northeast-1) 5.5.46, 5.5.53 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
캐나다(중부) 리전 (ca-central-1) 5.5.46, 5.5.53 5.6.29, 5.6.34 5.7.11, 5.7.16
EU(프랑크푸르트) 리전 (eu-central-1) 5.5.46, 5.5.53 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
EU(아일랜드) 지역 (eu-west-1) 5.5.46, 5.5.53 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16
EU(런던) 리전 (eu-west-2) 5.5.46, 5.5.53 5.6.29, 5.6.34 5.7.11, 5.7.16
남아메리카(상파울루) 리전 (sa-east-1) 5.5.46, 5.5.53 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23, 5.6.27, 5.6.29, 5.6.34 5.7.10, 5.7.11, 5.7.16

추후 Amazon RDS를 위한 추가 MySQL 버전을 지원할 계획입니다. 지정된 기간 동안 지원되는 새 버전 릴리스의 수는 MySQL 버전 릴리스의 빈도 및 콘텐츠, 그리고 데이터베이스 엔지니어링 팀에 의한 릴리스의 철저한 베팅 결과에 따라 달라집니다. 그러나 일반적인 지침으로 당사는 정식 출시 후 3~5개월 이내에 새로운 MySQL 버전을 지원할 수 있도록 노력하고 있습니다.

새 DB 인스턴스를 생성할 때는 현재 지원되는 모든 MySQL 버전을 지정할 수 있습니다. MySQL 5.7, 5.6 또는 5.5 메이저 버전과 지정된 메이저 버전에 대해 지원되는 모든 마이너 버전을 지정할 수 있습니다. 버전이 지정되지 않은 경우, Amazon RDS는 지원되는 버전(보통 가장 최신 버전)을 기본값으로 설정합니다. 메이저 버전(예: MySQL 5.7)이 지정되었지만 마이너 버전이 지정되지 않은 경우, Amazon RDS는 고객이 지정한 메이저 버전의 최근 릴리스를 기본값으로 설정합니다. 지원되는 버전 목록과 새로 만든 DB 인스턴스의 기본값을 보려면 DescribeDBEngineVersions API 작업을 사용합니다.

Amazon RDS를 통해 사용자는 MySQL 인스턴스를 Amazon RDS가 지원하는 새 버전으로 언제 업그레이드할 지를 제어합니다. 특정 MySQL 버전과의 호환성을 유지하고, 프로덕션 환경에 배포하기 전에 애플리케이션으로 새 버전을 테스트하고, 가장 원하는 일정에 맞춰 버전 업그레이드를 수행할 수 있습니다.

사용자가 달리 지정하지 않는 한 Amazon RDS에서 새로운 MySQL 마이너 버전을 지원할 때 DB 인스턴스가 새 버전으로 자동 업그레이드됩니다. 이 패치는 예정된 유지 관리 기간 동안 이루어지며, Amazon RDS 커뮤니티 포럼에 미리 공지됩니다. 자동 버전 업그레이드를 끄려면 AutoMinorVersionUpgrade 파라미터를 "false"로 설정합니다.

자동으로 예약된 업그레이드를 사용하지 않기로 선택한 경우, 사용자는 메이저 버전 업데이트를 위해 선택한 것과 동일한 절차에 따라 지원되는 마이너 버전 릴리스로 수동으로 업그레이드할 수 있습니다. 자세한 내용은 DB 인스턴스 및 DB 클러스터 유지 관리 및 업그레이드을(를) 참조하십시오.

Amazon RDS는 현재 MySQL 버전 5.5에서 버전 5.6으로, 그리고 MySQL 버전 5.6에서 버전 5.7로의 메이저 버전 업그레이드를 지원합니다. 메이저 버전 업그레이드에 약간의 호환성 위험이 수반되므로 업그레이드가 자동으로 이루어지지 않습니다. 즉, DB 인스턴스 수정을 요청해야 합니다. 프로덕션 인스턴스를 업그레이드하기 전에 모든 업그레이드를 철저하게 테스트해야 합니다. DB 인스턴스 업그레이드에 대한 자세한 내용은 DB 인스턴스 및 DB 클러스터 유지 관리 및 업그레이드을(를) 참조하십시오.

기존 DB 인스턴스의 DB 스냅샷을 만들고 DB 스냅샷에서 복구해 새 DB 인스턴스를 만든 다음 새로운 DB 인스턴스에 대한 버전 업그레이드를 시작함으로써, 업그레이드하기 전에 새 버전과 비교하여 DB 인스턴스를 테스트할 수 있습니다. 그런 다음 원래의 DB 인스턴스에 대한 업그레이드 여부를 결정하기 전에 DB 인스턴스의 업그레이드된 복제본에서 안전하게 실험을 진행할 수 있습니다.

MySQL에 대한 Amazon RDS 운영 중단 정책에는 다음이 포함됩니다.

  • MySQL 버전 릴리스(예: MySQL 5.5)는 Amazon RDS에서 처음으로 지원된 후 3년 동안 지원됩니다.

  • 마이너 MySQL 버전 릴리스(예: MySQL 5.5.46)는 Amazon RDS에서 처음으로 지원된 후 최소 1년 동안 지원됩니다.

  • MySQL 메이저 또는 마이너 버전이 "운영 중단"된 후, 예정된 유지 관리 기간 동안 자동 업그레이드가 적용되기 전에 지원되는 버전으로 업그레이드를 시작할 수 있도록 3개월의 유예 기간이 제공됩니다.

MySQL 과 함께 memcached 옵션 사용

대부분의 Amazon RDS DB 엔진은 DB 인스턴스 관련 추가 기능을 선택할 수 있도록 옵션 그룹을 지원합니다. MySQL 5.6 이상의 DB 인스턴스는 단순 키 기반 캐시인 memcached 옵션을 지원합니다. memcached 옵션에 대한 자세한 내용은 부록: MySQL 데이터베이스 엔진을 위한 옵션을(를) 참조하십시오. 옵션 그룹 작업에 대한 자세한 내용은 옵션 그룹 작업을(를) 참조하십시오.

Amazon RDS 지원 스토리지 엔진

MySQL은 다양한 기능으로 여러 스토리지 엔진을 지원하지만, 모든 기능이 복구와 데이터 내구성에 최적화되어 있지는 않습니다. Amazon RDS에서는 MySQL DB 인스턴스용 InnoDB 스토리지 엔진을 완벽히 지원합니다. 지정 시간 복원 및 스냅샷 복원과 같은 Amazon RDS 기능은 복구 가능 스토리지 엔진이 필요하며 InnoDB 스토리지 엔진에 대해서만 지원됩니다. InnoDB memcached 인터페이스를 사용하려면 MySQL 5.6 이상의 인스턴스를 실행하고 있어야 합니다. 자세한 내용은 MySQL memcached 지원을(를) 참조하십시오.

MySQL을 위한 외부 스토리지 엔진은 현재 Amazon RDS에서 지원되지 않습니다.

MyISAM 스토리지 엔진에서는 안정된 중단 복구가 어렵기 때문에 복구 후에 MySQL을 다시 시작했을 때, 지정 시간 복원 또는 스냅샷 복원 기능이 의도한 대로 작동하지 않아 데이터가 손실 또는 손상될 수 있습니다. 그래도 Amazon RDS에서 MyISAM을 사용하기로 선택한 경우, 일부 조건에서는 스냅샷이 유용할 수 있습니다.

기존의 MyISAM 테이블을 InnoDB 테이블로 변환하려면 alter table 명령(예: alter table TABLE_NAME engine=innodb;)을 사용하면 됩니다. MyISAM과 InnoDB는 각기 다른 장점과 단점을 갖고 있으므로 전환하기 전에 전환이 현재 애플리케이션에 미치는 영향을 충분히 평가해야 합니다.

MySQL 5.1은 이제 Amazon RDS에서 지원하지 않습니다. 그러나 기존의 MySQL 5.1 스냅샷을 복원할 수는 있습니다. MySQL 5.1 스냅샷을 복원할 경우 인스턴스가 자동으로 MySQL 5.5로 업그레이드됩니다.

Amazon RDS 및 MySQL 보안

Amazon RDS MySQL DB 인스턴스용 보안은 세 가지 수준에서 관리됩니다.

  • AWS Identity and Access Management은 누가 DB 인스턴스에 대한 Amazon RDS 관리 작업을 수행할 수 있는 지 제어합니다. IAM 자격 증명을 사용하여 AWS에 연결할 때, IAM 계정은 Amazon RDS 관리 작업을 수행하는 데 필요한 권한을 부여하는 IAM 정책을 보유하고 있어야 합니다. 자세한 내용은 Amazon RDS에 대한 인증 및 액세스 제어을(를) 참조하십시오.

  • DB 인스턴스를 생성할 때는 VPC 보안 그룹 또는 DB 보안 그룹을 사용하여 어떤 디바이스 및 Amazon EC2 인스턴스가 DB 인스턴스의 엔드포인트 및 포트에 대한 연결을 열 수 있는 지를 제어합니다. 이러한 연결은 SSL을 통해 이루어질 수 있습니다. 또한 회사의 방화벽 규칙을 통해 회사에서 실행하는 디바이스가 DB 인스턴스에 대한 연결을 열 수 있는지를 제어할 수 있습니다.

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

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

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

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

  • alter

  • alter routine

  • create

  • create routine

  • create temporary tables

  • create user

  • create view

  • delete

  • drop

  • event

  • execute

  • grant option

  • index

  • insert

  • lock tables

  • process

  • references

  • replication client

  • replication slave (MySQL 5.6 and later)

  • select

  • show databases

  • show view

  • trigger

  • update

참고

DB 인스턴스에서 마스터 사용자를 삭제할 수 있지만, 권장하지는 않습니다. 마스터 사용자를 다시 생성하려면 ModifyDBInstance RDS API 작업 또는 modify-db-instance AWS CLI 도구를 사용하고 적절한 파라미터와 함께 새로운 마스터 사용자 암호를 지정하십시오. 마스터 사용자가 인스턴스에 존재하지 않는 경우 마스터 사용자가 지정된 암호와 함께 생성됩니다.

각 DB 인스턴스에 관리 서비스를 제공하기 위해 DB 인스턴스가 생성될 때 rdsadmin 사용자가 만들어집니다. rdsadmin 계정에 대한 암호를 삭제하거나 이름 바꾸기를 하거나 변경하려고 시도하면 또는 권한을 변경하려고 시도하면 오류가 발생합니다.

DB 인스턴스의 관리를 허용하기 위해 표준 killkill_query 명령이 제한되었습니다. DB 인스턴스에서 사용자 세션 또는 쿼리를 종료할 수 있도록 Amazon RDS 명령 rds_killrds_kill_query가 제공됩니다.

MySQL DB 인스턴스와 함께 SSL 사용

Amazon RDS는 MySQL 데이터베이스 엔진을 실행하는 DB 인스턴스와의 SSL 연결을 지원합니다.

참고

Amazon Aurora는 MySQL과 호환됩니다. 단, Amazon Aurora DB 클러스터에 연결할 때는 다른 SSL 인증서를 사용합니다. SSL을 사용한 Amazon Aurora 연결에 대한 자세한 내용은 SSL을 이용한 Aurora 데이터 보안을(를) 참조하십시오.

Amazon RDS가 SSL 인증서를 생성한 후 Amazon RDS가 인스턴스를 프로비저닝할 때 DB 인스턴스에 인증서를 설치합니다. 인증 기관이 서명하는 SSL 인증서에는 스푸핑 공격으로부터 보호해주는 SSL 인증서를 위한 일반 이름(CN)으로 DB 인스턴스 엔드포인트가 포함되어 있습니다. 퍼블릭 키는 https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem에 저장되어 있습니다.

Amazon RDS에서 생성하는 SSL 인증서는 신뢰할 수 있는 루트 개체이므로 대부분의 경우에 작동하지만 애플리케이션에서 인증서 체인을 수락하지 않을 경우 실패할 수 있습니다. 애플리케이션에서 인증서 체인을 허용하지 않는 경우 중간 인증서를 사용하여 자신의 리전에 연결해야 할 수도 있습니다. 예를 들어 SSL을 사용하여 AWS GovCloud (US) 리전에 연결하려면 중간 인증서를 사용해야 합니다. 다운로드할 수 있는 리전별 중간 인증서 목록은 중간 인증서을(를) 참조하십시오.

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

Copy
mysql -h myinstance.c9akciq32.rds-us-east-1.amazonaws.com --ssl-ca=[full path]rds-combined-ca-bundle.pem --ssl-verify-server-cert

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

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

참고

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

MySQL DB 인스턴스의 현지 시간대

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

DB 인스턴스의 현지 시간대를 설정하려면 DB 인스턴스의 파라미터 그룹에서 time_zone 파라미터를 이 단원의 뒤에 나오는 지원되는 값 중 하나로 설정합니다. 파라미터 그룹에 대한 time_zone 파라미터를 설정하면 해당 파라미터 그룹을 사용 중인 모든 DB 인스턴스와 읽기 전용 복제본이 새로운 현지 시간대를 사용하도록 변경됩니다. 파라미터 그룹에서 파라미터를 설정하는 방법에 대한 자세한 내용은 DB 파라미터 그룹 작업을(를) 참조하십시오.

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

DB 인스턴스와 하나 이상의 읽기 전용 복제본에 대해 다른 현지 시간대를 설정할 수 있습니다. 이렇게 하려면 DB 인스턴스와 복제본에 대해 서로 다른 파라미터 그룹을 사용하고 각 파라미터 그룹에서 time_zone 파라미터를 다른 현지 시간대로 설정합니다.

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

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

현지 시간대는 MySQL 버전 5.5, 5.6 및 5.7에서만 지원됩니다.

현지 시간대를 다음 값 중 하나로 설정할 수 있습니다.

Africa/Cairo

Asia/Bangkok

Australia/Darwin

Africa/Casablanca

Asia/Beirut

Australia/Hobart

Africa/Harare

Asia/Calcutta

Australia/Perth

Africa/Monrovia

Asia/Damascus

Australia/Sydney

Africa/Nairobi

Asia/Dhaka

Brazil/East

Africa/Tripoli

Asia/Irkutsk

Canada/Newfoundland

Africa/Windhoek

Asia/Jerusalem

Canada/Saskatchewan

America/Araguaina

Asia/Kabul

Europe/Amsterdam

America/Asuncion

Asia/Karachi

Europe/Athens

America/Bogota

Asia/Kathmandu

Europe/Dublin

America/Caracas

Asia/Krasnoyarsk

Europe/Helsinki

America/Chihuahua

Asia/Magadan

Europe/Istanbul

America/Cuiaba

Asia/Muscat

Europe/Kaliningrad

America/Denver

Asia/Novosibirsk

Europe/Moscow

America/Fortaleza

Asia/Riyadh

Europe/Paris

America/Guatemala

Asia/Seoul

Europe/Prague

America/Halifax

Asia/Shanghai

Europe/Sarajevo

America/Manaus

Asia/Singapore

Pacific/Auckland

America/Matamoros

Asia/Taipei

Pacific/Fiji

America/Monterrey

Asia/Tehran

Pacific/Guam

America/Montevideo

Asia/Tokyo

Pacific/Honolulu

America/Phoenix

Asia/Ulaanbaatar

Pacific/Samoa

America/Santiago

Asia/Vladivostok

US/Alaska

America/Tijuana

Asia/Yakutsk

US/Central

Asia/Amman

Asia/Yerevan

US/Eastern

Asia/Ashgabat

Atlantic/Azores

US/East-Indiana

Asia/Baghdad

Australia/Adelaide

US/Pacific

Asia/Baku

Australia/Brisbane

UTC

InnoDB 캐시 워밍

InnoDB 캐시 워밍은 DB 인스턴스가 종료될 때 버퍼 풀의 현재 상태를 저장한 다음 DB 인스턴스가 시작될 때 저장된 정보에서 버퍼 풀을 다시 로드하여 MySQL DB 인스턴스의 성능 향상을 제공할 수 있습니다. 이렇게 하면 보통 데이터베이스 사용에서 "준비"까지의 버퍼 풀에 대한 필요를 무시하고, 대신 알려진 공용 쿼리에 대한 페이지와 함께 버퍼 풀을 미리 로드합니다. 저장된 버퍼 풀 정보를 저장하는 파일은 페이지 자체가 아니라 단지 버퍼 풀에 있는 페이지에 대한 메타데이터만 저장합니다. 따라서 파일은 많은 저장 공간을 요구하지 않습니다. 파일 크기는 캐시 크기의 약 0.2%입니다. 예를 들면, 64GB의 경우 캐시 워밍 파일 크기는 128MB입니다. InnoDB 캐시 워밍에 대한 자세한 내용은 MySQL 설명서에서 버퍼 풀 상태 저장 및 복원하기 단원을 참조하십시오.

Amazon RDS의 MySQL은 MySQL 버전 5.6 이상에 대한 InnoDB 캐시 워밍을 지원합니다. InnoDB 캐시 워밍을 활성화하려면 innodb_buffer_pool_dump_at_shutdowninnodb_buffer_pool_load_at_startup 파라미터를 DB 인스턴스용 파라미터 그룹에서 1로 설정합니다. 파라미터 그룹에서 이들 파라미터 값을 변경하면 파라미터 그룹을 사용하는 모든 MySQL DB 인스턴스가 영향을 받습니다. 특정 MySQL DB 인스턴스에 대한 InnoDB 캐시 워밍을 활성화하려면, 이들 인스턴스에 대한 새 파라미터 그룹을 생성해야 할 수도 있습니다. 파라미터 그룹에 대한 자세한 내용은 DB 파라미터 그룹 작업을(를) 참조하십시오.

InnoDB 캐시 워밍은 주로 표준 스토리지를 사용하는 DB 인스턴스를 위해 성능 혜택을 제공합니다. PIOPS 스토리지를 사용하는 경우에는 통상적으로 중요한 성능 혜택이 제공되지 않습니다.

중요

MySQL DB 인스턴스가 정상적으로 종료되지 않는 경우(예: 장애 조치 도중), 버퍼 풀 상태가 디스크에 저장되지 않습니다. 이 경우 MySQL은 DB 인스턴스가 다시 시작될 때 이용 가능한 모든 버퍼 풀 파일을 로드합니다. 어떤 손상도 발생하지 않지만, 복원된 버퍼 풀은 대부분의 경우 다시 시작하기 이전의 버퍼 풀 최신 상태를 반영하지 못할 수도 있습니다. 시작 시 InnoDB 캐시를 워밍업하기 위해 버퍼 풀의 최신 상태를 이용할 수 있게 하려면, "요청 시" 버퍼 풀을 주기적으로 덤프하는 것이 좋습니다. DB 인스턴스가 MySQL 버전 5.6.19 이상을 실행하고 있을 경우 요청 시 버퍼 풀을 덤프하거나 로드할 수 있습니다.

이벤트를 생성하여 버퍼 풀을 자동으로 그리고 정기적으로 덤프할 수 있습니다. 예를 들면, 다음 문은 매 시간마다 버퍼 풀을 덤프하는 이름이 periodic_buffer_pool_dump인 이벤트를 생성합니다.

Copy
CREATE EVENT periodic_buffer_pool_dump ON SCHEDULE EVERY 1 HOUR DO CALL mysql.rds_innodb_buffer_pool_dump_now();

MySQL 이벤트에 대한 자세한 내용은 MySQL 설명서의 이벤트 구문을(를) 참조하십시오.

요청 시 버퍼 풀 덤핑 및 로딩

MySQL 버전 5.6.19 이상의 경우, "요청 시" InnoDB 캐시를 저장 및 로드할 수 있습니다.

Amazon RDS가 지원하지 않는 MySQL 기능

Amazon RDS는 현재 다음과 같은 MySQL 기능은 지원하지 않습니다.

  • 전역 트랜잭션 ID

  • 전송 가능한 테이블스페이스

  • 인증 플러그인

  • 암호 보안 수준 플러그인

  • 복제 필터

  • 반동기식 복제

관리되는 서비스 환경을 제공하기 위해 Amazon RDS는 DB 인스턴스에 대해 셸 액세스를 제공하지 않으며, 고급 권한을 필요로 하는 특정 시스템 절차와 테이블에 대한 액세스를 제한합니다. Amazon RDS는 모든 표준 SQL 클라이언트 애플리케이션을 사용하여 DB 인스턴스의 데이터베이스에 대한 액세스를 지원합니다. Amazon RDS는 Telnet, Secure Shell (SSH), 또는 Windows 원격 데스크톱 연결을 통해 DB 인스턴스에 직접 호스트 액세스하는 것을 허용하지 않습니다. DB 인스턴스를 생성할 때 사용자는 해당 인스턴스의 모든 데이터베이스에 대한 db_owner 역할을 할당받게 되며, 백업을 위해 사용된 권한을 제외한 모든 데이터베이스 수준의 권한을 갖게 됩니다(Amazon RDS가 사용자를 위해 백업을 관리함).

알려진 문제 및 제한

알려진 문제 및 제한은 다음과 같습니다.

일관되지 않은 InnoDB 버퍼 풀 크기

MySQL 5.7에는 현재 InnoDB 버퍼 풀 크기가 관리되지 않는 버그가 있습니다. MySQL 5.7에서 innodb_buffer_pool_size 파라미터 값을 InnoDB 버퍼 풀 크기를 너무 많이 늘려 너무 많은 메모리를 소모하도록 하는 큰 값으로 조정할 수 있습니다. 이에 따라 MySQL 데이터베이스 엔진이 실행을 중단하거나 MySQL 데이터베이스 엔진이 시작하지 못할 수 있습니다. 이 문제는 사용 가능한 메모리가 적은 DB 인스턴스 클래스 문제보다 더 일반적으로 발생합니다.

이 문제를 해결하려면 innodb_buffer_pool_size 파라미터 값을 innodb_buffer_pool_instances 파라미터 값과 innodb_buffer_pool_chunk_size 파라미터 값의 곱의 배수로 설정해야 합니다. 예를 들어, 다음 예에서와 같이 innodb_buffer_pool_size 파라미터 값을 innodb_buffer_pool_instancesinnodb_buffer_pool_chunk_size 파라미터 값의 곱의 8배로 설정할 수 있습니다.

Copy
innodb_buffer_pool_chunk_size = 536870912 innodb_buffer_pool_instances = 4 innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184

MySQL 5.7 버그에 대한 자세한 내용은 MySQL 문서의 https://bugs.mysql.com/bug.php?id=79379을(를) 참조하십시오.

Memcached 권장 MySQL 버전

memcached 인터페이스는 MySQL 버전 5.6.21b 이상에서만 사용하는 것이 좋습니다. 이는 버전 5.6.21b로 시작하는 MySQL 엔진에 포함된 memcached 인터페이스와 관련된 많은 버그 수정이 있기 때문입니다. 자세한 내용은 MySQL 설명서의 MySQL 5.6.20의 변경 내용(2014-07-31)MySQL 5.6.21의 변경 내용(2014-09-23)을(를) 참조하십시오.

Amazon RDS에서 MySQL과 함께 memcached를 사용하는 것에 대한 자세한 내용은 MySQL memcached 지원을(를) 참조하십시오..

MySQL 버전 5.5.40 비동기식 I/O 비활성화

2014년 4월 23일 이전에 생성된 다음 2014년 10월 17일 이후 MySQL 버전 5.5.40으로 업그레이드된 MySQL DB 인스턴스를 보유하고 있는 경우 I/O 성능 감소를 확인하게 될 수도 있습니다. 이러한 성능 감소는 해당 DB 파라미터 그룹이 innodb_use_native_aio 파라미터를 활성화했음에도 innodb_use_native_aio 파라미터를 비활성화하는 오류로 인해 발생할 수 있습니다.

이 오류를 해결하려면 버전 5.5.40에서 실행되는 MySQL DB 인스턴스를 이러한 동작을 수정해 주는 버전 5.5.40a로 업그레이드하는 것이 좋습니다. 마이너 버전 업그레이드에 대한 자세한 내용은 MySQL DB 엔진 업그레이드을(를) 참조하십시오.

MySQL 비동기식 I/O에 대한 자세한 내용은 MySQL 설명서의 Linux에서의 비동기식 I/O을(를) 참조하십시오.

인덱스 병합 최적화가 잘못된 결과를 반환

인덱스 병합 최적화를 사용하는 쿼리는 MySQL 5.5.37에서 도입한 MySQL 쿼리 최적화 프로그램의 버그로 인해 잘못된 결과를 반환할 수도 있습니다. 복수의 인덱스가 있는 테이블에 대한 쿼리를 생성할 때 최적화 프로그램은 복수의 인덱스에 기반하여 행의 범위를 검사하지만 결과를 올바르게 병합하지는 않습니다. 쿼리 최적화 프로그램 버그에 대한 자세한 내용은 MySQL 버그 데이터베이스의 http://bugs.mysql.com/bug.php?id=72745http://bugs.mysql.com/bug.php?id=68194을(를) 참조하십시오.

예를 들면, 검색 인수가 인덱싱된 열을 참조하는 2개의 인덱스가 있는 테이블에 대한 쿼리를 고려합니다.

Copy
SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

이 경우 검색 엔진이 두 인덱스를 모두 검색합니다. 그러나 버그로 인해 병합 결과가 정확하지 않게 됩니다.

이 문제를 해결하려면 다음 중 한 가지 방법을 시도하면 됩니다.

  • MySQL DB 인스턴스용 DB 파라미터 그룹에서 optimizer_switch 파라미터를 index_merge=off로 설정합니다. DB 파라미터 그룹 파라미터 설정에 대한 자세한 내용은 DB 파라미터 그룹 작업을(를) 참조하십시오.

  • MySQL DB 인스턴스를 MySQL 버전 5.6.19a로 업그레이드합니다. 메이저 버전 업그레이드에 대한 자세한 내용은 DB 인스턴스 및 DB 클러스터 유지 관리 및 업그레이드을(를) 참조하십시오.

  • 인스턴스를 업그레이드하거나 optimizer_switch 파라미터를 변경할 수 없는 경우, 쿼리에 대한 인덱스를 명시적으로 확인하여 버그를 해결할 수 있습니다. 예:

    Copy
    SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

자세한 내용은 인덱스 병합 최적화을(를) 참조하십시오.

MySQL 버전 5.6.21로 업그레이드 후 복제 실패

버전 5.6.4 이전 버전을 실행하는 DB 인스턴스가 있거나 DB 인스턴스를 버전 5.6.4 이전 버전에서 업그레이드하지 않은 경우, MySQL 버전 5.6.21을 실행하는 읽기 복제본을 보유하고 있으면 다음과 같은 오류를 받을 수 있습니다.

Copy
mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail.

MySQL 버전 5.6.4는 datetime, time, 및 timestamp 열에 대한 새로운 날짜와 시간 형식을 채택하여 날짜와 시간 값에 일부 구성 요소를 허용합니다. 마스터와 복제본 간의 날짜 및 시간 형식의 불일치에 의해 오류가 발생하여, 행 기반 로깅이 마스터 DB 인스턴스에서 복제본 DB 인스턴스로 작업을 재생하려고 시도할 때 실패로 끝나게 됩니다. 또한 MySQL 오류 로그에서 많은 관련 행 기반 로깅 메시지(예: Relay_log_info, Rows_log_event, 등)를 볼 수도 있습니다. MySQL의 새로운 날짜 및 시간 형식에 대한 자세한 내용은 MySQL 설명서의 MySQL 5.5에서 5.6으로 업그레이드을(를) 참조하십시오.

이 오류를 해결하려면 다음 중 한 가지 방법을 시도하면 됩니다.

  • 읽기 복제본을 MySQL 버전 5.6.23 이상으로 업그레이드합니다. Amazon RDS에서 MySQL DB 인스턴스를 버전 5.6으로 업그레이드하는 것에 대한 자세한 내용은 데이터베이스 엔진 버전 업그레이드을(를) 참조하십시오.

  • 마스터 DB 인스턴스를 MySQL 버전 5.6.12 이상으로 업그레이드하고 해당 날짜 및 시간 열의 형식을 업데이트합니다. Amazon RDS에서 MySQL DB 인스턴스를 버전 5.6으로 업그레이드하는 것에 대한 자세한 내용은 데이터베이스 엔진 버전 업그레이드을(를) 참조하십시오.

    마스터 DB 인스턴스에서 날짜 및 시간 열을 새 형식으로 업그레이드하려면 ALTER TABLE <table_name> FORCE; 명령을 수행해야 합니다.

    참고

    테이블을 변경하면 테이블이 읽기 전용으로 잠기므로 유지 관리 기간 동안 이 업데이트를 수행하는 것이 좋습니다.

    다음 쿼리를 실행하여 datetime, time 또는 timestamp 유형의 열이 있는 데이터베이스에서 모든 테이블을 찾고 각 테이블에 대한 ALTER TABLE <table_name> FORCE; 명령을 생성할 수 있습니다.

    Copy
    SELECT DISTINCT CONCAT('ALTER TABLE `', REPLACE(is_tables.TABLE_SCHEMA, '`', '``'), '`.`', REPLACE(is_tables.TABLE_NAME, '`', '``'), '` FORCE;') FROM information_schema.TABLES is_tables INNER JOIN information_schema.COLUMNS col ON col.TABLE_SCHEMA = is_tables.TABLE_SCHEMA AND col.TABLE_NAME = is_tables.TABLE_NAME LEFT OUTER JOIN information_schema.INNODB_SYS_TABLES systables ON SUBSTRING_INDEX(systables.NAME, '#', 1) = CONCAT(is_tables.TABLE_SCHEMA,'/',is_tables.TABLE_NAME) LEFT OUTER JOIN information_schema.INNODB_SYS_COLUMNS syscolumns ON syscolumns.TABLE_ID = systables.TABLE_ID AND syscolumns.NAME = col.COLUMN_NAME WHERE col.COLUMN_TYPE IN ('time','timestamp','datetime') AND is_tables.TABLE_TYPE = 'BASE TABLE' AND is_tables.TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema') AND (is_tables.ENGINE = 'InnoDB' AND syscolumns.MTYPE = 6);

로그 파일 크기

MySQL 버전 5.6.20 이상의 경우 다시 실행 로그에 기록된 BLOB에 대한 크기 제한이 있습니다. 이러한 제안을 감안하려면 MySQL DB 인스턴스에 대한 innodb_log_file_size 파라미터가 테이블에서 발견된 BLOB 데이터의 최대 크기 및 동일한 테이블에서의 다른 가변 길이 필드(VARCHAR, VARBINARY, TEXT)의 길이 보다 10배 커야 합니다. 파라미터 값 설정 방법에 대한 자세한 내용은 DB 파라미터 그룹 작업을(를) 참조하십시오. 다시 실행 로그 BLOB 크기 제한에 대한 자세한 내용은 MySQL 5.6.20의 변경 내용을(를) 참조하십시오.

Amazon RDS DB 인스턴스에 대한 MySQL 파라미터 예외

일부 MySQL 파라미터의 경우 Amazon RDS DB 인스턴스와 함께 사용할 때 특별히 고려해야 할 사항이 있습니다.

lower_case_table_names

Amazon RDS는 대/소문자 구분 파일 시스템을 사용하므로 lower_case_table_names 서버 파라미터의 값을 2("이름은 지정된 대로 저장되지만 소문자로 비교됨")로 설정하는 것은 지원하지 않습니다. Amazon RDS DB 인스턴스에 지원되는 값은 기본값인 0("이름은 지정된 대로 저장되며 비교는 대/소문자로 구분하여 진행됨) 또는 1("이름은 소문자로 저장되며 비교는 대/소문자를 구분하지 않고 진행됨")입니다.

lower_case_table_names 파라미터는 DB 인스턴스를 생성하기 전에 사용자 지정 DB 파라미터 그룹의 일부로 설정해야 합니다. 지정 시간 복구 백업과 읽기 복제본 DB 인스턴스와 불일치를 유발할 수 있으므로 기존 데이터베이스 인스턴스에 대한 lower_case_table_names 파라미터를 변경하는 것을 피해야 합니다.

읽기 전용 복제본은 마스터 DB 인스턴스로 항상 동일한 lower_case_table_names 파라미터 값을 사용해야 합니다.

long_query_time

마이크로초 해상도(microsecond resolution)로 느린 쿼리를 MySQL의 느린 쿼리 로그에 기록할 수 있도록long_query_time 파라미터를 부동 소수점 값으로 설정합니다. 100밀리초에 해당하는 0.1초와 같은 값을 설정하여 1초 이내의 시간이 걸리는 느린 트랜젝션을 디버깅할 때 도움을 받을 수 있습니다.

MySQL 파일 크기 제한

Amazon RDS MySQL DB 인스턴스의 경우 최대 프로비저닝 스토리지 제한으로 인해 InnoDB 테이블당 파일 테이블스페이스를 사용하여 각 테이블의 크기가 최대 6TB로 제한됩니다. 또한 이 제한은 시스템 테이블스페이스를 최대 6TB의 크기로 제한합니다. Amazon RDS MySQL DB 인스턴스에서는 테이블이 각각 자체 테이블스페이스에 들어 있는 InnoDB 테이블당 파일 테이블스페이스가 기본적으로 설정됩니다.

참고

2014년 4월 이전에 생성된 MySQL DB 인스턴스는 파일과 테이블 크기 제한이 2TB입니다. 마찬가지로 DB 인스턴스의 생성 시기와 상관없이 2014년 4월 이전에 생성된 DB 스냅샷에서 생성한 DB 인스턴스나 읽기 복제 역시 파일 크기가 2TB로 제한됩니다.

애플리케이션에 따라 InnoDB 테이블당 파일 테이블스페이스 사용에 대한 장점과 단점은 서로 다릅니다. 애플리케이션에 가장 적합한 접근 방식을 확인하려면 MySQL 문서의 InnoDB 테이블당 파일 모드을(를) 참조하십시오.

테이블을 최대 파일 크기로 늘리도록 허용하는 것은 권장하지 않습니다. 일반적으로 모범 사례는 성능 및 복구 시간을 향상할 수 있도록 데이터를 더 작은 테이블로 분할하는 것입니다.

라지 테이블을 여러 개의 스몰 테이블로 분할하는 데 사용할 수 있는 한 가지 옵션으로 파티셔닝이 있습니다. 파티셔닝을 수행하면 사용자가 지정하는 규칙에 따라 라지 테이블의 일부가 개별 파일로 배포됩니다. 예를 들어, 트랜잭션을 날짜별로 저장하는 경우 파티셔닝을 사용하여 이전 트랜잭션을 개별 파일로 배포하는 파티셔닝 규칙을 생성할 수 있습니다. 이렇게 하면 애플리케이션에서 즉시 사용할 필요가 없는 이전 트랜잭션 데이터를 주기적으로 보관할 수 있습니다. 자세한 내용은 MySQL 문서의 https://dev.mysql.com/doc/refman/5.6/en/partitioning.html을(를) 참조하십시오.

테이블의 파일 크기를 확인하는 방법

다음 SQL 명령을 사용하여 크기가 너무 커서 파티셔닝을 수행해야 하는 테이블이 있는지 확인합니다.

Copy
SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)" FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema');

InnoDB 테이블당 파일 테이블스페이스를 활성화하는 방법

  • InnoDB 테이블당 파일 테이블스페이스를 활성화하려면 DB 인스턴스에 대한 파라미터 그룹에서 innodb_file_per_table 파라미터를 1로 설정합니다.

InnoDB 테이블당 파일 테이블스페이스를 비활성화하는 방법

  • InnoDB 테이블당 파일 테이블스페이스를 비활성화하려면 DB 인스턴스에 대한 파라미터 그룹에서 innodb_file_per_table 파라미터를 0으로 설정합니다.

파라미터 그룹 업데이트에 대한 자세한 내용은 DB 파라미터 그룹 작업을(를) 참조하십시오.

InnoDB 테이블당 파일 테이블스페이스를 활성화하거나 비활성화한 경우 ALTER TABLE 명령을 실행하여 아래의 예와 같이 테이블을 전역 테이블스페이스에서 자체 테이블스페이스로 이동하거나 자체 테이블스페이스에서 전역 테이블스페이스로 이동할 수 있습니다.

Copy
ALTER TABLE table_name ENGINE=InnoDB;

이 페이지에서: