# Aurora MySQL 버전 3은 MySQL 8.0과 호환 Aurora MySQL 버전 3을 사용하여 최신 MySQL 호환 기능, 성능 향상 및 버그 수정을 수행할 수 있습니다. 다음에서 MySQL 8.0 호환성을 갖춘 Aurora MySQL 버전 3에 대해 배울 수 있습니다. 클러스터 및 애플리케이션을 Aurora MySQL 버전 3으로 업그레이드하는 방법을 배울 수 있습니다. Aurora Serverless v2와 같은 일부 Aurora 기능에는 Aurora MySQL 버전 3이 필요합니다. **Topics** + [MySQL 8.0 커뮤니티 에디션의 기능](#AuroraMySQL.8.0-features-community) + [Aurora MySQL Serverless v2를 위한 Aurora MySQL 버전 3 전제 조건](#AuroraMySQL.serverless-v2-8.0-prereq) + [Aurora MySQL 버전 3에 대한 릴리스 정보](#AuroraMySQL.mysql80-bugs-fixed) + [새로운 병렬 쿼리 최적화](#AuroraMySQL.8.0-features-pq) + [데이터베이스 재시작 시간 단축을 위한 최적화](#ReducedRestartTime) + [Aurora MySQL 버전 3의 새로운 임시 테이블 동작](ams3-temptable-behavior.md) + [Aurora MySQL 버전 2와 Aurora MySQL 버전 3의 비교](AuroraMySQL.Compare-v2-v3.md) + [Aurora MySQL 버전 3과 MySQL 8.0 커뮤니티 에디션 비교](AuroraMySQL.Compare-80-v3.md) + [Aurora MySQL 버전 3으로 업그레이드](AuroraMySQL.mysql80-upgrade-procedure.md) ## MySQL 8.0 커뮤니티 에디션의 기능 Aurora MySQL 버전 3의 초기 릴리스는 MySQL 8.0.23 커뮤니티 에디션과 호환됩니다. MySQL 8.0에는 다음과 같은 여러 새로운 기능이 도입되었습니다. + 원자성 데이터 정의 언어(DDL) 지원 자세한 내용은 [원자성 데이터 정의 언어(DDL) 지원](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.Compare-v2-v3-atomic-ddl) 단원을 참조하십시오. + JSON 함수. 사용 정보는 *MySQL 참조 설명서*의 [JSON 함수](https://dev.mysql.com/doc/refman/8.0/en/json-functions.html)를 참조하세요. + 창 함수. 사용 정보는 *MySQL 참조 설명서*의 [Window 함수](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html)를 참조하세요. + `WITH` 절을 사용한 공통 테이블 표현식(CTE)입니다. 사용 정보는 *MySQL 참조 설명서*의 [공통 테이블 표현식(WITH)](https://dev.mysql.com/doc/refman/8.0/en/with.html)을 참조하세요. + `ALTER TABLE` 문에 대해 최적화된 `ADD COLUMN` 및 `RENAME COLUMN` 절입니다. 이러한 최적화를 '인스턴트 DDL'이라고 합니다. Aurora MySQL 버전 3은 커뮤니티 MySQL 인스턴트 DDL 기능과 호환됩니다. 이전의 Aurora 빠른 DDL 기능은 사용되지 않습니다. 인스턴트 DDL의 사용 정보는 [인스턴트 DDL(Aurora MySQL 버전 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl) 섹션을 참조하세요. + 내림차순 인덱스, 함수 인덱스 및 보이지 않는 인덱스. 사용 정보는 *MySQL 참조 설명서*의 [보이지 않는 인덱스](https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html), [내림차순 인덱스](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html) 및 [CREATE INDEX 문](https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-functional-key-parts)을 참조하세요. + SQL 문을 통해 제어되는 역할 기반 권한입니다. 권한 모델 변경에 대한 자세한 내용은 [역할 기반 권한 모델](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model) 섹션을 참조하세요. + `SELECT ... FOR SHARE` 문이 포함된 `NOWAIT` 및 `SKIP LOCKED` 절입니다. 이러한 절은 다른 트랜잭션이 행 잠금을 해제할 때까지 기다리지 않습니다. 사용 정보는 *MySQL 참조 설명서*의 [읽기 잠금](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html)을 참조하세요. + 이진 로그(binlog) 복제 향상. Aurora MySQL의 자세한 내용은 [이진 로그 복제](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-binlog) 섹션을 참조하세요. 특히 필터링된 복제를 할 수 있습니다. 필터링된 복제에 대한 사용 정보는 *MySQL 참조 설명서*의 [서버가 복제 필터링 규칙을 평가하는 방법](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html)을 참조하세요. + 힌트. 일부 MySQL 8.0 호환 힌트는 이미 Aurora MySQL 버전 2로 백포팅되었습니다. Aurora MySQL에서 힌트 사용에 대한 자세한 내용은 [Aurora MySQL 힌트](AuroraMySQL.Reference.Hints.md) 섹션을 참조하세요. 커뮤니티 MySQL 8.0의 전체 힌트 목록은 *MySQL 참조 설명서*의 [최적화 프로그램 힌트](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)를 참조하세요. MySQL 8.0 커뮤니티 버전에 추가된 기능의 전체 목록은 블로그 게시물, [MySQL 8.0의 전체 새 기능 목록](https://dev.mysql.com/blog-archive/the-complete-list-of-new-features-in-mysql-8-0/)을 참조하세요. Aurora MySQL 버전 3에는 커뮤니티 MySQL 8.0.26에서 백포팅된 포괄적 언어에 대한 키워드 변경도 포함되어 있습니다. 이러한 변경 사항에 대한 자세한 내용은 [Aurora MySQL 버전 3에 대한 포괄적 언어 변경](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language) 섹션을 참조하세요. ## Aurora MySQL Serverless v2를 위한 Aurora MySQL 버전 3 전제 조건 Aurora MySQL 버전 3은 Aurora MySQL Serverless v2 클러스터의 모든 DB 인스턴스에 대한 전제 조건입니다. Aurora MySQL 서버리스 v2에는 DB 클러스터의 리더 인스턴스 및 Aurora MySQL 서버리스 v1에서 사용할 수 없는 기타 Aurora 기능에 대한 지원이 포함되어 있습니다. 또한 Aurora MySQL 서버리스 v1보다 빠르고 세분화된 크기 조정이 가능합니다. ## Aurora MySQL 버전 3에 대한 릴리스 정보 모든 Aurora MySQL 버전 3 릴리스에 대한 릴리스 정보는 *Aurora MySQL 릴리스 정보*의 [Amazon Aurora MySQL 버전 3에 대한 데이터베이스 엔진 업데이트](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)를 참조하세요. ## 새로운 병렬 쿼리 최적화 Aurora 병렬 쿼리 최적화가 이제 SQL 작업에 더 많이 적용됩니다. + 병렬 쿼리는 이제 768바이트보다 긴 `TEXT`, `BLOB`, `JSON`, `GEOMETRY`, `VARCHAR` 및 `CHAR`와 같은 데이터 유형이 포함된 테이블에 적용됩니다. + 병렬 쿼리는 파티셔닝된 테이블과 관련된 쿼리를 최적화할 수 있습니다. + 병렬 쿼리는 선택 목록 및 `HAVING` 절에서 집계 함수 호출과 관련된 쿼리를 최적화할 수 있습니다. 이런 향상에 대한 자세한 내용은 [Aurora MySQL 버전 3에 병렬 쿼리 클러스터 업그레이드](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2) 섹션을 참조하세요. Aurora 병렬 쿼리에 대한 일반적인 정보는 [Amazon Aurora MySQL용 병렬 쿼리](aurora-mysql-parallel-query.md) 섹션을 참조하세요. ## 데이터베이스 재시작 시간 단축을 위한 최적화 Aurora MySQL DB 클러스터는 계획된 운영 중단과 예기치 않은 운영 중단 모두에서 가용성이 높아야 합니다. 데이터베이스 관리자는 때때로 데이터베이스 유지 관리를 수행해야 합니다. 이 유지 관리에는 데이터베이스 패치 적용, 업그레이드, 수동 재부팅이 필요한 데이터베이스 파라미터 수정, 인스턴스 클래스 변경에 걸리는 시간을 줄이기 위한 장애 조치 수행 등이 포함됩니다. 이러한 계획된 작업에는 가중 중지가 필요합니다. 그러나 가동 중지는 기본 하드웨어 장애로 인한 예상치 못한 장애 조치 또는 데이터베이스 리소스 제한과 같은 예기치 않은 작업으로 인해 발생할 수도 있습니다. 이러한 모든 계획된 작업과 예기치 않은 작업으로 인해 데이터베이스가 다시 시작됩니다. Aurora MySQL 버전 3.05 이상에서 데이터베이스 재시작 시간을 단축하는 최적화 기능을 도입했습니다. 이러한 최적화를 통해 최적화를 사용하지 않을 때보다 가동 중지 시간이 최대 65% 줄어들고 재시작 후 데이터베이스 워크로드가 중단되는 일도 줄어듭니다. 데이터베이스를 시작하는 동안 많은 내부 메모리 구성 요소가 초기화됩니다. 이 중 가장 큰 것은 [InnoDB 버퍼 풀](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/)로, Aurora MySQL에서는 기본적으로 인스턴스 메모리 크기의 75%입니다. 테스트 결과, 초기화 시간은 InnoDB 버퍼 풀의 크기에 비례하므로 DB 인스턴스 클래스 크기에 따라 조정되는 것으로 나타났습니다. 이 초기화 단계에서는 데이터베이스가 연결을 수락할 수 없어 재시작 시 가동 중지가 길어집니다. Aurora MySQL 고속 재시작의 첫 번째 단계는 버퍼 풀 초기화를 최적화하여 데이터베이스 초기화 시간을 줄임으로써 전체 재시작 시간을 줄입니다. 자세한 내용은 [Aurora MySQL 최적화, 데이터베이스 재시작 시간 단축](https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/) 블로그를 참조하세요. # Aurora MySQL 버전 3의 새로운 임시 테이블 동작 Aurora MySQL 버전 3에서는 이전 Aurora MySQL 버전과 다르게 임시 테이블을 처리합니다. 이 새로운 동작은 MySQL 8.0 커뮤니티 에디션에서 상속되었습니다. Aurora MySQL 버전 3에서 생성할 수 있는 임시 테이블에는 다음과 같이 2가지 유형이 있습니다. + 내부(또는 *암묵적*) 임시 테이블 – Aurora MySQL 엔진이 집계 정렬, 파생 테이블 또는 공통 테이블 표현식(CTE)과 같은 작업을 처리하기 위해 생성합니다. + 사용자 생성(또는 *명시적*) 임시 테이블 - `CREATE TEMPORARY TABLE` 문을 사용할 때 Aurora MySQL 엔진에서 생성합니다. Aurora 리더 DB 인스턴스의 내부 및 사용자 생성 임시 테이블 모두에 대해 추가로 고려해야 할 점이 있습니다. 다음 섹션에서 이러한 변경 사항에 대해 살펴봅니다. **Topics** + [내부(암묵적) 임시 테이블에 대한 스토리지 엔진](#ams3-temptable-behavior-engine) + [내부 인 메모리 임시 테이블의 크기 제한](#ams3-temptable-behavior-limit) + [Aurora 복제본의 내부 임시 테이블에 대한 완전성 문제 완화](#ams3-temptable-behavior-mitigate) + [Aurora MySQL DB 인스턴스에서 temptable\$1max\$1mmap 파라미터 최적화](#ams-optimize-temptable_max_mmap) + [리더 DB 인스턴스의 사용자 생성(명시적) 임시 테이블](#ams3-temptable-behavior.user) + [임시 테이블 생성 오류 및 완화](#ams3-temptable-behavior.errors) ## 내부(암묵적) 임시 테이블에 대한 스토리지 엔진 중간 결과 세트를 생성할 때 Aurora MySQL은 처음에 메모리 내 임시 테이블에 쓰기를 시도합니다. 호환되지 않는 데이터 유형이나 구성된 제한으로 인해 실패할 수 있습니다. 그렇다면 임시 테이블은 메모리에 보관되지 않고 온디스크 임시 테이블로 변환됩니다. 이에 대한 자세한 내용은 MySQL 설명서의 [MySQL의 내부 임시 테이블 사용](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html)에서 확인할 수 있습니다. Aurora MySQL 버전 3에서는 내부 임시 테이블이 작동하는 방식이 이전 Aurora MySQL 버전과 다릅니다. 이러한 임시 테이블에 대해 InnoDB와 MyISAM 스토리지 엔진 중에서 선택하지 않고 이제 `TempTable` 및 `MEMORY` 스토리지 엔진 중에서 선택합니다. `TempTable` 스토리지 엔진을 사용하면 특정 데이터를 처리하는 방법을 추가로 선택할 수 있습니다. 영향을 받은 데이터는 DB 인스턴스의 모든 내부 임시 테이블을 저장하는 메모리 풀을 오버플로합니다. 예를 들어 대형 테이블에 `GROUP BY`와 같은 집계를 수행하는 동안 이러한 선택은 많은 양의 임시 데이터를 생성하는 쿼리의 성능에 영향을 줄 수 있습니다. **작은 정보** 워크로드에 내부 임시 테이블을 생성하는 쿼리가 포함되어 있는 경우 벤치마크를 실행하고 성능 관련 지표를 모니터링하여 애플리케이션이 이 변경으로 수행하는 방법을 확인합니다. 경우에 따라 임시 데이터의 양을 `TempTable` 메모리 풀 내에 맞추거나 적은 양으로 메모리 풀만 오버플로합니다. 이러한 경우 내부 임시 테이블 및 메모리 매핑 파일에 대한 `TempTable` 설정을 사용하여 오버플로 데이터를 저장하는 것이 좋습니다. 이게 기본 설정입니다. `TempTable` 스토리지 엔진이 기본값입니다. `TempTable`에서는 테이블당 최대 메모리 제한 대신 이 엔진을 사용하는 모든 임시 테이블에 대한 공통 메모리 풀을 사용합니다. 이 메모리 풀의 크기는 [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) 파라미터에서 지정합니다. 메모리가 16GiB 이상인 DB 인스턴스에서는 1GiB, 메모리가 16GiB 미만인 DB 인스턴스에서는 16MB가 기본값으로 설정됩니다. 메모리 풀의 크기는 세션 수준 메모리 소비에 영향을 줍니다. 경우에 따라 `TempTable` 스토리지 엔진을 사용할 때 임시 데이터가 메모리 풀의 크기를 초과할 수 있습니다. 그렇다면 Aurora MySQL은 보조 메커니즘을 사용하여 오버플로 데이터를 저장합니다. [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) 파라미터를 설정하여 데이터가 메모리 매핑된 임시 파일에 오버플로될지, 디스크의 InnoDB 내부 임시 테이블에 오버플로될지 선택할 수 있습니다. 이러한 오버플로 메커니즘의 다양한 데이터 형식과 오버플로 기준은 쿼리 성능에 영향을 줄 수 있습니다. 이렇게 하려면 디스크에 기록되는 데이터의 양과 디스크 스토리지 처리량에 대한 수요에 영향을 주면 됩니다. Aurora MySQL 버전 3은 다음과 같은 방식으로 오버플로 데이터를 저장합니다. + 라이터 DB 인스턴스에서 InnoDB 내부 임시 테이블 또는 메모리 매핑된 임시 파일로 오버플로되는 데이터는 인스턴스의 로컬 스토리지에 상주합니다. + 리더 DB 인스턴스에서 오버플로 데이터는 항상 로컬 스토리지의 메모리 매핑된 임시 파일에 상주합니다. 읽기 전용 인스턴스는 Aurora 클러스터 볼륨에 데이터를 저장할 수 없습니다. 내부 임시 테이블과 관련된 구성 파라미터는 클러스터의 라이터 및 리더 인스턴스와 다르게 적용됩니다. + 리더 인스턴스의 경우 Aurora MySQL은 항상 `TempTable` 스토리지 엔진을 사용합니다. + DB 인스턴스 메모리 크기에 관계없이 라이터 인스턴스와 리더 인스턴스 모두에 대해 `temptable_max_mmap`의 기본값 크기는 1GiB입니다. 라이터 및 리더 인스턴스 둘 다에서 이 값을 조정할 수 있습니다. + `temptable_max_mmap`을 `0`으로 설정하면 라이터 인스턴스에서 메모리 매핑된 임시 파일 사용이 비활성화됩니다. + 리더 인스턴스에서는 `temptable_max_mmap`을 `0`으로 설정할 수 없습니다. **참고** [temptable\$1use\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap) 파라미터를 사용하지 않는 것이 좋습니다. 이 파라미터는 사용이 중단되었으며 향후 MySQL 릴리스에서 지원이 제거될 예정입니다. ## 내부 인 메모리 임시 테이블의 크기 제한 [내부(암묵적) 임시 테이블에 대한 스토리지 엔진](#ams3-temptable-behavior-engine)에서 설명한 바와 같이 [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) 및 [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) 설정을 사용하여 임시 테이블 리소스를 전역적으로 제어할 수 있습니다. 또한 [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) DB 파라미터를 사용하여 개별 내부 인 메모리 임시 테이블의 크기를 제한할 수 있습니다. 이 제한은 개별 쿼리가 과도한 양의 글로벌 임시 테이블 리소스를 소비하는 것을 방지하기 위한 것이며, 이러한 리소스가 필요한 동시 쿼리의 성능에 영향을 미칠 수 있습니다. `tmp_table_size` 파라미터는 Aurora MySQL 버전 3의 `MEMORY` 스토리지 엔진이 생성한 임시 테이블의 최대 크기를 정의합니다. Aurora MySQL 버전 3.04 이상에서는 `tmp_table_size`가 `aurora_tmptable_enable_per_table_limit` DB 파라미터가 `ON`으로 설정되었을 때 `TempTable` 스토리지 엔진이 생성한 임시 테이블의 최대 크기도 정의합니다. 이 동작은 기본적으로 비활성화(`OFF`)되며, 이는 Aurora MySQL 버전 3.03 이하 버전에서와 동일합니다. + `aurora_tmptable_enable_per_table_limit`이 `OFF`로 설정되었을 때 `tmp_table_size`는 `TempTable` 스토리지 엔진이 생성한 내부 인 메모리 임시 테이블에 고려되지 않습니다. 그러나 글로벌 `TempTable` 리소스 제한은 계속 적용됩니다. Aurora MySQL은 글로벌 `TempTable` 리소스 제한에 도달했을 때 다음과 같이 동작합니다. + 라이터 DB 인스턴스 - Aurora MySQL이 인 메모리 임시 테이블을 InnoDB 온 디스크 임시 테이블로 자동 변환합니다. + 리더 DB 인스턴스 - 쿼리가 오류와 함께 종료됩니다. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` + `aurora_tmptable_enable_per_table_limit`이 `ON`인 경우 Aurora MySQL은 `tmp_table_size` 제한에 도달했을 때 다음과 같이 동작합니다. + 라이터 DB 인스턴스 - Aurora MySQL이 인 메모리 임시 테이블을 InnoDB 온 디스크 임시 테이블로 자동 변환합니다. + 리더 DB 인스턴스 - 쿼리가 오류와 함께 종료됩니다. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` 이 경우 글로벌 `TempTable` 리소스 제한과 테이블당 제한이 모두 적용됩니다. **참고** `aurora_tmptable_enable_per_table_limit` 파라미터는 [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine)이 `MEMORY`로 설정된 경우 아무런 효과가 없습니다. 이 경우 인 메모리 임시 테이블의 최대 크기는 [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) 또는 [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size) 값 중 더 작은 것으로 정의됩니다. 다음 예시는 라이터 및 리더 DB 인스턴스에 대한 `aurora_tmptable_enable_per_table_limit` 파라미터의 동작을 보여줍니다. **Example `aurora_tmptable_enable_per_table_limit`이 `OFF`로 설정된 경우 라이터 DB 인스턴스** 인 메모리 임시 테이블이 InnoDB 온 디스크 임시 테이블로 변환되지 않습니다. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 0 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (13.99 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example `aurora_tmptable_enable_per_table_limit`이 `ON`으로 설정된 경우 라이터 DB 인스턴스** 인 메모리 임시 테이블이 InnoDB 온 디스크 임시 테이블로 변환됩니다. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 0 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; +---------+ | max(n) | +---------+ | 6000000 | +---------+ 1 row in set (4.10 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 1 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example `aurora_tmptable_enable_per_table_limit`이 `OFF`로 설정된 경우 리더 DB 인스턴스** 쿼리가 오류 없이 완료되는 이유는 `tmp_table_size`가 적용되지 않으며 글로벌 `TempTable` 리소스 제한에 도달하지 않았기 때문입니다. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (14.05 sec) ``` **Example `aurora_tmptable_enable_per_table_limit`이 `OFF`로 설정된 경우 리더 DB 인스턴스** 이 쿼리는 `aurora_tmptable_enable_per_table_limit`이 OFF로 설정된 경우 글로벌 TempTable 리소스 제한에 도달합니다. 리더 인스턴스에 오류가 있는 상태로 쿼리가 종료됩니다. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.01 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full ``` **Example `aurora_tmptable_enable_per_table_limit`이 `ON`로 설정된 경우 리더 DB 인스턴스** `tmp_table_size` 제한에 도달하면 오류와 함께 쿼리가 종료됩니다. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 1 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full ``` ## Aurora 복제본의 내부 임시 테이블에 대한 완전성 문제 완화 임시 테이블의 크기 제한 문제를 방지하려면 `temptable_max_ram` 및 `temptable_max_mmap` 파라미터를 워크로드의 요구 사항에 맞출 수 있는 결합된 값으로 설정합니다. `temptable_max_ram` 파라미터 값을 설정할 때는 주의해야 합니다. 값을 너무 높게 설정하면 데이터베이스 인스턴스에서 사용 가능한 메모리가 줄어들어 메모리 부족 상태가 발생할 수 있습니다. DB 인스턴스의 평균 여유 메모리를 모니터링합니다. 그런 다음, `temptable_max_ram`에 대한 적절한 값을 결정하여 인스턴스에 합리적인 수준의 여유 메모리가 계속해서 남아 있도록 합니다. 자세한 내용은 [Amazon Aurora의 여유 메모리 부족](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory) 섹션을 참조하세요. 로컬 스토리지의 크기와 임시 테이블 공간 사용량을 모니터링하는 것도 중요합니다. `FreeLocalStorage`에 설명된 [Amazon Aurora에 대한 Amazon CloudWatch 지표](Aurora.AuroraMonitoring.Metrics.md) Amazon CloudWatch 지표를 사용하여 특정 DB 인스턴스에 사용할 수 있는 임시 스토리지를 모니터링할 수 있습니다. **참고** 이 프로시저는 `aurora_tmptable_enable_per_table_limit` 파라미터가 `ON`으로 설정된 경우에는 작동하지 않습니다. 자세한 내용은 [내부 인 메모리 임시 테이블의 크기 제한](#ams3-temptable-behavior-limit) 섹션을 참조하세요. **Example 1** 임시 테이블의 누적 크기가 20GiB까지 늘어난다는 점은 알고 있지만, 메모리 내 임시 테이블을 2GiB로 설정하고 디스크에서 최대 20GiB까지 확장하려고 합니다. 이 경우 `temptable_max_ram`을 **2,147,483,648**로, `temptable_max_mmap`를 **21,474,836,480**으로 설정합니다. 이러한 값은 바이트 단위입니다. 이러한 파라미터 설정을 사용하면 임시 테이블을 누적해서 총 22GiB로 확장할 수 있습니다. **Example 2** 현재 인스턴스 크기는 16xlarge 이상이고, 필요한 임시 테이블의 전체 크기를 알 수 없습니다. 메모리에서 최대 4GiB를, 디스크에서 사용 가능한 최대 스토리지 크기를 사용할 수 있기를 원합니다. 이 경우 `temptable_max_ram`을 **4,294,967,296**으로, `temptable_max_mmap`를 **1,099,511,627,776**으로 설정합니다. 이러한 값은 바이트 단위입니다. 여기서 `temptable_max_mmap`을 16xlarge Aurora DB 인스턴스의 최대 로컬 스토리지인 1.2TiB보다 작은 1TiB로 설정합니다. 인스턴스 크기가 이보다 작은 경우 사용 가능한 로컬 스토리지를 채우지 않도록 `temptable_max_mmap`의 값을 조정합니다. 예를 들어, 2xlarge 인스턴스에는 160GiB의 로컬 스토리지만 사용할 수 있습니다. 이 경우 값을 160GiB 미만으로 설정하는 것이 좋습니다. DB 인스턴스 크기에 사용할 수 있는 로컬 스토리지에 대한 자세한 내용은 [Aurora MySQL에 대한 임시 스토리지 한도임시 스토리지 한도](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage) 섹션을 참조하세요. ## Aurora MySQL DB 인스턴스에서 temptable\$1max\$1mmap 파라미터 최적화 Aurora MySQL의 `temptable_max_mmap` 파라미터는 온디스크 InnoDB 임시 테이블로 오버플로하거나(라이터 DB 인스턴스) 오류를 발생시키기(리더 DB 인스턴스) 전에 메모리 매핑 파일에서 사용할 수 있는 최대 로컬 디스크 공간을 제어합니다. 이 DB 인스턴스 파라미터를 올바르게 설정하면 DB 인스턴스의 성능을 최적화하는 데 도움이 될 수 있습니다. **사전 조건** 1. 성능 스키마가 활성화되어 있는지 확인합니다. 다음 SQL 명령을 실행하여 확인할 수 있습니다. ``` SELECT @@performance_schema; ``` 출력 값이 `1`이면 활성화되었음을 나타냅니다. 1. 임시 테이블 메모리 계측이 활성화되어 있는지 확인합니다. 다음 SQL 명령을 실행하여 확인할 수 있습니다. ``` SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%'; ``` `enabled` 열에는 관련 임시 테이블 메모리 계측 항목에 대해 `YES`가 표시됩니다. **임시 테이블 사용량 모니터링** `temptable_max_mmap`의 초기 값을 설정할 때는 사용 중인 DB 인스턴스 클래스의 로컬 스토리지 크기의 80%로 시작하는 것이 좋습니다. 이렇게 하면 임시 테이블이 효율적으로 작동할 수 있는 충분한 디스크 공간을 확보하는 동시에 인스턴스에서 다른 디스크를 사용할 수 있는 공간을 확보할 수 있습니다. DB 인스턴스 클래스의 로컬 스토리지 크기를 찾으려면 [Aurora MySQL에 대한 임시 스토리지 한도임시 스토리지 한도](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage) 섹션을 참조하세요. 예를 들어 db.r5.large DB 인스턴스 클래스를 사용하는 경우 로컬 스토리지 크기는 32GiB입니다. 이 경우 처음에 `temptable_max_mmap` 파라미터를 32GiB의 80%, 즉 25.6GiB로 설정합니다. 초기 `temptable_max_mmap` 값을 설정한 후 Aurora MySQL 인스턴스에서 피크 워크로드를 실행합니다. 다음 SQL 쿼리를 사용하여 현재 및 높은 임시 테이블 디스크 사용량을 모니터링합니다. ``` SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%'; ``` 이 쿼리는 다음 정보를 검색합니다. + `event_name` - 임시 테이블 메모리 또는 디스크 사용 이벤트의 이름입니다. + `current_count` - 할당된 현재 임시 테이블 메모리 또는 디스크 블록 수입니다. + `current_alloc` - 임시 테이블에 할당된 현재 메모리 또는 디스크의 양입니다. + `current_avg_alloc` - 임시 테이블 메모리 또는 디스크 블록의 현재 평균 크기입니다. + `high_count` - 할당된 임시 테이블 메모리 또는 디스크 블록의 가장 많은 수입니다. + `high_alloc` - 임시 테이블에 할당된 메모리 또는 디스크의 가장 많은 양입니다. + `high_avg_alloc` - 임시 테이블 메모리 또는 디스크 블록의 가장 큰 평균 크기입니다. 이 설정을 사용하여 테이블이 가득 참 오류와 함께 쿼리가 실패할 경우 임시 테이블 작업을 위해 워크로드에 더 많은 디스크 공간이 필요함을 나타냅니다. 이 경우 로컬 스토리지 공간이 더 많은 인스턴스 크기로 DB 인스턴스 크기를 늘리는 것이 좋습니다. **최적의 `temptable_max_mmap` 값 설정** 다음 프로시저에 따라 `temptable_max_mmap` 파라미터에 적합한 크기를 모니터링하고 설정합니다. 1. 이전 쿼리의 출력을 검토하고 `high_alloc` 열에 표시된 대로 임시 테이블 디스크 피크 사용량을 식별합니다. 1. 임시 테이블 디스크 피크 사용량에 따라 Aurora MySQL DB 인스턴스의 DB 파라미터 그룹에서 `temptable_max_mmap` 파라미터를 조정합니다. 향후 성장을 수용하기 위해 값을 임시 테이블 디스크 피크 사용량보다 약간 높게 설정합니다. 1. DB 인스턴스에 파라미터 그룹 변경 사항을 적용합니다. 1. 피크 워크로드 중에 임시 테이블 디스크 사용량을 다시 모니터링하여 새 `temptable_max_mmap` 값이 적절한지 확인합니다. 1. 필요에 따라 이전 단계를 반복하여 `temptable_max_mmap` 파라미터를 미세 조정합니다. ## 리더 DB 인스턴스의 사용자 생성(명시적) 임시 테이블 `CREATE TABLE` 문에서 `TEMPORARY` 키워드를 사용하여 명시적 임시 테이블을 생성할 수 있습니다. Aurora DB 클러스터의 라이터 DB 인스턴스에서 명시적 임시 테이블이 지원됩니다. 리더 DB 인스턴스에서 명시적 임시 테이블을 사용할 수도 있지만, 이 테이블에서 InnoDB 스토리지 엔진을 사용할 수 없습니다. Aurora 리더 DB 인스턴스에서 명시적 임시 테이블을 생성하는 동안 오류가 발생하지 않게 하려면 모든 `CREATE TEMPORARY TABLE` 문을 다음 두 방법 중 하나 또는 둘 다를 이용해 실행해야 합니다. + `ENGINE=InnoDB` 절은 지정하지 마십시오. + SQL 모드를 `NO_ENGINE_SUBSTITUTION`으로 설정하지 마십시오. ## 임시 테이블 생성 오류 및 완화 수신하는 오류는 일반 `CREATE TEMPORARY TABLE` 문 또는 변형 `CREATE TEMPORARY TABLE AS SELECT`를 사용하는지에 따라 다릅니다. 다음 예에서는 서로 다른 형식의 오류를 보여줍니다. 이 임시 테이블 동작은 읽기 전용 인스턴스에만 적용됩니다. 이 첫 번째 예에서는 세션이 연결된 인스턴스의 종류임을 확인합니다. ``` mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 1 | +--------------------+ ``` 일반 `CREATE TEMPORARY TABLE` 문에서 명령문은 `NO_ENGINE_SUBSTITUTION` SQL 모드가 켜져 있는 경우 실패합니다. `NO_ENGINE_SUBSTITUTION`이 해제되면(기본값) 적절한 엔진 교체가 이루어지며, 임시 테이블 생성이 성공합니다. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB; mysql> SHOW CREATE TABLE tt4\G *************************** 1. row *************************** Table: tt4 Create Table: CREATE TEMPORARY TABLE `tt4` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ``` `CREATE TEMPORARY TABLE AS SELECT` 문에서 명령문은 `NO_ENGINE_SUBSTITUTION` SQL 모드가 켜져 있는 경우 실패합니다. `NO_ENGINE_SUBSTITUTION`이 해제되면(기본값) 적절한 엔진 교체가 이루어지며, 임시 테이블 생성이 성공합니다. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> show create table tt3; +-------+----------------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------------+ | tt3 | CREATE TEMPORARY TABLE `tt3` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci | +-------+----------------------------------------------------------+ 1 row in set (0.00 sec) ``` Aurora MySQL 버전 3에서 임시 테이블의 스토리지 측면 및 성능 영향에 대한 자세한 내용은 [Amazon RDS for MySQL 및 Amazon Aurora MySQL의 TempTable 스토리지 엔진 사용](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/) 블로그 게시물을 참조하세요. # Aurora MySQL 버전 2와 Aurora MySQL 버전 3의 비교 Aurora MySQL 버전 2 클러스터를 버전 3으로 업그레이드하는 경우 주의해야 할 변경 사항에 대해 알아보려면 다음을 참조하세요. **Topics** + [원자성 데이터 정의 언어(DDL) 지원](#AuroraMySQL.Compare-v2-v3-atomic-ddl) + [Aurora MySQL 버전 2와 3의 기능 차이점](#AuroraMySQL.Compare-v2-v3-features) + [인스턴스 클래스 지원](#AuroraMySQL.mysql80-instance-classes) + [Aurora MySQL 버전 3에 대한 파라미터 변경 사항](#AuroraMySQL.mysql80-parameter-changes) + [상태 변수](#AuroraMySQL.mysql80-status-vars) + [Aurora MySQL 버전 3에 대한 포괄적 언어 변경](#AuroraMySQL.8.0-inclusive-language) + [AUTO\$1INCREMENT 값](#AuroraMySQL.mysql80-autoincrement) + [이진 로그 복제](#AuroraMySQL.mysql80-binlog) ## 원자성 데이터 정의 언어(DDL) 지원 MySQL 5.7에서 8.0으로의 가장 큰 변경 사항 중 하나는 [원자성 데이터 딕셔너리](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html)의 도입입니다. MySQL 8.0 이전에 MySQL 데이터 딕셔너리는 파일 기반 접근 방식을 사용하여 테이블 정의(.frm), 트리거(.trg) 및 함수와 같은 메타데이터를 스토리지 엔진의 메타데이터(예: InnoDB)와 별도로 저장했습니다. 이로 인해 DDL 작업 중에 예기치 않은 일이 발생하여 파일 기반 및 스토리지 엔진 메타데이터가 동기화되지 않을 경우 테이블이 ‘[분리](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html)’될 위험을 비롯한 몇 가지 문제가 발생했습니다. 이를 해결하기 위해 MySQL 8.0은 모든 메타데이터를 `mysql` 스키마의 내부 InnoDB 테이블 세트에 저장하는 원자성 데이터 딕셔너리를 도입했습니다. 이 새로운 아키텍처는 트랜잭션 [ACID](https://en.wikipedia.org/wiki/ACID) 규정을 준수하는 방식으로 데이터베이스 메타데이터를 관리하여 이전 파일 기반 접근 방식의 '원자성 DDL' 문제를 해결합니다. 원자성 데이터 딕셔너리에 대한 자세한 내용은 MySQL 참조 설명서**의 [파일 기반 메타데이터 스토리지 제거](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) 및 [원자성 데이터 정의 문 지원](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html)을 참조하세요. 이러한 아키텍처 변경으로 인해 Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때 다음을 고려해야 합니다. + 버전 3으로 업그레이드하는 동안 버전 2의 파일 기반 메타데이터를 새 데이터 딕셔너리 테이블로 마이그레이션해야 합니다. 마이그레이션되는 데이터베이스 객체 수에 따라 시간이 다소 걸릴 수 있습니다. + 또한 이 변경 사항으로 인해 MySQL 5.7에서 8.0으로 업그레이드하기 전에 해결해야 할 몇 가지 새로운 비호환성도 발생했습니다. 예를 들어, 8.0에는 기존 데이터베이스 객체 이름과 충돌할 수 있는 일부 새로운 예약 키워드가 있습니다. 엔진을 업그레이드하기 전에 이러한 비호환성을 식별하는 데 도움이 되도록 Aurora MySQL은 일련의 업그레이드 호환성 검사(사전 확인)를 실행하여 데이터 딕셔너리 업그레이드를 수행하기 전에 데이터베이스 딕셔너리에 비호환 객체가 있는지 확인합니다. 사전 확인에 대한 자세한 설명은 [Aurora MySQL에 대한 메이저 버전 업그레이드 사전 확인](AuroraMySQL.upgrade-prechecks.md) 섹션을 참조하세요. ## Aurora MySQL 버전 2와 3의 기능 차이점 다음 Amazon Aurora MySQL 기능은 Aurora MySQL for MySQL 5.7에서 지원되지만, 이러한 기능은 현재 Aurora MySQL for MySQL 8.0에서 지원되지 않습니다. + Aurora Serverless v1 클러스터를 위한 Aurora MySQL 버전 3을 사용할 수 없습니다. Aurora MySQL 버전 3은 Aurora Serverless v2와 호환됩니다. + 랩 모드는 Aurora MySQL 버전 3에는 적용되지 않습니다. Aurora MySQL 버전 3에는 랩 모드 기능이 없습니다. 인스턴트 DDL은 이전에 랩 모드에서 사용 가능했던 빠른 온라인 DDL 기능을 대체합니다. 예시는 [인스턴트 DDL(Aurora MySQL 버전 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl)을 확인하세요. + 쿼리 캐시는 커뮤니티 MySQL 8.0 및 Aurora MySQL 버전 3에서도 제거됩니다. + Aurora MySQL 버전 3은 커뮤니티 MySQL 해시 조인 기능과 호환됩니다. Aurora MySQL 버전 2에서 해시 조인의 Aurora별 구현은 사용되지 않습니다. Aurora 병렬 쿼리에서 해시 조인 사용에 대한 자세한 내용은 [병렬 쿼리 클러스터에 대한 해시 조인 설정](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join) 및 [Aurora MySQL 힌트](AuroraMySQL.Reference.Hints.md) 섹션을 참조하세요. 해시 조인에 대한 일반적인 사용 정보는 *MySQL 참조 설명서*의 [해시 조인 최적화](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html)를 참조하세요. + Aurora MySQL 버전 2에서 더 이상 사용되지 않는 `mysql.lambda_async` 저장 프로시저는 버전 3에서 제거됩니다. 버전 3의 경우 대신 비동기 함수 `lambda_async`을 사용합니다. + Aurora MySQL 버전 3의 기본 문자 집합은 `utf8mb4`입니다. Aurora MySQL 버전 2의 기본 문자 집합은 `latin1`이었습니다. 이 문자 집합에 대한 자세한 내용은 *MySQL 참조 설명서*의 [utf8mb4 문자 집합(4바이트 UTF-8 유니코드 인코딩)](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html)을 참조하세요. 일부 Aurora MySQL 기능은 AWS 리전 및 DB 엔진 버전의 특정 조합에서 사용할 수 있습니다. 세부 정보는 [Amazon Aurora에서 AWS 리전 및 Aurora DB 엔진별 지원 기능](Concepts.AuroraFeaturesRegionsDBEngines.grids.md)을 참조하세요. ## 인스턴스 클래스 지원 Aurora MySQL 버전 3은 Aurora MySQL 버전 2와 다른 인스턴스 클래스 집합을 지원합니다. + 대형 인스턴스의 경우 `db.r5`, `db.r6g` 및 `db.x2g`와 같은 최신 인스턴스 클래스를 사용할 수 있습니다. + 소형 인스턴스의 경우 `db.t3` 및 `db.t4g`와 같은 최신 인스턴스 클래스를 사용할 수 있습니다. **참고** T DB 인스턴스 클래스는 개발 및 테스트 서버 또는 기타 비프로덕션 서버에만 사용하는 것이 좋습니다. T 인스턴스 클래스에 대한 자세한 내용은 [개발 및 테스트에 T 인스턴스 클래스 사용](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium) 섹션을 참조하세요. Aurora MySQL 버전 2의 다음 인스턴스 클래스는 Aurora MySQL 버전 3에서 사용할 수 없습니다. + `db.r4` + `db.r3` + `db.t3.small` + `db.t2` Aurora MySQL DB 인스턴스를 생성하는 CLI 문을 관리 스크립트에서 확인하세요. Aurora MySQL 버전 3에서 사용할 수 없는 인스턴스 클래스 이름을 하드코딩합니다. 필요한 경우 인스턴스 클래스 이름을 Aurora MySQL 버전 3에서 지원하는 이름으로 수정합니다. **작은 정보** Aurora MySQL 버전 및 AWS 리전의 특정 조합에 사용할 수 있는 인스턴스 클래스를 확인하려면 `describe-orderable-db-instance-options` AWS CLI 명령을 사용하세요. Aurora 인스턴스 클래스에 대한 자세한 내용은 [Amazon AuroraDB 인스턴스 클래스](Concepts.DBInstanceClass.md) 섹션을 참조하세요. ## Aurora MySQL 버전 3에 대한 파라미터 변경 사항 Aurora MySQL 버전 3에는 새로운 클러스터 수준 및 인스턴스 수준 구성 파라미터가 포함되어 있습니다. Aurora MySQL 버전 3은 또한 Aurora MySQL 버전 2에 있던 일부 파라미터를 제거합니다. 일부 파라미터 이름은 포괄적 언어에 대한 이니셔티브의 결과로 변경됩니다. 이전 버전과의 호환성을 위해 이전 이름이나 새 이름을 사용하여 파라미터 값을 검색할 수 있습니다. 그러나 새 이름을 사용하여 사용자 지정 파라미터 그룹에서 파라미터 값을 지정해야 합니다. Aurora MySQL 버전 3에서는 `lower_case_table_names` 파라미터가 클러스터가 생성될 때 영구적으로 설정됩니다. 이 옵션에 기본값이 아닌 값을 사용하는 경우 업그레이드하기 전에 Aurora MySQL 버전 3 사용자 지정 파라미터 그룹을 설정합니다. 그런 다음, 클러스터 생성 또는 스냅샷 복원 작업 중에 파라미터 그룹을 지정합니다. **참고** Aurora MySQL 기반 Aurora Global Database 사용 시 `lower_case_table_names` 파라미터가 활성화 되어 있는 경우 Aurora MySQL 버전 2에서 버전 3으로 현재 위치 업그레이드를 수행할 수 없습니다. 대신 스냅샷 복원 방법을 사용하세요. Aurora MySQL 버전 3에서는 `CONNECTION_ADMIN` 권한이 있는 사용자에게 `init_connect` 및 `read_only` 파라미터가 적용되지 않습니다. Aurora 마스터 사용자도 마찬가지입니다. 자세한 내용은 [역할 기반 권한 모델](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model) 단원을 참조하십시오. Aurora MySQL 클러스터 파라미터 전체 목록은 [클러스터 수준 파라미터](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster) 섹션을 참조하세요. 이 테이블에서는 Aurora MySQL 버전 2 및 3의 모든 파라미터를 다룹니다. 이 테이블에는 Aurora MySQL 버전 3에서 새로운 파라미터 또는 Aurora MySQL 버전 3에서 제거된 파라미터를 보여주는 메모가 포함되어 있습니다. Aurora MySQL 인스턴스 파라미터 전체 목록은 [인스턴스 수준 파라미터](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance) 섹션을 참조하세요. 이 테이블에서는 Aurora MySQL 버전 2 및 3의 모든 파라미터를 다룹니다. 이 테이블에는 Aurora MySQL 버전 3에서 새로운 파라미터 또는 Aurora MySQL 버전 3에서 제거된 파라미터를 보여주는 메모가 포함되어 있습니다. 또한 이전 버전에서는 수정할 수 있었지만 Aurora MySQL 버전 3에서는 수정할 수 없는 파라미터를 보여주는 메모도 포함되어 있습니다. 변경된 파라미터 이름에 대한 자세한 내용은 [Aurora MySQL 버전 3에 대한 포괄적 언어 변경](#AuroraMySQL.8.0-inclusive-language) 섹션을 참조하세요. ## 상태 변수 Aurora MySQL에 적용되지 않는 상태 변수에 대한 자세한 내용은 [Aurora MySQL에 적용되지 않는 MySQL 상태 변수](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable) 섹션을 참조하세요. ## Aurora MySQL 버전 3에 대한 포괄적 언어 변경 Aurora MySQL 버전 3은 MySQL 커뮤니티 에디션의 버전 8.0.23과 호환됩니다. Aurora MySQL 버전 3에는 포괄적 언어에 대한 키워드 및 시스템 스키마와 관련된 MySQL 8.0.26의 변경도 포함되어 있습니다. 예를 들어 `SHOW REPLICA STATUS` 명령이 이제 `SHOW SLAVE STATUS` 대신 기본 설정됩니다. 다음 Amazon CloudWatch 지표는 Aurora MySQL 버전 3에서 새 이름을 갖습니다. Aurora MySQL 버전 3에서는 새 지표 이름만 사용할 수 있습니다. Aurora MySQL 버전 3으로 업그레이드할 때 지표 이름에 의존하는 경보 또는 기타 자동화를 업데이트해야 합니다. | 이전 이름 | 새 이름 | | --- | --- | | ForwardingMasterDMLLatency | ForwardingWriterDMLLatency | | ForwardingMasterOpenSessions | ForwardingWriterOpenSessions | | AuroraDMLRejectedMasterFull | AuroraDMLRejectedWriterFull | | ForwardingMasterDMLThroughput | ForwardingWriterDMLThroughput | 다음 상태 변수는 Aurora MySQL 버전 3에서 새 이름을 갖습니다. 호환성을 위해 초기 Aurora MySQL 버전 3 릴리스에서 두 이름 중 하나를 사용할 수 있습니다. 향후 릴리스에서 기존 상태 변수 이름이 제거되게 됩니다. | 제거할 이름 | 새 이름 또는 기본 이름 | | --- | --- | | Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration | | Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count | | Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration | | Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Aurora\$1fwd\$1writer\$1select\$1stmt\$1count | | Aurora\$1fwd\$1master\$1errors\$1session\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1session\$1timeout | | Aurora\$1fwd\$1master\$1open\$1sessions | Aurora\$1fwd\$1writer\$1open\$1sessions | | Aurora\$1fwd\$1master\$1errors\$1session\$1limit | Aurora\$1fwd\$1writer\$1errors\$1session\$1limit | | Aurora\$1fwd\$1master\$1errors\$1rpc\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1rpc\$1timeout | 다음 구성 파라미터는 Aurora MySQL 버전 3에서 새 이름을 갖습니다. 호환성을 위해 초기 Aurora MySQL 버전 3 릴리스에서 두 이름 중 하나를 사용하여 `mysql`에서 파라미터 값을 확인할 수 있습니다. 사용자 정의 파라미터 그룹의 값을 수정할 때는 새 이름만 사용 수 있습니다. 향후 릴리스에서 기존 파라미터 이름이 제거되게 됩니다. | 제거할 이름 | 새 이름 또는 기본 이름 | | --- | --- | | aurora\$1fwd\$1master\$1idle\$1timeout | aurora\$1fwd\$1writer\$1idle\$1timeout | | aurora\$1fwd\$1master\$1max\$1connections\$1pct | aurora\$1fwd\$1writer\$1max\$1connections\$1pct | | master\$1verify\$1checksum | source\$1verify\$1checksum | | sync\$1master\$1info | sync\$1source\$1info | | init\$1slave | init\$1replica | | rpl\$1stop\$1slave\$1timeout | rpl\$1stop\$1replica\$1timeout | | log\$1slow\$1slave\$1statements | log\$1slow\$1replica\$1statements | | slave\$1max\$1allowed\$1packet | replica\$1max\$1allowed\$1packet | | slave\$1compressed\$1protocol | replica\$1compressed\$1protocol | | slave\$1exec\$1mode | replica\$1exec\$1mode | | slave\$1type\$1conversions | replica\$1type\$1conversions | | slave\$1sql\$1verify\$1checksum | replica\$1sql\$1verify\$1checksum | | slave\$1parallel\$1type | replica\$1parallel\$1type | | slave\$1preserve\$1commit\$1order | replica\$1preserve\$1commit\$1order | | log\$1slave\$1updates | log\$1replica\$1updates | | slave\$1allow\$1batching | replica\$1allow\$1batching | | slave\$1load\$1tmpdir | replica\$1load\$1tmpdir | | slave\$1net\$1timeout | replica\$1net\$1timeout | | sql\$1slave\$1skip\$1counter | sql\$1replica\$1skip\$1counter | | slave\$1skip\$1errors | replica\$1skip\$1errors | | slave\$1checkpoint\$1period | replica\$1checkpoint\$1period | | slave\$1checkpoint\$1group | replica\$1checkpoint\$1group | | slave\$1transaction\$1retries | replica\$1transaction\$1retries | | slave\$1parallel\$1workers | replica\$1parallel\$1workers | | slave\$1pending\$1jobs\$1size\$1max | replica\$1pending\$1jobs\$1size\$1max | | pseudo\$1slave\$1mode | pseudo\$1replica\$1mode | 다음 저장 프로시저는 Aurora MySQL 버전 3에서 새 이름을 갖습니다. 호환성을 위해 초기 Aurora MySQL 버전 3 릴리스에서 두 이름 중 하나를 사용할 수 있습니다. 향후 릴리스에서 기존 프로시저 이름이 제거되게 됩니다. | 제거할 이름 | 새 이름 또는 기본 이름 | | --- | --- | | mysql.rds\$1set\$1master\$1auto\$1position | mysql.rds\$1set\$1source\$1auto\$1position | | mysql.rds\$1set\$1external\$1master | mysql.rds\$1set\$1external\$1source | | mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position | mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position | | mysql.rds\$1reset\$1external\$1master | mysql.rds\$1reset\$1external\$1source | | mysql.rds\$1next\$1master\$1log | mysql.rds\$1next\$1source\$1log | ## AUTO\$1INCREMENT 값 Aurora MySQL 버전 3에서 Aurora에서는 각 DB 인스턴스를 다시 시작할 때 각 테이블의 `AUTO_INCREMENT` 값을 보존합니다. Aurora MySQL 버전 2에서는 다시 시작한 후에는 `AUTO_INCREMENT` 값이 보존되지 않았습니다. 스냅샷에서 복원하고, 특정 시점으로 복구를 수행하고, 클러스터를 복제하여 새 클러스터를 설정하는 경우 `AUTO_INCREMENT` 값이 보존되지 않습니다. 이런 경우 `AUTO_INCREMENT` 값은 스냅샷이 생성된 시점의 테이블에서 가장 큰 열 값을 기준으로 한 값으로 초기화됩니다. 이 동작은 이런 작업 중에 `AUTO_INCREMENT` 값이 보존되는 RDS for MySQL 8.0의 동작과 다릅니다. ## 이진 로그 복제 MySQL 8.0 커뮤니티 에디션에서는 기본적으로 이진 로그 복제를 설정해 둡니다. Aurora MySQL 버전 3에서는 기본적으로 이진 로그 복제를 해제해 둡니다. **작은 정보** Aurora 기본 제공 복제 기능으로 고가용성 요구 사항이 충족되면 이진 로그 복제를 해제해 둘 수 있습니다. 이렇게 하면 이진 로그 복제의 성능 오버헤드를 방지할 수 있습니다. 또한 이진 로그 복제를 관리하는 데 필요한 관련 모니터링 및 문제 해결을 방지할 수 있습니다. Aurora는 MySQL 5.7 호환 소스에서 Aurora MySQL 버전 3으로 이진 로그 복제를 지원합니다. 소스 시스템은 Aurora MySQL DB 클러스터, RDS for MySQL DB 인스턴스 또는 온프레미스 MySQL 인스턴스일 수 있습니다. 커뮤니티 MySQL과 마찬가지로 Aurora MySQL은 특정 버전을 실행하는 소스에서 동일한 주 버전 또는 하나의 주 버전 이상을 실행하는 대상으로 복제를 지원합니다. 예를 들어 MySQL 5.6 호환 시스템에서 Aurora MySQL 버전 3으로 복제는 지원되지 않습니다. Aurora MySQL 버전 3에서 MySQL 5.7 호환 또는 MySQL 5.6 호환 시스템으로 복제는 지원되지 않습니다. 이진 로그 복제 사용에 대한 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 섹션을 참조하세요. Aurora MySQL 버전 3에는 필터링된 복제와 같은 커뮤니티 MySQL 8.0에서 이진 로그 복제에 대한 개선이 포함됩니다. 커뮤니티 MySQL 8.0 개선 사항에 대한 자세한 내용은 *MySQL 참조 설명서*의 [서버가 복제 필터링 규칙을 평가하는 방법](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html)을 참조하세요. ### 이진 로그 복제에 대한 트랜잭션 압축 이진 로그 압축에 대한 사용 정보는 MySQL 참조 설명서의 [이진 로그 트랜잭션 압축](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html)을 참조하세요. Aurora MySQL 버전 3의 이진 로그 압축에는 다음 제한 사항이 적용됩니다. + 이진 로그 데이터가 허용되는 최대 패킷 크기보다 큰 트랜잭션은 압축되지 않습니다. 이는 Aurora MySQL 이진 로그 압축 설정이 켜져 있는지와 관계없이 해당됩니다. 이러한 트랜잭션은 압축되지 않고 복제됩니다. + 아직 MySQL 8.0을 지원하지 않는 변경 데이터 캡처(CDC)의 커넥터를 사용하는 경우 이 기능을 사용할 수 없습니다. 이진 로그 압축을 사용하여 타사 커넥터를 철저히 테스트하는 것이 좋습니다. 또한 CDC에 binlog 복제를 사용하는 시스템에서 binlog 압축을 켜기 전에 테스트하는 것이 좋습니다. # Aurora MySQL 버전 3과 MySQL 8.0 커뮤니티 에디션 비교 다음 정보를 사용하여 다른 MySQL 8.0 호환 시스템에서 Aurora MySQL 버전 3으로 변환하는 경우 알아야 할 변경 사항에 대해 알아볼 수 있습니다. 일반적으로 Aurora MySQL 버전 3은 커뮤니티 MySQL 8.0.23의 기능 세트를 지원합니다. MySQL 8.0 커뮤니티 에디션의 일부 새로운 기능은 Aurora MySQL에는 적용되지 않습니다. 이러한 기능 중 일부는 Aurora 스토리지 아키텍처와 같은 Aurora의 일부 측면과 호환되지 않습니다. Amazon RDS 관리 서비스가 동등한 기능을 제공하기 때문에 다른 기능은 필요하지 않습니다. 커뮤니티 MySQL 8.0의 다음 기능은 Aurora MySQL 버전 3에서 지원되지 않거나 다르게 작동합니다. 모든 Aurora MySQL 버전 3 릴리스에 대한 릴리스 정보는 *Aurora MySQL 릴리스 정보*의 [Amazon Aurora MySQL 버전 3에 대한 데이터베이스 엔진 업데이트](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)를 참조하세요. **Topics** + [Aurora MySQL 버전 3에서 MySQL 8.0 기능을 사용할 수 없음](#AuroraMySQL.Compare-80-v3-features) + [역할 기반 권한 모델](#AuroraMySQL.privilege-model) + [데이터베이스 서버 ID 찾기](#AuroraMySQL.server-id) + [Authentication](#AuroraMySQL.mysql80-authentication) ## Aurora MySQL 버전 3에서 MySQL 8.0 기능을 사용할 수 없음 커뮤니티 MySQL 8.0의 다음 기능은 Aurora MySQL 버전 3에서 사용할 수 없거나 다르게 작동합니다. + Aurora MySQL에서는 Resource Groups 및 관련 SQL 문을 지원하지 않습니다. + Aurora MySQL은 사용자 정의 테이블스페이스 실행 취소 및 관련 SQL 문(예: `CREATE UNDO TABLESPACE`, `ALTER UNDO TABLESPACE ... SET INACTIVE`, `DROP UNDO TABLESPACE`)을 지원하지 않습니다. + Aurora MySQL은 3.06 미만의 Aurora MySQL 버전에서 테이블스페이스 자르기 실행 취소를 지원하지 않습니다. Aurora MySQL 버전 3.06 이상에서는 [테이블스페이스 자르기 자동 실행 취소](https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace)가 지원됩니다. + 암호 검증 플러그인이 지원됩니다. + 암호 검증 플러그인을 포함하여 MySQL 플러그인의 설정을 수정할 수 없습니다. + X 플러그인은 지원되지 않습니다. + 다중 소스 복제는 지원되지 않습니다. ## 역할 기반 권한 모델 Aurora MySQL 버전 3에서는 `mysql` 데이터베이스의 테이블을 직접 수정할 수 없습니다. 특히 `mysql.user` 테이블에 삽입하여 사용자를 설정할 수 없습니다. 대신 SQL 문을 사용하여 역할 기반 권한을 부여합니다. 또한 `mysql` 데이터베이스에 저장 프로시저를 비롯한 다른 종류의 객체를 생성할 수 없습니다. 여전히 `mysql` 테이블을 쿼리할 수 있습니다. 이진 로그 복제를 사용하는 경우 원본 클러스터의 `mysql` 테이블에 대한 직접 변경은 대상 클러스터로 복제되지 않습니다. 경우에 따라 애플리케이션에서 바로 가기를 사용하여 `mysql` 테이블에 삽입함으로써 사용자 또는 다른 객체를 만들 수 있습니다. 그렇다면 애플리케이션 코드를 변경하여 `CREATE USER`와 같은 해당 명령문을 사용합니다. 애플리케이션에서 `mysql` 데이터베이스에 저장 프로시저 또는 다른 객체를 생성하는 경우 다른 데이터베이스를 대신 사용합니다. 외부 MySQL 데이터베이스에서 마이그레이션하는 동안 데이터베이스 사용자의 메타데이터를 내보내려면 `mysqldump` 대신 MySQL Shell 명령을 사용할 수 있습니다. 자세한 내용은 [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about)를 참조하세요. 많은 사용자 또는 애플리케이션에 대한 권한 관리를 단순화하려면 `CREATE ROLE` 문을 사용하여 권한 집합이 있는 역할을 만들 수 있습니다. 그런 다음, `GRANT` 및 `SET ROLE` 문과 `current_role` 함수를 사용하여 사용자 또는 애플리케이션에 역할을 할당하고 현재 역할을 전환하며 어떤 역할이 유효한지 확인할 수 있습니다. MySQL 8.0의 역할 기반 권한 시스템에 대한 자세한 내용은 MySQL 참조 설명서의 [역할 사용](https://dev.mysql.com/doc/refman/8.0/en/roles.html)을 참조하세요. **중요** 애플리케이션에서 직접 마스터 사용자를 사용하지 않는 것이 좋습니다. 대신에 애플리케이션에 필요한 최소 권한으로 생성한 데이터베이스 사용자를 사용하는 모범 사례를 준수하십시오. **Topics** + [rds\$1superuser\$1role](#AuroraMySQL.privilege-model.rds_superuser_role) + [이진 로그 복제에 대한 권한 검사 사용자](#AuroraMySQL.privilege-model.binlog) + [다른 AWS 서비스에 액세스하기 위한 역할](#AuroraMySQL.privilege-model.other) ### rds\$1superuser\$1role Aurora MySQL 버전 3에는 다음과 같은 모든 권한이 있는 특수 역할이 포함됩니다. 이 역할의 이름은 `rds_superuser_role`입니다. 각 클러스터의 기본 관리 사용자에게는 이미 이 역할이 부여되었습니다. `rds_superuser_role` 역할에는 모든 데이터베이스 객체에 대한 다음과 같은 권한이 포함됩니다. + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CONNECTION_ADMIN` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `FLUSH_OPTIMIZER_COSTS`(Aurora MySQL 버전 3.09 이상) + `FLUSH_STATUS`(Aurora MySQL 버전 3.09 이상) + `FLUSH_TABLES`(Aurora MySQL 버전 3.09 이상) + `FLUSH_USER_RESOURCES`(Aurora MySQL 버전 3.09 이상) + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW_ROUTINE`(Aurora MySQL 버전 3.04 이상) + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` 역할 정의에는 `WITH GRANT OPTION`이 포함되므로 관리 사용자가 다른 사용자에게 해당 역할을 부여할 수 있습니다. 특히 관리자는 Aurora MySQL 클러스터를 대상으로 사용하여 이진 로그 복제를 수행하는 데 필요한 모든 권한을 부여해야 합니다. **작은 정보** 권한의 세부 정보를 모두 확인하려면 다음 명령문을 입력합니다. ``` SHOW GRANTS FOR rds_superuser_role@'%'; SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%'; ``` ### 이진 로그 복제에 대한 권한 검사 사용자 Aurora MySQL 버전 3에는 이진 로그(binlog) 복제에 대한 권한 검사 사용자인 `rdsrepladmin_priv_checks_user`가 포함되어 있습니다. 이 사용자는 `rds_superuser_role`의 권한 외에도 `replication_applier` 권한을 가집니다. `mysql.rds_start_replication` 저장 절차를 직접적으로 호출하여 binlog 복제를 켜면 `rdsrepladmin_priv_checks_user`가 생성됩니다. `rdsrepladmin_priv_checks_user@localhost` 사용자는 예약된 사용자입니다. 수정하지 마세요. ### 다른 AWS 서비스에 액세스하기 위한 역할 Aurora MySQL 버전 3에는 다른 AWS 서비스에 액세스하는 데 사용할 수 있는 역할이 포함됩니다. 이러한 역할을 권한 부여에 대한 대안으로 설정할 수 있습니다. 예를 들어 `GRANT INVOKE LAMBDA ON *.* TO user` 대신 `GRANT AWS_LAMBDA_ACCESS TO user`를 지정합니다. 다른 AWS 서비스에 대한 액세스 절차는 [Amazon Aurora MySQL을 다른 AWS 서비스와 통합](AuroraMySQL.Integrating.md) 섹션을 참조하세요. Aurora MySQL 버전 3에는 다른 AWS 서비스에 대한 액세스와 관련된 다음 역할이 포함됩니다. + `AWS_LAMBDA_ACCESS` – `INVOKE LAMBDA` 권한에 대한 대안입니다. 사용 정보는 [Amazon Aurora MySQL DB 클러스터에서 Lambda 함수 호출](AuroraMySQL.Integrating.Lambda.md) 섹션을 참조하세요. + `AWS_LOAD_S3_ACCESS` – `LOAD FROM S3` 권한에 대한 대안입니다. 사용 정보는 [Amazon S3 버킷의 텍스트 파일에서 Amazon Aurora MySQL DB 클러스터로 데이터 로드](AuroraMySQL.Integrating.LoadFromS3.md) 섹션을 참조하세요. + `AWS_SELECT_S3_ACCESS` – `SELECT INTO S3` 권한에 대한 대안입니다. 사용 정보는 [Amazon Aurora MySQL DB 클러스터에서 Amazon S3 버킷의 텍스트 파일로 데이터 저장](AuroraMySQL.Integrating.SaveIntoS3.md) 섹션을 참조하세요. + `AWS_COMPREHEND_ACCESS` – `INVOKE COMPREHEND` 권한에 대한 대안입니다. 사용 정보는 [데이터베이스 사용자에게 Aurora 기계 학습에 대한 액세스 권한 부여](mysql-ml.md#aurora-ml-sql-privileges) 섹션을 참조하세요. + `AWS_SAGEMAKER_ACCESS` – `INVOKE SAGEMAKER` 권한에 대한 대안입니다. 사용 정보는 [데이터베이스 사용자에게 Aurora 기계 학습에 대한 액세스 권한 부여](mysql-ml.md#aurora-ml-sql-privileges) 섹션을 참조하세요. + `AWS_BEDROCK_ACCESS` – Amazon Bedrock에는 유사한 `INVOKE` 권한이 없습니다. 사용 정보는 [데이터베이스 사용자에게 Aurora 기계 학습에 대한 액세스 권한 부여](mysql-ml.md#aurora-ml-sql-privileges) 섹션을 참조하세요. Aurora MySQL 버전 3에서 역할을 사용하여 액세스 권한을 부여하는 경우 `SET ROLE role_name` 또는 `SET ROLE ALL` 문을 사용하여 해당 역할을 활성화합니다. 다음 예에서는 이 작업을 수행하는 방법을 보여줍니다. 적합한 역할 이름을 `AWS_SELECT_S3_ACCESS`로 대체합니다. ``` # Grant role to user. mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +-----------------------------------------------------+ | CURRENT_ROLE() | +-----------------------------------------------------+ | `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` | +-----------------------------------------------------+ ``` ## 데이터베이스 서버 ID 찾기 데이터베이스 서버 ID(`server_id`)는 이진 로깅(binlog) 복제에 필요합니다. 서버 ID를 찾는 방법은 Aurora MySQL과 커뮤니티 MySQL이 다릅니다. 커뮤니티 MySQL에서 서버 ID는 서버에 로그인한 상태에서 다음 구문을 사용하여 얻는 숫자입니다. ``` mysql> select @@server_id; +-------------+ | @@server_id | +-------------+ | 2 | +-------------+ 1 row in set (0.00 sec) ``` Aurora MySQL에서 서버 ID는 DB 인스턴스에 로그인한 상태에서 다음 구문을 사용하여 얻는 DB 인스턴스 ID입니다. ``` mysql> select @@aurora_server_id; +------------------------+ | @@aurora_server_id | +------------------------+ | mydbcluster-instance-2 | +------------------------+ 1 row in set (0.00 sec) ``` Binlog 복제에 대한 자세한 내용은 [Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제](AuroraMySQL.Replication.MySQL.md) 섹션을 참조하세요. ## Authentication 커뮤니티 MySQL 8.0에서 기본 인증 플러그인은 `caching_sha2_password`입니다. Aurora MySQL 버전 3은 여전히 `mysql_native_password` 플러그인을 사용합니다. `default_authentication_plugin` 설정은 변경할 수 없습니다. 그러나 새 사용자를 생성하고 현재 사용자를 변경할 수 있으며 개별 암호는 새 인증 플러그인을 사용합니다. 다음은 한 예입니다. ``` mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword'; Query OK, 0 rows affected (0.74 sec) ``` # Aurora MySQL 버전 3으로 업그레이드 Aurora MySQL 버전 2에서 버전 3으로 데이터베이스를 업그레이드하는 내용은 [DB 클러스터의 Amazon Aurora MySQL 메이저 버전 업그레이드](AuroraMySQL.Updates.MajorVersionUpgrade.md) 섹션을 참고하시기 바랍니다.