Aurora MySQL 버전 3과 MySQL 8.0 커뮤니티 에디션 비교

원본 문서: Comparing Aurora MySQL version 3 and MySQL 8.0 Community Edition

다음 정보를 통해 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 데이터베이스 엔진 업데이트를 참조하세요.

Aurora MySQL 버전 3에서 제공되지 않는 MySQL 8.0 기능

MySQL 8.0 커뮤니티 에디션의 다음 기능은 Aurora MySQL 버전 3에서 지원되지 않거나 다르게 작동합니다.

• 리소스 그룹 기능과 및 관련 SQL 문은 Aurora MySQL에서 지원되지 않습니다.
• CREATE UNDO TABLESPACE, ALTER UNDO TABLESPACE ... SET INACTIVE, DROP UNDO TABLESPACE와 같은 사용자 정의 undo 테이블스페이스 기능 및 관련 SQL 문은 Aurora MySQL에서 지원되지 않습니다.
• Aurora MySQL 3.06 버전 미만에서는 undo 테이블스페이스 절단(truncation)을 지원하지 않습니다. Aurora MySQL 3.06 이상 버전에서는 자동 undo 테이블스페이스 절단을 지원합니다.
• MySQL 플러그인의 설정을 수정할 수 없습니다.
• X 플러그인은 지원되지 않습니다.
• 멀티 소스 복제는 지원되지 않습니다.

역할 기반 권한 모델

Aurora MySQL 버전 3에서는 mysql 데이터베이스의 테이블을 직접 수정할 수 없습니다. 특히, mysql.user 테이블에 insert 하는 식으로 사용자 계정을 설정할 수 없으며, 대신 역할 기반 권한을 부여하는 SQL 문을 사용해야 합니다. 또한, mysql 데이터베이스에 스토어드 프로시저와 같은 다른 종류의 객체를 생성할 수 없습니다. mysql 테이블에 대한 쿼리는 여전히 가능합니다. 바이너리 로그 복제를 사용하는 경우, 소스 클러스터의 mysql 테이블에서 직접 수정한 작업들은 타겟 클러스터로 복제되지 않습니다.

어떤 경우에는 애플리케이션에서 mysql 테이블에 삽입하여 사용자나 객체를 생성하는 방식을 사용하고 있었을 수 있습니다. 이러한 경우에, 애플리케이션 코드를 수정하여 CREATE USER와 같은 SQL 문을 사용하도록 변경해야 합니다. 애플리케이션이 mysql 데이터베이스에 스토어드 프로시저나 다른 객체를 생성하는 경우에도, mysql이 아닌 다른 데이터베이스를 사용하여야 합니다.

외부 MySQL 데이터베이스에서 마이그레이션 시 데이터베이스 사용자 메타데이터를 내보내려면, mysqldump 대신 MySQL Shell 명령을 사용할 수 있습니다. 자세한 내용은 Instance Dump Utility, Schema Dump Utility, and Table Dump Utility를 참조하세요.

여러 사용자나 애플리케이션에 대한 권한 관리를 간소화하려면, CREATE ROLE 문을 사용하여 특정 권한 집합을 가진 역할을 생성할 수 있습니다. 그런 다음, GRANT 및 SET ROLE 문과 current_role 함수를 사용하여 역할을 사용자나 애플리케이션에 할당하고, 현재 역할을 전환하며, 활성화된 역할을 확인할 수 있습니다. MySQL 8.0의 역할 기반 권한 시스템에 대한 자세한 내용은 MySQL 참고 매뉴얼의 Using Roles를 참조하세요.

중요
애플리케이션에서 마스터 사용자를 직접 사용하지 않는 것이 좋습니다. 대신, 애플리케이션에 필요한 최소 권한을 가진 데이터베이스 사용자를 생성하여 사용하는 것이 최선의 방법입니다.

rds_superuser_role

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
• 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

rds_superuser_role 역할 정의에는 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 스토어드 프로시저를 호출하여 바이너리 로그 복제를 활성화하면 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 서비스 통합을 참조하세요. Aurora MySQL 버전 3은 다음과 같은 AWS 서비스 접근과 관련된 역할을 포함합니다:

• AWS_LAMBDA_ACCESS – INVOKE LAMBDA 권한에 대한 대체 롤 입니다. 자세한 내용은 Amazon Aurora MySQL DB 클러스터에서 Lambda 함수 호출을 참조하세요.
• AWS_LOAD_S3_ACCESS – LOAD FROM S3 권한에 대한 대체 롤 입니다. 자세한 내용은 Amazon S3 버킷의 텍스트 파일에서 Amazon Aurora MySQL DB 클러스터로 데이터 로드를 참조하세요.
• AWS_SELECT_S3_ACCESS – SELECT INTO S3 권한에 대한 대체 롤 입니다. 자세한 내용은 Amazon Aurora MySQL DB 클러스터에서 Amazon S3 버킷으로 데이터 저장을 참조하세요.
• AWS_COMPREHEND_ACCESS – INVOKE COMPREHEND 권한에 대한 대체 롤 입니다. 자세한 내용은 Aurora 머신 러닝에 대한 데이터베이스 사용자 접근 권한 부여를 참조하세요.
• AWS_SAGEMAKER_ACCESS – INVOKE SAGEMAKER 권한에 대한 대체 롤 입니다. 자세한 내용은 Aurora 머신 러닝에 대한 데이터베이스 사용자 접근 권한 부여를 참조하세요.
• AWS_BEDROCK_ACCESS – Amazon Bedrock에는 대응되는 INVOKE 권한이 없습니다. 자세한 내용은 Aurora 머신 러닝에 대한 데이터베이스 사용자 접근 권한 부여를 참조하세요.

Aurora MySQL 버전 3에서 역할을 사용하여 접근 권한을 부여할 때는, 부여만 한다고 끝이 아니라, SET ROLE role_name 또는 SET ROLE ALL 문을 사용하여 부여받은 역할을 활성화해야 합니다. 다음 예제에서 어떻게 관리하는지 그 방법을 보여줍니다. AWS_SELECT_S3_ACCESS 부분은 적절한 역할 이름으로 대체하십시오.

# 사용자에게 역할 부여

mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address';

# 현재 사용자의 활성화된 역할을 확인합니다. 이 경우, AWS_SELECT_S3_ACCESS 역할이 아직 활성화되지 않았으며,
# rds_superuser_role만 적용되고 있습니다.
mysql> SELECT CURRENT_ROLE();
+--------------------------+
| CURRENT_ROLE()           |
+--------------------------+
| `rds_superuser_role`@`%` |
+--------------------------+
1 row in set (0.00 sec)

# SET ROLE을 사용하여 이 사용자와 관련된 모든 역할을 활성화합니다.
# 특정 역할만 활성화 할 수도 있고, 모든 역할을 한번에 활성화할 수도 있습니다.
# 이 경우, 사용자가 가지고 있는 역할이 2개 뿐이므로, ALL을 지정하여 2개를 한번에 활성화 합니다. 
# (grant는 롤을 부여하는 것이고, set role은 부여받은 롤중에 선택해서 활성화 하는건데, 
# 지금 엄청 많은 롤이 있는게 아니라 달랑 2개 뿐이니까 그냥 ALL로 활성화해서, 한번에 2개 다 활성화 하겠다 라는 의미)
mysql> SET ROLE ALL;
Query OK, 0 rows affected (0.00 sec)

# 역할이 활성화되었는지 확인합니다.
mysql> SELECT CURRENT_ROLE();
+-----------------------------------------------------+
| CURRENT_ROLE()                                      |
+-----------------------------------------------------+
| `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` |
+-----------------------------------------------------+

인증

MySQL 8.0 커뮤니티 에디션에서는 기본 인증 플러그인으로 caching_sha2_password가 사용됩니다. 하지만 Aurora MySQL 버전 3에서는 여전히 mysql_native_password 플러그인을 사용하며, default_authentication_plugin 설정을 변경할 수 없습니다.