' for the table to apply all the pending DDL updates. Then try the upgrade again."
}
]
}
```
사전 확인은 테이블 `test.test`에 보류 중인 빠른 DDL 작업이 있음을 보고합니다.
업그레이드를 계속하려면 테이블을 다시 빌드한 다음 업그레이드를 다시 시도할 수 있습니다.
테이블스페이스를 다시 빌드하기 전에 MySQL 설명서의 [온라인 DDL 작업](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html)을 참조하여 잠금 및 데이터 이동이 전경 트랜잭션에 미치는 영향을 이해하세요.
```
mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status | OK |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)
```
테이블을 다시 빌드한 후 사전 확인이 성공합니다.
```
{
"id": "auroraFODUpgradeCheck",
"title": "Check for artifacts related to Aurora fast DDL feature",
"status": "OK",
"detectedProblems": []
}
```
**auroraGetDanglingFulltextIndex**
**사전 확인 수준: 오류**
**누락된 `FULLTEXT` 인덱스 참조가 있는 테이블**
MySQL 5.6.26 이전에는 전체 텍스트 검색 인덱스를 삭제한 후 숨겨진 `FTS_DOC_ID` 및 `FTS_DOC_ID_INDEX` 열이 분리될 수 있었습니다. 자세한 내용은 [버그 \$176012](https://bugs.mysql.com/bug.php?id=76012)를 참조하세요.
이러한 문제가 발생한 이전 버전의 MySQL에서 테이블이 생성된 경우 Aurora MySQL 버전 3으로의 업그레이드가 실패할 수 있습니다. 이 사전 확인은 MySQL 8.0으로 업그레이드하기 전에 DB 클러스터에 이렇게 분리되었거나 누락된 전체 텍스트 인덱스가 없는지 확인합니다. 이 사전 확인이 실패하면 이러한 누락된 전체 텍스트 인덱스가 포함된 테이블을 다시 빌드합니다.
**출력 예제:**
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.table_with_fts_index",
"description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
}
]
},
```
`test.table_with_fts_index` 테이블에 누락된 전체 텍스트 인덱스가 포함되어 있으므로 사전 확인은 테이블에 대한 오류를 보고합니다. 업그레이드를 진행하려면 테이블을 다시 빌드하여 전체 텍스트 인덱스 보조 테이블을 정리합니다. `OPTIMIZE TABLE test.table_with_fts_index` 또는 `ALTER TABLE test.table_with_fts_index, ENGINE=INNODB`를 사용합니다.
테이블을 다시 빌드한 후 사전 확인이 통과됩니다.
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**사전 확인 수준: 오류**
**`ibd` 파일 경로와 관련된 불일치 확인**
이 사전 확인은 Aurora MySQL 버전 3.03.0 이하에만 적용됩니다. 이 사전 확인에 오류가 발생하면 Aurora MySQL 버전 3.04 이상으로 업그레이드하세요.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForDatafilePathInconsistency",
"title": "Check for inconsistency related to ibd file path.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**사전 확인 수준: 오류**
**스페이스 ID가 0인 전체 텍스트 인덱스 확인**
MySQL에서 InnoDB 테이블에 [전체 텍스트 인덱스](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html)를 추가하면 여러 보조 인덱스 테이블스페이스가 생성됩니다. 이전 버전의 MySQL에 [버그](https://bugs.mysql.com/bug.php?id=72132)(버전 5.6.20에서 수정됨)가 있어 이러한 보조 인덱스 테이블이 자체 InnoDB 테이블스페이스가 아닌 [시스템 테이블스페이스](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace)에 생성되었을 수 있습니다.
이러한 보조 테이블스페이스가 있는 경우 업그레이드가 실패합니다. 사전 확인 오류에 언급된 전체 텍스트 인덱스를 다시 생성한 다음 업그레이드를 다시 시도합니다.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.fts_space_zero_check",
"description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
}
]
},
```
사전 확인은 시스템 테이블스페이스에 보조 전체 텍스트 검색(FTS) 테이블이 있으므로 `test.fts_space_zero_check` 테이블에 대한 오류를 보고합니다.
이 테이블과 연결된 FTS 인덱스를 삭제하고 다시 생성하면 사전 확인이 성공합니다.
테이블스페이스를 다시 빌드하기 전에 MySQL 설명서의 [파티셔닝 작업](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning)을 참조하여 잠금 및 데이터 이동이 전경 트랜잭션에 미치는 영향을 이해합니다.
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**사전 확인 수준: 오류**
**준비된 상태의 XA 트랜잭션 확인**
메이저 버전 업그레이드 프로세스를 실행하는 동안 Aurora MySQL 버전 2 DB 인스턴스가 [완전히 종료](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)되는 것이 중요합니다. 이렇게 하면 모든 트랜잭션이 커밋되거나 롤백되고 InnoDB가 모든 실행 취소 로그 레코드를 제거하게 됩니다. 트랜잭션 롤백이 필요하기 때문에 데이터베이스에 준비된 상태의 [XA 트랜잭션](https://dev.mysql.com/doc/refman/5.7/en/xa.html)이 있는 경우 완전한 종료가 계속되는 것을 차단할 수 있습니다. 따라서 준비된 XA 트랜잭션이 감지되면 커밋 또는 롤백 작업을 수행할 때까지 업그레이드를 진행할 수 없습니다.
`XA RECOVER`를 사용하여 준비된 상태의 XA 트랜잭션을 찾는 방법에 대한 자세한 내용은 MySQL 설명서의 [XA 트랜잭션 SQL 문](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html)을 참조하세요. XA 트랜잭션 상태에 대한 자세한 내용은 MySQL 설명서의 [XA 트랜잭션 상태](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html)를 참조하세요.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
}
]
}
```
이 사전 확인은 커밋하거나 롤백해야 하는 준비된 상태의 트랜잭션이 있기 때문에 오류를 보고합니다.
데이터베이스에 로그인한 후 [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) 테이블과 `XA RECOVER` 출력에서 자세한 내용을 확인할 수 있습니다.
트랜잭션을 커밋하거나 롤백하기 전에 [MySQL 설명서](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html)와 애플리케이션 요구 사항을 검토하는 것이 좋습니다.
```
mysql> select trx_started,
trx_mysql_thread_id,
trx_id,trx_state,
trx_operation_state,
trx_rows_modified,
trx_rows_locked
from
information_schema.innodb_trx;
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| trx_started | trx_mysql_thread_id | trx_id | trx_state | trx_operation_state | trx_rows_modified | trx_rows_locked |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| 2024-08-12 01:09:39 | 0 | 2849470 | RUNNING | NULL | 1 | 0 |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
1 row in set (0.00 sec)
mysql> xa recover;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+--------+
| 1 | 6 | 0 | xatest |
+----------+--------------+--------------+--------+
1 row in set (0.00 sec)
```
이 경우 준비된 트랜잭션을 롤백합니다.
```
mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)
```
XA 트랜잭션이 롤백되면 사전 확인이 성공합니다.
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**사전 확인 수준: 오류**
**현재 인스턴스 클래스에서 업그레이드가 지원되는지 확인**
라이터 [DB 인스턴스 클래스](Concepts.DBInstanceClass.md)가 db.r6i.32xlarge인 Aurora MySQL 버전 2.12.0 또는 2.12.1에서 현재 위치 업그레이드를 실행하는 것은 현재 지원되지 않습니다. 이 경우 사전 확인은 오류를 반환합니다. 업그레이드를 계속하려면 DB 인스턴스 클래스를 db.r6i.24xlarge 이하로 변경할 수 있습니다. 또는 Aurora MySQL 버전 2.12.2 이상으로 업그레이드할 수 있습니다. 여기서 Aurora MySQL 버전 3으로의 현재 위치 업그레이드는 db.r6i.32xlarge에서 지원됩니다.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForInstanceLimit",
"title": "Checks if upgrade is supported on the current instance class",
"status": "OK",
"description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
}
]
},
```
사전 확인은 라이터 DB 인스턴스가 db.r6i.32xlarge 인스턴스 클래스를 사용하고 Aurora MySQL 버전 2.12.1에서 실행 중이므로 오류를 반환합니다.
**auroraUpgradeCheckForInternalUsers**
**사전 확인 수준: 오류**
**8.0 내부 사용자 확인**
이 사전 확인은 Aurora MySQL 버전 3.03.0 이하에만 적용됩니다. 이 사전 확인에 오류가 발생하면 Aurora MySQL 버전 3.04 이상으로 업그레이드하세요.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForInternalUsers",
"title": "Check for 8.0 internal users.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForMasterUser**
**사전 확인 수준: 오류**
**RDS 마스터 사용자가 존재하는지 확인**
MySQL 8에는 권한 관리를 더 쉽고 세밀하게 만들 수 있도록 [역할](https://dev.mysql.com/doc/refman/8.0/en/roles.html)과 [동적 권한](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges)을 지원하는 새로운 권한 모델이 추가되었습니다. 이 변경 사항의 일환으로 Aurora MySQL은 Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때 데이터베이스의 마스터 사용자에게 자동으로 부여되는 새로운 `rds_superuser_role`을 도입했습니다.
Aurora MySQL에서 마스터 사용자에게 할당되는 역할 및 권한에 대한 자세한 내용은 [마스터 사용자 계정 권한](UsingWithRDS.MasterAccounts.md) 섹션을 참조하세요. Aurora MySQL 버전 3의 역할 기반 권한 모델에 대한 자세한 내용은 [역할 기반 권한 모델](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model) 섹션을 참조하세요.
이 사전 확인은 마스터 사용자가 데이터베이스에 있는지 확인합니다. 마스터 사용자가 없는 경우 사전 확인이 실패합니다. 업그레이드를 계속하려면 마스터 사용자 암호를 재설정하거나 사용자를 수동으로 생성하여 마스터 사용자를 다시 생성합니다. 그런 다음 업그레이드를 다시 시도하세요. 마스터 사용자 암호 재설정에 대한 자세한 내용은 [데이터베이스 마스터 사용자의 암호 변경](Aurora.Modifying.md#Aurora.Modifying.Password) 섹션을 참조하세요.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForMasterUser",
"title": "Check if master user exists",
"status": "OK",
"description": "Throws error if master user has been dropped!",
"documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
}
]
}
```
마스터 사용자 암호를 재설정하면 사전 확인이 통과되고 업그레이드를 다시 시도할 수 있습니다.
다음 예제에서는 AWS CLI를 사용하여 암호를 재설정합니다. 암호 변경 사항이 바로 적용됩니다.
```
aws rds modify-db-cluster \
--db-cluster-identifier my-db-cluster \
--master-user-password my-new-password
```
그러면 사전 확인이 성공합니다.
```
{
"id": "auroraUpgradeCheckForMasterUser",
title": "Check if master user exists",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**사전 확인 수준: 오류**
**접두사 인덱스의 지오메트리 열 확인**
[MySQL 8.0.12](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-12.html#mysqld-8-0-12-spatial-support)부터는 [GEOMETRY](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html) 데이터 유형을 사용하여 열에 [접두사](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) 인덱스를 더 이상 생성할 수 없습니다. 자세한 내용은 [WL\$111808](https://dev.mysql.com/worklog/task/?id=11808)을 참조하세요.
이러한 인덱스가 있으면 업그레이드가 실패합니다. 문제를 해결하려면 사전 확인 실패에 언급된 테이블에 접두사가 붙은 `GEOMETRY` 인덱스를 삭제합니다.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.geom_index_prefix",
"description": "Table `test`.`geom_index_prefix` has an index `LatLon` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `LatLon` ON `test`.`geom_index_prefix`;"
}
]
}
```
`test.geom_index_prefix` 테이블에 `GEOMETRY` 열에 접두사가 있는 인덱스가 포함되어 있기 때문에 사전 확인은 오류를 보고합니다.
이 인덱스를 삭제하면 사전 확인이 성공합니다.
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**사전 확인 수준: 오류**
**저장된 프로시저의 특수 문자와 관련된 불일치 확인**
MySQL 8.0 이전에는 데이터베이스 이름, 테이블 이름 및 기타 객체가 데이터 디렉터리의 파일, 즉 파일 기반 메타데이터에 상응했습니다. MySQL 8.0으로 업그레이드하는 과정에서 모든 데이터베이스 객체가 `mysql` 스키마에 저장된 새 내부 데이터 딕셔너리 테이블로 마이그레이션되어 새로 구현된 [원자성 데이터 딕셔너리](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html)를 지원합니다. 저장된 프로시저를 마이그레이션하는 과정에서 각 프로시저의 프로시저 정의와 본문은 새 데이터 딕셔너리로 수집될 때 검증됩니다.
MySQL 8 이전에는 경우에 따라 저장된 루틴을 생성하거나 특수 문자가 포함된 프로시저인 `mysql.proc` 테이블에 직접 삽입할 수 있었습니다. 예를 들어 규정을 준수하지 않는 [줄 바꿈하지 않는 공백](https://en.wikipedia.org/wiki/Non-breaking_space) `\xa0`이 있는 주석이 포함된 저장 프로시저를 생성할 수 있습니다. 이러한 프로시저가 발생하면 업그레이드가 실패합니다.
이 사전 확인은 저장된 프로시저의 본문과 정의에 이러한 문자가 포함되어 있지 않은지 확인합니다. 업그레이드를 진행하려면 숨겨진 문자나 특수 문자 없이 이러한 저장된 프로시저를 다시 생성합니다.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"description": "Following procedure(s) has special characters inconsistency.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "information_schema.routines",
"description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
}
]
}
```
사전 확인은 DB 클러스터에 프로시저 본문에 특수 문자가 포함된 `test` 데이터베이스에 `get_version_proc`이라는 프로시저가 포함되어 있음을 보고합니다.
저장된 프로시저를 삭제하고 다시 생성한 후 사전 확인이 성공하여 업그레이드를 진행할 수 있습니다.
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**사전 확인 수준: 오류**
**`sys` 스키마에 대한 객체 유형 불일치 확인**
[sys 스키마](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html)는 사용자가 DB 인스턴스의 문제를 해결하고 최적화하고 모니터링하는 데 도움이 되는 MySQL 데이터베이스의 객체 및 뷰 세트입니다. Aurora MySQL 버전 2에서 버전 3으로 메이저 버전 업그레이드를 수행할 때 `sys` 스키마 뷰가 다시 생성되고 새 Aurora MySQL 버전 3 정의로 업데이트됩니다.
업그레이드의 일환으로 `sys` 스키마의 모든 객체가 뷰가 아닌 스토리지 엔진([INFORMATION\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html)의 `sys_config/BASE TABLE`)을 사용하여 정의된 경우 업그레이드가 실패합니다. 이러한 테이블은 `information_schema.tables` 테이블에서 찾을 수 있습니다. 이는 예상되는 동작은 아니지만 경우에 따라 사용자 오류로 인해 발생할 수 있습니다.
이 사전 확인은 스키마 객체가 올바른 테이블 정의를 사용하고 뷰가 InnoDB 또는 MyISAM 테이블로 잘못 정의되지 않았는지 확인하기 위해 모든 `sys` 스키마 객체를 검증합니다. 문제를 해결하려면 반환된 객체의 이름을 바꾸거나 삭제하여 수동으로 수정합니다. 그런 다음 업그레이드를 다시 시도하세요.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"description": "Database contains objects with type mismatch for sys schema.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "sys.waits_global_by_latency",
"description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
}
]
}
```
사전 확인은 `sys` 스키마의 [sys.waits\$1global\$1by\$1latency](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) 뷰에 유형 불일치가 있어 업그레이드가 진행되지 않는다고 보고합니다.
DB 인스턴스에 로그인한 후 이 객체가 뷰여야 하지만 InnoDB 테이블로 정의되어 있음을 확인할 수 있습니다.
```
mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
`events` varchar(128) DEFAULT NULL,
`total` bigint(20) unsigned DEFAULT NULL,
`total_latency` text,
`avg_latency` text,
`max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
이 문제를 해결하기 위해 뷰를 삭제하고 [올바른 정의](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql)로 다시 생성하거나 이름을 바꿀 수 있습니다. 업그레이드 프로세스 중에 올바른 테이블 정의로 자동으로 생성됩니다.
```
mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)
```
이렇게 하면 사전 확인이 통과됩니다.
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**사전 확인 수준: 오류**
**뷰에서 열 이름의 상한 확인**
MySQL에서 [열 이름의 최대 허용 길이는](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html) 64자입니다. MySQL 8.0 이전에는 열 이름이 64자보다 큰 뷰를 생성할 수 있었습니다. 데이터베이스 인스턴스에 이러한 뷰가 있는 경우 사전 확인 오류가 반환되고 업그레이드가 실패합니다. 업그레이드를 계속하려면 열 길이가 64자 미만으로 해당 뷰를 다시 생성해야 합니다. 그런 다음 업그레이드를 다시 시도하세요.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"description": "Following view(s) has column(s) with length greater than 64.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
"description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
}
]
}
```
사전 확인은 `test.colname_view_test` 뷰에 허용되는 최대 열 길이인 64자를 초과하는 열 `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad`가 포함되어 있음을 보고합니다.
뷰 정의에서 문제가 되는 열을 볼 수 있습니다.
```
mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11) | YES | | NULL | |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
업그레이드를 계속하려면 열 길이가 64자를 초과하지 않도록 뷰를 다시 생성하세요.
```
mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)
mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)
mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_nopad | int(11) | YES | | NULL | |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
이렇게 하면 사전 확인이 성공합니다.
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**사전 확인 수준: 오류**
**작은 열에서 접두사 길이가 255바이트를 초과하는 인덱스가 정의된 테이블 확인**
MySQL에서 [바이너리 데이터 유형](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html)을 사용하여 열에 인덱스를 생성할 때는 인덱스 정의에 [접두사](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) 길이를 추가해야 합니다. MySQL 8.0 이전에는 경우에 따라 이러한 데이터 유형의 최대 허용 크기보다 큰 접두사 길이를 지정할 수 있었습니다. 허용되는 최대 데이터 크기가 255바이트이지만 이보다 큰 인덱스 접두사가 허용된 `TINYTEXT` 및 `TINYBLOB` 열을 예로 들 수 있습니다. 자세한 내용은 MySQL 설명서의 [InnoDB 한도](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html)를 참조하세요.
이 사전 확인이 실패하면 문제가 되는 인덱스를 삭제하거나 인덱스에서 `TINYTEXT` 및 `TINYBLOB` 열의 접두사 길이를 255바이트 미만으로 줄입니다. 그런 다음 업그레이드를 다시 시도하세요.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.tintxt_prefixed_index.col1",
"description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
}
]
}
```
사전 확인은 TINYTEXT 또는 TINYBLOB 열에 접두사가 255바이트보다 큰 `PRIMARY` 인덱스가 있기 때문에 `test.tintxt_prefixed_index` 테이블에 대한 오류를 보고합니다.
이 테이블의 정의를 보면 `col1` 열의 `TINYTEXT`에서 프라이머리 키의 접두사가 65임을 알 수 있습니다. 테이블은 문자당 4바이트를 저장하는 `utf8mb4` 문자 세트를 사용하여 정의되므로 접두사가 255바이트 제한을 초과합니다.
```
mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
`col1` tinytext NOT NULL,
`col2` tinytext,
`col_id` tinytext,
PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)
```
`utf8mb4` 문자 세트를 사용하는 동안 인덱스 접두사를 63으로 수정하면 업그레이드를 진행할 수 있습니다.
```
mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0 Duplicates: 0 Warnings: 0
```
이렇게 하면 사전 확인이 성공합니다.
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**사전 확인 수준: 오류**
**`mysql.host` 테이블에 누락된 InnoDB 메타데이터 불일치 확인**
RDS 서비스에서 수행하는 내부 전용 사전 확인입니다. 모든 오류는 업그레이드 시 자동으로 처리되며 안전하게 무시할 수 있습니다.
이 사전 확인에 오류가 발생하면 [AWS 지원](https://aws.amazon.com/support)에서 사례를 열어 메타데이터 불일치를 해결하도록 요청합니다. 또는 논리적 덤프를 수행한 다음 새 Aurora MySQL 버전 3 DB 클러스터로 복원하여 업그레이드를 다시 시도할 수 있습니다.
**auroraUpgradeCheckForInvalidUtf8mb3ColumnComments**
**사전 확인 수준: 오류**
**잘못된 utf8mb3 열 주석 확인**
이 사전 확인은 잘못된 utf8mb3 문자 인코딩이 있는 열 주석이 포함된 테이블을 식별합니다. MySQL 8.0에서는 열 주석을 포함하여 메타데이터의 문자 인코딩에 더 엄격한 검증이 적용됩니다. utf8mb3 문자 집합에 유효하지 않은 문자가 포함된 열 주석이 있는 경우 업그레이드가 실패합니다.
이 문제의 가장 일반적인 원인은 열 주석에 기본 다국어 평면(BMP) 이외의 문자가 있는 것입니다. BMP 이외 문자에는 4바이트 UTF-8 인코딩(utf8mb4)이 필요한데 utf8mb3는 3바이트 시퀀스만 지원하여 이러한 문자를 나타낼 수 없습니다.
이 문제를 해결하려면 업그레이드를 시도하기 전에 열 주석을 수정하여 BMP 이외 문자를 제거하거나 바꿔야 합니다. `ALTER TABLE` 문을 사용하여 열 주석을 업데이트할 수 있습니다.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.t2",
"description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
}
```
사전 확인 결과, 특히 BMP 이외 문자로 인해 `test.t2` 테이블의 하나 이상의 열 주석에 잘못된 utf8mb3 문자가 포함되어 있는 것으로 나타났습니다.
이 문제를 해결하려면 문제가 있는 열을 식별하고 주석을 업데이트해야 합니다. 먼저 테이블 구조를 조사하여 주석이 있는 열을 식별합니다.
```
mysql> SHOW CREATE TABLE test.t2\G
```
문제가 있는 주석이 포함된 열을 식별한 후에는 `ALTER TABLE` 문을 사용하여 해당 열을 업데이트합니다. 예시:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
또는 주석을 완전히 제거할 수도 있습니다.
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
문제가 있는 열 주석을 모두 업데이트하면 사전 확인이 통과되고 업그레이드를 진행할 수 있습니다.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
열 주석을 수정하기 전에 이러한 주석에 의존하는 모든 애플리케이션 코드 또는 문서를 그에 따라 업데이트해야 합니다. 애플리케이션에 BMP 이외 문자가 필요한 경우 더 나은 유니코드 지원을 위해 utf8mb4 문자 집합으로 마이그레이션하는 것이 좋습니다.
## 경고
다음 사전 확인은 사전 확인이 실패할 때 경고를 생성하지만 업그레이드를 진행할 수 있습니다.
**Topics**
+ [경고를 보고하는 MySQL 사전 확인](#precheck-descriptions-warnings.mysql)
+ [경고를 보고하는 Aurora MySQL 사전 확인](#precheck-descriptions-warnings.aurora)
### 경고를 보고하는 MySQL 사전 확인
다음 사전 확인은 Community MySQL에서 가져온 것입니다.
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**사전 확인 수준: 경고**
**새로운 기본 인증 플러그인 고려 사항**
MySQL 8.0에는 `caching_sha2_password` 인증 플러그인이 도입되어 더 이상 사용되지 않는 `mysql_native_password` 플러그인보다 더 안전한 암호 암호화와 더 나은 성능을 제공합니다. Aurora MySQL 버전 3의 경우 데이터베이스 사용자에게 사용되는 기본 인증 플러그인은 `mysql_native_password` 플러그인입니다.
이 사전 확인은 이 플러그인이 제거되고 향후 메이저 버전 릴리스에서 기본값이 변경된다는 것을 경고합니다. 이 변경 전에 애플리케이션 클라이언트와 사용자의 호환성을 평가하는 것이 좋습니다.
자세한 내용은 MySQL 설명서의 [caching\$1sha2\$1password 호환성 문제 및 해결 방법](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues)을 참조하세요.
**출력 예제:**
```
{
"id": "defaultAuthenticationPlugin",
"title": "New default authentication plugin considerations",
"description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},
```
**maxdbFlagCheck**
**사전 확인 수준: 경고**
**더 이상 사용되지 않는 `MAXDB` `sql_mode` 플래그 사용**
MySQL 8.0에서는 더 이상 사용되지 않는 여러 [sql\$1mode](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode) 시스템 변수 옵션이 [제거](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)되었으며, 그 중 하나는 `MAXDB`였습니다. 이 사전 확인은 루틴 및 트리거와 함께 현재 연결된 모든 세션을 검사하여 `MAXDB`를 포함하는 조합으로 `sql_mode`가 설정된 세션이 없는지 확인합니다.
**출력 예제:**
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.maxdb_stored_routine",
"description": "PROCEDURE uses obsolete MAXDB sql_mode",
"dbObjectType": "Routine"
}
]
}
```
사전 확인은 `test.maxdb_stored_routine` 루틴에 지원되지 않는 `sql_mode` 옵션이 포함되어 있음을 보고합니다.
데이터베이스에 로그인한 후 루틴 정의에서 `sql_mode`에 `MAXDB`가 포함되어 있는 것을 볼 수 있습니다.
```
> SHOW CREATE PROCEDURE test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
문제를 해결하려면 클라이언트에서 올바른 `sql_mode`를 설정한 후 프로시저를 다시 생성합니다.
[MySQL 설명서](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html)에 따라 MySQL은 루틴이 생성되거나 변경될 때 적용되는 `sql_mode` 설정을 저장합니다. 루틴이 시작될 때의 `sql_mode` 설정에 관계없이 항상 이 설정으로 루틴을 실행합니다.
`sql_mode`를 변경하기 전에 MySQL 설명서의 [서버 SQL 모드](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html)를 참조하세요. 이 작업이 애플리케이션에 미치는 잠재적 영향을 신중하게 평가합니다.
지원되지 않는 `sql_mode`를 사용하지 않고 프로시저를 다시 생성합니다.
```
mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
-> SQL SECURITY DEFINER
-> BEGIN
-> SELECT * FROM test;
-> END$$
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
사전 확인에 성공합니다.
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"detectedProblems": []
}
```
**mysqlDollarSignNameCheck**
**사전 확인 수준: 경고**
**객체 이름에서 더 이상 사용되지 않는 단일 달러 기호 사용 확인**
[MySQL 8.0.32](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-32.html#mysqld-8-0-32-deprecation-removal)부터 인용되지 않은 식별자의 첫 번째 문자로 달러 기호(`$`)를 사용하는 것은 더 이상 지원되지 않습니다. `$` 기호를 첫 번째 문자로 포함하는 스키마, 테이블, 뷰, 열 또는 루틴이 있는 경우 이 사전 확인은 경고를 반환합니다. 이 경고로 인해 업그레이드가 차단되지는 않지만 이 문제를 해결하기 위해 조만간 조치를 취하는 것이 좋습니다. [MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html)에서 이러한 식별자는 경고가 아닌 구문 오류를 반환합니다.
**출력 예제:**
```
{
"id": "mysqlDollarSignNameCheck",
"title": "Check for deprecated usage of single dollar signs in object names",
"status": "OK",
"description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.$deprecated_syntx",
"description": " name starts with $ sign."
}
]
},
```
`test` 스키마의 `$deprecated_syntx` 테이블에는 `$` 기호가 첫 번째 문자로 포함되어 있으므로 사전 확인은 경고를 보고합니다.
**reservedKeywordsCheck**
**사전 확인 수준: 경고**
**이름이 예약된 새 키워드와 충돌하는 데이터베이스 객체 사용**
이 확인은 이름이 예약된 새 키워드와 충돌하는 데이터베이스 객체의 사용을 확인한다는 점에서 [routineSyntaxCheck](#routineSyntaxCheck)와 유사합니다. 업그레이드를 차단하지는 않지만 경고를 신중하게 평가해야 합니다.
**출력 예제:**
테이블 이름이 `except`인 이전 예제를 사용하면 사전 확인이 경고를 반환합니다.
```
{
"id": "reservedKeywordsCheck",
"title": "Usage of db objects with names conflicting with new reserved keywords",
"status": "OK",
"description": "Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.except",
"description": "Table name",
"dbObjectType": "Table"
}
]
}
```
이 경고를 통해 검토할 몇 가지 애플리케이션 쿼리가 있을 수 있음을 알 수 있습니다. 애플리케이션 쿼리가 [문자열 리터럴을 올바르게 이스케이프](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html)하지 않는 경우 MySQL 8.0으로 업그레이드한 후 오류가 발생할 수 있습니다. 애플리케이션을 검토하여 버전 3에서 실행되는 Aurora MySQL DB 클러스터의 복제본 또는 스냅샷을 기준으로 테스트하는 방법으로 확인합니다.
업그레이드 후 실패하는 이스케이프되지 않은 애플리케이션 쿼리의 예:
```
SELECT * FROM escape;
```
업그레이드 후 성공하는 올바르게 이스케이프된 애플리케이션 쿼리의 예:
```
SELECT * FROM 'escape';
```
**utf8mb3Check**
**사전 확인 수준: 경고**
**`utf8mb3` 문자 세트 사용**
MySQL 8.0에서는 `utf8mb3` 문자 세트가 더 이상 사용되지 않으며 향후 MySQL 메이저 버전에서 제거됩니다. 이 사전 확인은 이 문자 세트를 사용하는 데이터베이스 객체가 감지되는 경우 경고를 표시하기 위해 구현됩니다. 이렇게 해도 업그레이드가 차단되지는 않지만 테이블을 MySQL 8.0의 기본값인 `utf8mb4` 문자 세트로 마이그레이션하는 것이 좋습니다. [utf8mb3](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html) 및 [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html)에 대한 자세한 내용은 MySQL 설명서의 [3바이트와 4바이트 유니코드 문자 세트 간 변환](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html)을 참조하세요.
**출력 예제:**
```
{
"id": "utf8mb3",
"title": "Usage of utf8mb3 charset",
"status": "OK",
"description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.t1.col1",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
},
{
"level": "Warning",
"dbObject": "test.t1.col2",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
}
]
}
```
이 문제를 해결하기 위해 참조된 객체와 테이블을 다시 빌드합니다. 자세한 내용과 사전 요구 사항은 MySQL 설명서의 [3바이트와 4바이트 유니코드 문자 세트 간 변환](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html)을 참조하세요.
**zeroDatesCheck**
**사전 확인 수준: 경고**
**날짜, 날짜/시간 및 타임스탬프 값이 0임**
MySQL은 이제 날짜, 날짜/시간 및 타임스탬프 열에 0 값을 사용하는 것과 관련하여 더 엄격한 규칙을 적용합니다. `NO_ZERO_IN_DATE` 및 `NO_ZERO_DATE SQL` 모드는 향후 MySQL 릴리스에서 `strict` 모드와 병합되므로 `strict` 모드와 함께 사용하는 것이 좋습니다.
사전 확인을 실행할 때 데이터베이스 연결에 대한 `sql_mode` 설정에 이러한 모드가 포함되지 않으면 사전 확인에 경고가 발생합니다. 사용자는 여전히 값이 0인 날짜, 날짜/시간 및 타임스탬프 값을 삽입할 수 있습니다. 하지만 향후 동작이 변경되어 제대로 작동하지 않을 수 있으므로 0 값을 유효한 값으로 바꾸는 것이 좋습니다. 이는 경고이므로 업그레이드를 차단하지는 않지만 조치를 취하기 위한 계획을 시작하는 것이 좋습니다.
**출력 예제:**
```
{
"id": "zeroDatesCheck",
"title": "Zero Date, Datetime, and Timestamp values",
"status": "OK",
"description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
"documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "global.sql_mode",
"description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
},
{
"level": "Warning",
"dbObject": "session.sql_mode",
"description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
}
]
}
```
### 경고를 보고하는 Aurora MySQL 사전 확인
다음 사전 확인은 Aurora MySQL에만 적용됩니다.
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**사전 확인 수준: 경고**
**클러스터의 롤백 세그먼트 기록 목록 길이가 높은지 확인합니다.**
[auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions)에서 언급한 바와 같이 메이저 버전 업그레이드 프로세스를 실행하는 동안 Aurora MySQL 버전 2 DB 인스턴스가 [완전히 종료](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)되는 것이 중요합니다. 이렇게 하면 모든 트랜잭션이 커밋되거나 롤백되고 InnoDB가 모든 실행 취소 로그 레코드를 제거하게 됩니다.
DB 클러스터의 롤백 세그먼트 기록 목록 길이(HLL)가 길면 InnoDB가 실행 취소 로그 레코드 제거를 완료하는 데 걸리는 시간이 길어져 메이저 버전 업그레이드 프로세스 중에 가동 중지 시간이 길어질 수 있습니다. 사전 확인에서 DB 클러스터의 HLL이 높음을 감지하면 경고가 발생합니다. 이렇게 해도 업그레이드가 차단되지는 않지만 DB 클러스터의 HLL을 면밀히 모니터링하는 것이 좋습니다. 이를 낮은 수준으로 유지하면 메이저 버전 업그레이드 중에 필요한 가동 중지 시간이 줄어듭니다. HLL 모니터링에 대한 자세한 내용은 [InnoDB 기록 목록 길이가 크게 늘어남](proactive-insights.history-list.md) 섹션을 참조하세요.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
"title": "Checks if the rollback segment history length for the cluster is high",
"status": "OK",
"description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_metrics",
"description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
}
]
}
```
사전 확인은 데이터베이스 클러스터(82989114)에서 InnoDB 실행 취소 HLL이 높음을 감지했기 때문에 경고를 반환합니다. 업그레이드는 진행되지만 제거를 위한 실행 취소의 양에 따라 업그레이드 프로세스 중에 필요한 가동 중지 시간이 연장될 수 있습니다.
프로덕션에서 업그레이드를 실행하기 전에 DB 클러스터에서 [열린 트랜잭션을 조사](proactive-insights.history-list.md)하여 HLL이 관리 가능한 크기로 유지되도록 하는 것이 좋습니다.
**auroraUpgradeCheckForUncommittedRowModifications**
**사전 확인 수준: 경고**
**커밋되지 않은 행 수정이 많은지 확인**
[auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions)에서 언급한 바와 같이 메이저 버전 업그레이드 프로세스를 실행하는 동안 Aurora MySQL 버전 2 DB 인스턴스가 [완전히 종료](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)되는 것이 중요합니다. 이렇게 하면 모든 트랜잭션이 커밋되거나 롤백되고 InnoDB가 모든 실행 취소 로그 레코드를 제거하게 됩니다.
DB 클러스터에 많은 수의 행을 수정한 트랜잭션이 있는 경우 완전한 종료 프로세스의 일부로 InnoDB이 트랜잭션의 롤백을 완료하는 데 걸리는 시간이 연장될 수 있습니다. 사전 확인에서 DB 클러스터에 많은 수의 수정된 행이 있는 장기 실행 트랜잭션을 찾으면 경고가 발생합니다. 이렇게 해도 업그레이드가 차단되지는 않지만 DB 클러스터의 활성 트랜잭션 크기를 면밀히 모니터링하는 것이 좋습니다. 이를 낮은 수준으로 유지하면 메이저 버전 업그레이드 중에 필요한 가동 중지 시간이 줄어듭니다.
**출력 예제:**
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_trx",
"description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
}
]
},
```
사전 확인은 DB 클러스터에 11,000,000개의 커밋되지 않은 행 변경 사항이 있는 트랜잭션이 포함되어 있음을 보고합니다. 이 트랜잭션은 완전한 종료 프로세스 중에 롤백해야 합니다. 업그레이드가 진행되지만 업그레이드 프로세스 중 가동 중지 시간을 줄이려면 프로덕션 클러스터에서 업그레이드를 실행하기 전에 이를 모니터링하고 조사하는 것이 좋습니다.
라이터 DB 인스턴스에서 활성 트랜잭션을 보려면 [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) 테이블을 사용할 수 있습니다. 라이터 DB 인스턴스에 대한 다음 쿼리는 DB 클러스터의 현재 트랜잭션, 실행 시간, 상태 및 수정된 행을 보여줍니다.
```
# Example of uncommitted transaction
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 | 1592 | 20041 | 52866130 | RUNNING | 11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)
# Example of transaction rolling back
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 | 1719 | 20041 | 52866130 | ROLLING BACK | 10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)
```
트랜잭션이 커밋되거나 롤백된 후에는 사전 확인이 더 이상 경고를 반환하지 않습니다. 대규모 트랜잭션을 롤백하기 전에 MySQL 설명서와 애플리케이션 팀에 문의하세요. 롤백이 완료되려면 트랜잭션 크기에 따라 시간이 걸릴 수 있습니다.
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"detectedProblems": []
},
```
InnoDB 트랜잭션 관리 최적화와 MySQL 데이터베이스 인스턴스에서 대규모 트랜잭션 실행 및 롤백의 잠재적 영향에 대한 자세한 내용은 MySQL 설명서의 [InnoDB 트랜잭션 관리 최적화](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)를 참조하세요.
## 고지 사항
다음 사전 확인은 사전 확인이 실패하면 알림을 생성하지만 업그레이드를 진행할 수 있습니다.
**sqlModeFlagCheck**
**사전 확인 수준: 알림**
**더 이상 사용되지 않는 `sql_mode` 플래그 사용**
`MAXDB` 외에도 `DB2`, `MSSQL`, `MYSQL323`, `MYSQL40`, `ORACLE`, `POSTGRESQL`, `NO_FIELD_OPTIONS`, `NO_KEY_OPTIONS` 및 `NO_TABLE_OPTIONS` 등의 다른 `sql_mode` 옵션이 [제거](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)되었습니다. MySQL 8.0부터 이러한 값 중 어느 것도 `sql_mode` 시스템 변수에 할당할 수 없습니다. 이 사전 확인에서 이러한 `sql_mode` 설정을 사용하여 열려 있는 세션을 찾으면 DB 인스턴스 및 DB 클러스터 파라미터 그룹과 클라이언트 애플리케이션 및 구성을 업데이트하여 비활성화해야 합니다. 자세한 내용은 [MySQL 설명서](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)를 참조하세요.
**출력 예제:**
```
{
"id": "sqlModeFlagCheck",
"title": "Usage of obsolete sql_mode flags",
"status": "OK",
"detectedProblems": []
}
```
이러한 사전 확인 실패를 해결하려면 [maxdbFlagCheck](#maxdbFlagCheck)를 참조하세요.
## 오류, 경고 또는 알림
다음 사전 확인은 사전 확인 출력에 따라 오류, 경고 또는 알림을 반환할 수 있습니다.
**checkTableOutput**
**사전 확인 수준: 오류, 경고 또는 알림**
**`check table x for upgrade` 명령에서 보고되는 문제**
Aurora MySQL 버전 3으로 업그레이드를 시작하기 전에 `check table for upgrade`는 DB 클러스터의 사용자 스키마에 있는 각 테이블에서 실행됩니다. 이 사전 확인은 [checkTableMysqlSchema](#checkTableMysqlSchema)와 동일하지 않습니다.
`check table for upgrade` 명령은 최신 버전의 MySQL로 업그레이드하는 동안 발생할 수 있는 잠재적 문제가 있는지 테이블을 검사합니다. 업그레이드를 시도하기 전에 이 명령을 실행하면 비호환성을 미리 식별하고 해결하는 데 도움이 되므로 실제 업그레이드 프로세스가 더 원활해집니다.
이 명령은 각 테이블에 대해 다음과 같은 다양한 검사를 수행합니다.
+ 테이블 구조 및 메타데이터가 대상 MySQL 버전과 호환되는지 확인
+ 더 이상 사용되지 않거나 제거된 기능이 테이블에서 사용되고 있는지 확인
+ 데이터 손실 없이 테이블을 올바르게 업그레이드할 수 있는지 확인
다른 사전 확인과 달리 `check table` 출력에 따라 오류, 경고 또는 알림을 반환할 수 있습니다. 이 사전 확인에서 테이블을 반환하는 경우 업그레이드를 시작하기 전에 반환 코드 및 메시지와 함께 테이블을 주의 깊게 검토합니다. 자세한 내용은 MySQL 설명서의 [CHECK TABLE 문](https://dev.mysql.com/doc/refman/5.7/en/check-table.html)을 참조하세요.
여기서는 오류 예제와 경고 예제를 제공합니다.
**오류 예제**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.parent",
"description": "Table 'test.parent' doesn't exist"
}
]
},
```
사전 확인은 `test.parent` 테이블이 존재하지 않는다는 오류를 보고합니다.
라이터 DB 인스턴스의 `mysql-error.log` 파일에 외래 키 오류가 있는 것으로 표시됩니다.
```
2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
```
라이터 DB 인스턴스에 로그인하고 `show engine innodb status\G`를 실행하여 외래 키 오류에 대한 자세한 정보를 얻습니다.
```
mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.
```
이 `LATEST FOREIGN KEY ERROR` 메시지는 `test.parent` 테이블을 참조하는 `test.child` 테이블의 `fk_pname` 외래 키 제약 조건에 누락된 인덱스 또는 데이터 유형 불일치가 있음을 보고합니다. [외래 키 제약 조건](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html)에 대한 MySQL 설명서에는 외래 키에서 참조되는 열에 연결된 인덱스가 있어야 하고 상위/하위 열은 동일한 데이터 유형을 사용해야 한다고 명시되어 있습니다.
누락된 인덱스 또는 데이터 유형 불일치와 관련이 있는지 확인하려면 데이터베이스에 로그인하고 세션 변수 [foreign\$1key\$1checks](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#foreign-key-checks)를 일시적으로 비활성화하여 테이블 정의를 확인합니다. 이렇게 하면 문제의 하위 제약 조건(`fk_pname`)이 상위 테이블 `name varchar(20) NOT NULL`을 참조하는 데 `p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL`을 사용하는 것을 확인할 수 있습니다. 상위 테이블은 `DEFAULT CHARSET=utf8`을 사용하지만 하위 테이블의 `p_name` 열은 `latin1`을 사용하므로 데이터 유형 불일치 오류가 발생합니다.
```
mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)
mysql> show create table parent\G
*************************** 1. row ***************************
Table: parent
Create Table: CREATE TABLE `parent` (
`name` varchar(20) NOT NULL,
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
이 문제를 해결하기 위해 하위 테이블을 상위 테이블과 동일한 문자 세트를 사용하도록 변경하거나 상위 테이블을 하위 테이블과 동일한 문자 세트를 사용하도록 변경할 수 있습니다. 여기서 하위 테이블은 `p_name` 열 정의에서 명시적으로 `latin1`을 사용하기 때문에 `ALTER TABLE`을 실행하여 문자 세트를 `utf8`로 수정합니다.
```
mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)
```
이렇게 하면 사전 확인이 통과되고 업그레이드를 진행할 수 있습니다.
**경고 예:**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.orders",
"description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
}
]
}
```
사전 확인은 `CREATED` 속성이 없기 때문에 `test.orders` 테이블에 `delete_audit_trigg` 트리거에 대한 경고를 보고합니다. MySQL 설명서의 [버전 호환성 확인](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-version-compatibility)에 따르면 이 메시지는 정보 제공용이며 MySQL 5.7.2 이전에 생성된 트리거에 대해 표시됩니다.
이는 경고이므로 업그레이드를 계속 진행하지 못하도록 차단하지 않습니다. 그러나 문제를 해결하려면 해당 트리거를 다시 생성할 수 있으며 사전 확인이 성공하고 경고가 표시되지 않습니다.
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": []
},
```
# 현재 위치 업그레이드 수행 방법
[Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence)의 배경 자료를 검토하는 것이 좋습니다.
[Aurora MySQL 클러스터에 대한 주 버전 업그레이드 계획](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning)에 설명된 대로 사전 업그레이드 계획 및 테스트를 수행합니다.
## 콘솔
다음 예제에서는 `mydbcluster-cluster` DB 클러스터를 Aurora MySQL 버전 3.04.1로 업그레이드합니다.
**Aurora MySQL DB 클러스터의 주 버전을 업그레이드하는 방법**
1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 AWS Management Console에 로그인한 후 Amazon RDS 콘솔을 엽니다.
1. 원래 DB 클러스터에 사용자 지정 파라미터 그룹을 사용한 경우 새 메이저 버전과 호환되는 해당 파라미터 그룹을 생성합니다. 새 파라미터 그룹의 구성 파라미터를 필요에 따라 조정합니다. 자세한 내용은 [현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향](#AuroraMySQL.Upgrading.ParamGroups) 섹션을 참조하세요.
1. 탐색 창에서 **데이터베이스**를 선택합니다.
1. 목록에서 수정할 DB 클러스터를 선택합니다.
1. **수정**을 선택합니다.
1. **버전**에 새 Aurora MySQL 메이저 버전을 선택합니다.
일반적으로 메이저 버전의 최신 마이너 버전을 사용하는 것이 좋습니다. 여기에서는 현재의 기본 버전을 선택합니다.
![\[Aurora MySQL DB 클러스터 버전 2에서 버전 3으로의 현재 위치 업그레이드\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. [**Continue**]를 선택합니다.
1. 다음 페이지에서 업그레이드 수행 시기를 지정합니다. **다음 예약된 유지 관리 기간 중** 또는 **즉시**를 선택합니다.
1. (선택 사항) 업그레이드하는 동안 RDS 콘솔에서 **이벤트** 페이지를 주기적으로 검사합니다. 이렇게 하면 업그레이드 진행 상황을 모니터링하고 모든 문제를 식별할 수 있습니다. 업그레이드에 문제가 발생하면 수행할 단계에 대한 [Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결](AuroraMySQL.Upgrading.Troubleshooting.md)를 참조하십시오.
1. 이 절차를 시작할 때 새 파라미터 그룹을 생성한 경우 사용자 지정 파라미터 그룹을 업그레이드된 클러스터와 연결합니다. 자세한 내용은 [현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향](#AuroraMySQL.Upgrading.ParamGroups) 단원을 참조하십시오.
**참고**
이 단계를 수행하려면 클러스터를 다시 시작하여 새 파라미터 그룹을 적용해야 합니다.
1. (선택 사항) 업그레이드 후 테스트를 완료한 후 Aurora이 업그레이드 시작 시 생성한 수동 스냅샷을 삭제합니다.
## AWS CLI
Aurora MySQL DB 클러스터의 메이저 버전을 업그레이드하려면 다음 필수 파라미터와 함께 AWS CLI [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 명령을 사용합니다.
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` 또는 `--no-apply-immediately`
클러스터에서 사용자 지정 파라미터 그룹을 사용하는 경우 다음 옵션 중 하나 또는 모두를 포함합니다.
+ `--db-cluster-parameter-group-name`클러스터가 사용자 지정 클러스터 파라미터 그룹을 사용하는 경우
+ `--db-instance-parameter-group-name`클러스터의 인스턴스가 사용자 지정 DB 파라미터 그룹을 사용하는 경우
다음 예제에서는 `sample-cluster` DB 클러스터를 Aurora MySQL 버전 3.04.1로 업그레이드합니다. 업그레이드는 다음 유지 관리 기간을 기다리는 대신 즉시 수행됩니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 8.0.mysql_aurora.3.04.1 \
--allow-major-version-upgrade \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 8.0.mysql_aurora.3.04.1 ^
--allow-major-version-upgrade ^
--apply-immediately
```
다른 CLI 명령을 `modify-db-cluster`와 결합하여 업그레이드 수행 및 확인을 위한 자동화된 종단 간 프로세스를 생성할 수 있습니다. 자세한 정보와 지침은 [Aurora MySQL 현재 위치 업그레이드 자습서](AuroraMySQL.Upgrading.Tutorial.md) 단원을 참조하십시오.
**참고**
클러스터가 Aurora 글로벌 데이터베이스의 일부라면 현재 위치 업그레이드 절차가 약간 다릅니다. [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) 명령 작업을 `modify-db-cluster` 대신 호출합니다. 자세한 내용은 [글로벌 데이터베이스에 대한 현재 위치 메이저 업그레이드](#AuroraMySQL.Upgrading.GlobalDB) 섹션을 참조하세요.
## RDS API
Aurora MySQL DB 클러스터의 메이저 버전을 업그레이드하려면 다음 필수 파라미터와 함께 RDS API 작업 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 사용합니다.
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` (`true` 또는 `false`로 설정)
**참고**
클러스터가 Aurora 글로벌 데이터베이스의 일부라면 현재 위치 업그레이드 절차가 약간 다릅니다. [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) 작업을 `ModifyDBCluster` 대신 호출합니다. 자세한 내용은 [글로벌 데이터베이스에 대한 현재 위치 메이저 업그레이드](#AuroraMySQL.Upgrading.GlobalDB) 섹션을 참조하세요.
## 현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향
Aurora 파라미터 그룹에는 MySQL 5.7 또는 8.0과 호환되는 클러스터에 대해 서로 다른 구성 설정 집합이 있습니다. 현재 위치 업그레이드를 수행할 때 업그레이드된 클러스터와 클러스터의 모든 인스턴스는 해당하는 클러스터 및 인스턴스 파라미터 그룹을 사용해야 합니다.
클러스터와 인스턴스는 기본 5.7 호환 파라미터 그룹을 사용할 수 있습니다. 그렇다면 업그레이드된 클러스터 및 인스턴스는 기본 8.0 호환 파라미터 그룹으로 시작합니다. 클러스터와 인스턴스가 사용자 지정 파라미터 그룹을 사용하는 경우 해당하는 8.0 호환 파라미터 그룹을 생성해야 합니다. 또한 업그레이드 프로세스 중에 이를 지정해야 합니다.
**참고**
대부분의 파라미터 설정에서는 두 지점에서 사용자 정의 파라미터 그룹을 선택할 수 있습니다. 클러스터를 만들 때와 나중에 파라미터 그룹을 클러스터와 연결할 때입니다.
그러나 `lower_case_table_names` 파라미터에 대해 기본값이 아닌 설정을 사용하는 경우 미리 이 설정으로 사용자 정의 파라미터 그룹을 설정해야 합니다. 그런 다음, 클러스터를 생성하기 위해 스냅샷 복원을 수행하는 경우 파라미터 그룹을 지정합니다. `lower_case_table_names` 파라미터에 대한 모든 변경은 클러스터를 생성한 후에는 효력이 없습니다.
Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때 `lower_case_table_names`에 동일한 설정을 사용하는 것이 좋습니다.
Aurora MySQL 기반 Aurora Global Database 사용 시 `lower_case_table_names` 파라미터가 활성화 되어 있는 경우 Aurora MySQL 버전 2에서 버전 3으로 현재 위치 업그레이드를 수행할 수 없습니다. 사용할 수 있는 메서드에 대한 자세한 내용은 [메이저 버전 업그레이드](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major) 섹션을 참조하세요.
**중요**
업그레이드 프로세스 중에 사용자 지정 파라미터 그룹을 지정하는 경우 업그레이드가 완료된 후 클러스터를 수동으로 재부팅해야 합니다. 이렇게 하면 클러스터가 사용자 지정 파라미터 설정을 사용하기 시작합니다.
## Aurora MySQL 버전 간의 클러스터 속성 변경
Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때는 Aurora MySQL 클러스터 및 DB 인스턴스를 설정하거나 관리하는 데 사용하는 애플리케이션 또는 스크립트를 변경해야 합니다.
또한 5.7 및 8.0 호환 클러스터에서 기본 파라미터 그룹 이름이 다르다는 사실을 설명하기 위해 파라미터 그룹을 조작하는 코드를 변경하세요. Aurora MySQL 버전 2 및 3 클러스터에 해당하는 기본 파라미터 그룹 이름은 각각 `default.aurora-mysql5.7` 및 `default.aurora-mysql8.0`입니다.
예를 들어 업그레이드 전에 클러스터에 적용되는 다음과 같은 코드가 있을 수 있습니다.
```
# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1
```
클러스터의 주 버전을 업그레이드한 후 다음과 같이 해당 코드를 수정합니다.
```
# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1
```
## 글로벌 데이터베이스에 대한 현재 위치 메이저 업그레이드
Aurora 글로벌 데이터베이스의 경우 글로벌 데이터베이스 클러스터를 업그레이드합니다. Aurora는 자동으로 모든 클러스터를 동시에 업그레이드하고 모든 클러스터가 동일한 엔진 버전을 실행하도록 합니다. 이 요구 사항은 시스템 테이블, 데이터 파일 형식 등에 대한 변경 내용이 모든 보조 클러스터에 자동으로 복제되기 때문입니다.
[Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence)의 지침을 따르세요. 업그레이드할 대상을 지정할 때 포함된 클러스터 중에서 대신 글로벌 데이터베이스 클러스터를 선택해야 합니다.
AWS Management Console을 사용하는 경우 **글로벌 데이터베이스(Global database)** 역할이 있는 항목을 선택합니다.
![\[글로벌 데이터베이스 클러스터 업그레이드\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
AWS CLI 또는 RDS API를 사용하는 경우에는 [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) 명령 또는 [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html) 작업을 호출하여 업그레이드 프로세스를 시작합니다. `modify-db-cluster` 또는 `ModifyDBCluster` 대신 이중 하나를 사용합니다.
**참고**
해당 Aurora Global Database의 메이저 버전 업그레이드를 수행하는 동안에는 글로벌 데이터베이스 클러스터에 대한 사용자 지정 파라미터 그룹을 지정할 수 없습니다. 전역 클러스터의 각 리전에 사용자 지정 파라미터 그룹을 생성합니다. 그런 다음 업그레이드 후 리전 클러스터에 수동으로 적용합니다.
AWS CLI를 사용하여 Aurora MySQL 글로벌 데이터베이스 클러스터의 메이저 버전을 업그레이드하려면 다음 필수 파라미터와 함께 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) 명령을 사용합니다.
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
다음 예에서는 글로벌 데이터베이스 클러스터를 Aurora MySQL 버전 2.10.2로 업그레이드합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine aurora-mysql \
--engine-version 5.7.mysql_aurora.2.10.2 \
--allow-major-version-upgrade
```
Windows의 경우:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine aurora-mysql ^
--engine-version 5.7.mysql_aurora.2.10.2 ^
--allow-major-version-upgrade
```
## 역추적 고려 사항
업그레이드한 클러스터에서 역추적 기능을 사용하도록 설정한 경우 업그레이드된 클러스터를 업그레이드 전의 시간으로 되돌릴 수 없습니다.
# Aurora MySQL 현재 위치 업그레이드 자습서
다음 Linux 예제에서는 AWS CLI를 사용하여 전체 업그레이드 절차의 일반적인 단계를 수행하는 방법을 보여 줍니다.
이 첫 번째 예시에서는 2.x 버전의 Aurora MySQL를 실행하는 Aurora DB 클러스터를 생성합니다. 클러스터에는 라이터 DB 인스턴스와 리더 DB 인스턴스가 포함됩니다. `wait db-instance-available` 명령은 라이터 DB 인스턴스를 사용할 수 있을 때까지 일시 중지됩니다. 이것이 바로 클러스터를 업그레이드할 준비가 된 시점입니다.
```
aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
--db-cluster-version 5.7.mysql_aurora.2.11.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
--db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
클러스터를 업그레이드할 수 있는 Aurora MySQL 3.x 버전은 클러스터가 현재 실행 중인 2.x 버전과 클러스터가 위치한 AWS 리전에 따라 다릅니다. `--output text`를 갖춘 첫 번째 명령은 사용 가능한 대상 버전만 표시합니다. 두 번째 명령은 응답의 전체 JSON 출력을 보여줍니다. 이 응답에서 `engine` 파라미터에 사용하는 `aurora-mysql` 값과 같은 세부 정보를 볼 수 있습니다. 또한 3.04.0으로의 업그레이드가 메이저 버전 업그레이드를 나타낸다는 사실을 알 수 있습니다.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.2 \
--query '*[].[ValidUpgradeTarget]'
...
{
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.04.0",
"Description": "Aurora MySQL 3.04.0 (compatible with MySQL 8.0.28)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": true,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsIntegrations": false
},
...
```
이 예에서는 클러스터에 유효한 업그레이드 대상이 아닌 대상 버전 번호를 입력하면 Aurora에서 업그레이드를 수행하지 않는 상황을 보여줍니다. Aurora는 또한 `--allow-major-version-upgrade` 파라미터를 포함하지 않으면 메이저 버전 업그레이드를 수행하지 않습니다. 이러면 애플리케이션 코드를 광범위하게 테스트하여 변경해야 할 가능성이 있는 업그레이드를 우연히 수행하게 될 수 없습니다.
```
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.11.2 with requested version 5.7.mysql_aurora.2.09.2.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --apply-immediately --allow-major-version-upgrade
{
"DBClusterIdentifier": "mynewdbcluster",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2"
}
```
클러스터 및 관련 DB 인스턴스의 상태가 `upgrading`로 변경되려면 몇 분 정도 걸립니다. 클러스터와 DB 인스턴스의 버전 번호는 업그레이드가 완료된 경우에만 변경됩니다. 다시 말해 라이터 DB 인스턴스에 대한 `wait db-instance-available` 명령을 사용하여 업그레이드가 완료될 때까지 기다렸다가 계속 진행할 수 있습니다.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.11.2
aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
--query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
"DBInstanceIdentifier": "mynewdbcluster-instance1",
"DBInstanceStatus": "upgrading"
}
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
이 시점에서 클러스터의 버전 번호는 업그레이드에 지정된 번호와 일치합니다.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
앞의 예제에서는 `--apply-immediately` 파라미터를 지정하여 즉시 업그레이드를 수행했습니다. 클러스터가 사용 중일 것으로 예상되지 않는 편리한 시간에 업그레이드를 수행하도록 `--no-apply-immediately` 파라미터를 지정할 수 있습니다. 이러면 클러스터의 다음 유지 관리 기간 동안 업그레이드가 시작됩니다. 유지 관리 기간은 유지 관리 작업을 시작할 수 있는 기간을 정의합니다. 유지 관리 기간 동안 장기 실행 작업이 완료되지 않을 수 있습니다. 따라서 업그레이드에 시간이 오래 걸릴 것으로 예상되더라도 더 긴 유지 관리 시간을 정의할 필요는 없습니다.
다음 예시에서는 처음에 Aurora MySQL 버전 2.11.2를 실행하는 클러스터를 업그레이드합니다. `describe-db-engine-versions` 출력에서 `False` 및 `True` 값은 `IsMajorVersionUpgrade` 속성을 나타냅니다. 버전 2.11.2부터는 다른 2.\$1 버전으로 업그레이드할 수 있습니다. 이러한 업그레이드는 메이저 버전 업그레이드로 간주되지 않으므로 현재 위치 업그레이드가 필요하지 않습니다. 현재 위치 업그레이드는 목록에 표시된 3.\$1 버전으로 업그레이드할 때만 사용할 수 있습니다.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
--query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.7.mysql_aurora.2.11.3 False
5.7.mysql_aurora.2.11.4 False
5.7.mysql_aurora.2.11.5 False
5.7.mysql_aurora.2.11.6 False
5.7.mysql_aurora.2.12.0 False
5.7.mysql_aurora.2.12.1 False
5.7.mysql_aurora.2.12.2 False
5.7.mysql_aurora.2.12.3 False
8.0.mysql_aurora.3.04.0 True
8.0.mysql_aurora.3.04.1 True
8.0.mysql_aurora.3.04.2 True
8.0.mysql_aurora.3.04.3 True
8.0.mysql_aurora.3.05.2 True
8.0.mysql_aurora.3.06.0 True
8.0.mysql_aurora.3.06.1 True
8.0.mysql_aurora.3.07.1 True
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --no-apply-immediately --allow-major-version-upgrade
...
```
지정된 유지 관리 기간 없이 클러스터가 생성되면 Aurora에서 주중 임의의 요일을 선택합니다. 이 경우 `modify-db-cluster` 명령은 월요일에 제출됩니다. 따라서 유지 보수 기간을 화요일 아침으로 변경합니다. 모든 시간은 UTC 표준 시간대로 표시됩니다. `tue:10:00-tue:10:30` 기간은 태평양 표준시 오전 2시\$12시 30분에 해당합니다. 유지 관리 기간의 변경 내용은 즉시 적용됩니다.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"sat:08:20-sat:08:50"
]
]
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"tue:10:00-tue:10:30"
]
]
```
다음 예시에서는 업그레이드로 생성된 이벤트에 대한 보고서를 가져오는 방법을 보여줍니다. `--duration` 인수는 이벤트 정보 검색 시간(분)을 나타냅니다. 기본적으로 `describe-events`는 마지막 시간의 이벤트만 반환하므로 이 인수가 필요합니다.
```
aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
"Events": [
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "DB cluster created",
"EventCategories": [
"creation"
],
"Date": "2022-11-17T01:24:11.093000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing online pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:08.450000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:59.519000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:00:22.318000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Cloning volume.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:01:45.428000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:02:25.141000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:23.036000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Upgrading database objects.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:48.208000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster major version has been upgraded",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:10:28.999000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
}
]
}
```
# Aurora MySQL 주 버전 업그레이드 실패 원인 조사
[자습서](AuroraMySQL.Upgrading.Tutorial.md)에서는 Aurora MySQL 버전 2에서 버전 3로 업그레이드하는 데 성공했습니다. 하지만 업그레이드가 실패했다면 그 이유를 알고 싶을 것입니다.
먼저 `describe-events` AWS CLI 명령을 사용하여 DB 클러스터 이벤트를 살펴볼 수 있습니다. 이 예제는 지난 10시간 동안의 `mydbcluster`에 대한 이벤트를 보여줍니다.
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
이 경우 업그레이드 사전 점검에 실패한 것이 원인입니다.
```
{
"Events": [
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster engine version upgrade started.",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:22.846000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
},
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the
upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:24.373000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
}
]
}
```
문제의 정확한 원인을 진단하려면 라이터 DB 인스턴스에 대한 데이터베이스 로그를 검사합니다. Aurora MySQL 버전 3으로 업그레이드할 때 실패하면 라이터 인스턴스에 `upgrade-prechecks.log`라는 이름의 로그 파일이 포함됩니다. 이 예에서는 해당 로그의 존재를 감지한 다음 검사를 위해 로컬 파일로 다운로드하는 방법을 보여줍니다.
```
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
--query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log
aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
--log-file-name upgrade-prechecks.log \
--starting-token 0 \
--output text >upgrade_prechecks.log
```
`upgrade-prechecks.log` 파일은 JSON 형식입니다. 다른 JSON 래퍼 내에서 JSON 출력을 인코딩하지 않도록 `--output text` 옵션을 사용하여 다운로드합니다. Aurora MySQL 버전 3 업그레이드의 경우 이 로그에는 항상 특정 정보 메시시지와 경고 메시지가 포함됩니다. 업그레이드가 실패하는 경우에만 오류 메시지가 포함됩니다. 업그레이드가 성공하면 로그 파일이 생성되지 않습니다.
이러한 모든 오류를 요약하고 관련 객체 및 설명 필드를 표시하려면 `upgrade-prechecks.log` 파일의 내용에 관한 `grep -A 2 '"level": "Error"'` 명령을 실행합니다. 그러기 위해 각 오류 줄과 그 뒤에 두 줄이 표시됩니다. 여기에는 해당 데이터베이스 객체의 이름과 문제 수정 방법에 대한 지침이 포함되어 있습니다.
```
$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'
"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
```
이 예제에서는 문제가 되는 테이블에서 다음 SQL 명령을 실행하여 문제를 해결하거나, 누락된 인덱스 없이 테이블을 다시 생성할 수 있습니다.
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
그런 다음 업그레이드를 다시 시도하세요.
# Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결
다음 팁을 사용하면 Aurora MySQL 인플레이스 업그레이드와 관련된 문제를 해결하는 데 도움이 됩니다. 이러한 팁은 Aurora Serverless DB 클러스터에는 적용되지 않습니다.
| 현재 위치 업그레이드가 취소되거나 느린 이유 | Effect | 유지 관리 기간 내에 현재 위치 업그레이드를 완료할 수 있는 솔루션 |
| --- | --- | --- |
| 관련 Aurora 크로스 리전 복제본이 아직 패치되지 않음 | Aurora는 업그레이드를 취소합니다. | Aurora 크로스 리전 복제본을 업그레이드하고 다시 시도합니다. |
| 클러스터에 준비된 상태의 XA 트랜잭션이 있습니다. | Aurora는 업그레이드를 취소합니다. | 준비된 모든 XA 트랜잭션을 커밋하거나 롤백합니다. |
| 클러스터가 데이터 정의 언어(DDL)문을 처리하고 있습니다. | Aurora는 업그레이드를 취소합니다. | 모든 DDL문이 완료된 후 대기하고 업그레이드를 수행하기를 고려하십시오. |
| 클러스터에 많은 행에 대해 커밋되지 않은 변경 사항이 있습니다. | 업그레이드에 시간이 오래 걸릴 수 있습니다. | 업그레이드 프로세스는 커밋되지 않은 변경 사항을 롤백합니다. 이 조건에 대한 표시기는 `TRX_ROWS_MODIFIED` 테이블 내 `INFORMATION_SCHEMA.INNODB_TRX`의 값입니다. 모든 대규모 트랜잭션이 커밋되거나 롤백된 후에만 업그레이드를 수행하는 것이 좋습니다. |
| 클러스터에 실행 취소 레코드 수가 많음 | 업그레이드에 시간이 오래 걸릴 수 있습니다. | 커밋되지 않은 트랜잭션이 대량의 행에 영향을 미치지 않더라도 대량의 데이터가 포함될 수 있습니다. 예를 들어 대형 BLOB를 삽입할 수 있습니다. Aurora는 이러한 종류의 트랜잭션 활동에 대한 이벤트를 자동으로 감지하거나 생성하지 않습니다. 이 조건에 대한 지표는 HLL(기록 목록 길이)입니다. 업그레이드 프로세스는 커밋되지 않은 변경 사항을 롤백합니다. `SHOW ENGINE INNODB STATUS` SQL 명령의 출력에서 HLL을 확인하거나 다음 SQL 쿼리를 사용하여 직접 확인할 수 있습니다. SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
또한 Amazon CloudWatch를 사용하여 `RollbackSegmentHistoryListLength` 지표를 모니터링할 수도 있습니다. HLL의 길이가 더 줄어든 후에 한하여 업그레이드 수행을 고려하세요. |
| 클러스터가 큰 이진 로그 트랜잭션을 커밋하는 중입니다. | 업그레이드에 시간이 오래 걸릴 수 있습니다. | 업그레이드 프로세스는 이진 로그 변경 내용이 적용될 때까지 기다립니다. 이 기간 동안 더 많은 트랜잭션 또는 DDL문이 시작될 수 있으므로 업그레이드 프로세스가 느려질 수 있습니다. 클러스터가 이진 로그 복제 변경 내용을 생성하느라 바쁜 경우가 아니면 업그레이드 프로세스를 예약합니다. Aurora는 이 조건에 대한 이벤트를 자동으로 감지하거나 생성하지 않습니다. |
| 파일 제거 또는 손상으로 인한 스키마 불일치 | Aurora는 업그레이드를 취소합니다. | 임시 테이블의 기본 스토리지 엔진을 MyISAM에서 InnoDB로 변경합니다. 다음 단계를 수행합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| 마스터 사용자 삭제됨 | Aurora는 업그레이드를 취소합니다. | 마스터 사용자는 삭제하지 마세요. 하지만 어떤 이유로든 마스터 사용자를 삭제해야 하는 경우 다음 SQL 명령을 사용하여 복원하세요. CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT,
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;
|
업그레이드 사전 검사 실패를 유발하는 문제 해결에 대한 자세한 내용은 다음 블로그를 참조하세요.
+ [Amazon Aurora MySQL 버전 2(MySQL 5.7 호환성 지원)에서 버전 3(MySQL 8.0 호환성 지원)으로 업그레이드할 때 필요한 체크리스트, 1부](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/)
+ [Amazon Aurora MySQL 버전 2(MySQL 5.7 호환성 지원)에서 버전 3(MySQL 8.0 호환성 지원)으로 업그레이드할 때 필요한 체크리스트, 2부](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
다음 단계를 사용하여 위 테이블의 일부 조건에 대해 직접 검사를 수행할 수 있습니다. 이렇게 하면 데이터베이스가 업그레이드가 성공적으로 신속하게 완료될 수 있는 상태임을 알고 있을 때 업그레이드를 예약할 수 있습니다.
+ `XA RECOVER`문을 실행하여 열린 XA 트랜잭션을 확인할 수 있습니다. 그런 다음 업그레이드를 시작하기 전에 XA 트랜잭션을 커밋하거나 롤백할 수 있습니다.
+ `SHOW PROCESSLIST`문을 실행하고 출력에서 `CREATE`, `DROP`, `ALTER`, `RENAME` 및 `TRUNCATE` 문을 찾아 DDL 문을 확인할 수 있습니다. 업그레이드를 시작하기 전에 모든 DDL 문이 완료될 수 있습니다.
+ `INFORMATION_SCHEMA.INNODB_TRX` 테이블을 쿼리하여 수행되지 않은 행의 총 수를 확인할 수 있습니다. 테이블은 각 트랜잭션에 대한 하나의 행을 포함합니다. `TRX_ROWS_MODIFIED` 열은 트랜잭션에 의해 수정되거나 삽입된 행 수를 포함합니다.
+ `SHOW ENGINE INNODB STATUS SQL`문을 실행하고 출력에서 `History list length`를 찾아 InnoDB 히스토리 목록의 길이를 확인할 수 있습니다. 다음 쿼리를 실행하여 값을 직접 확인할 수도 있습니다.
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
기록 목록의 길이는 다중 버전 동시성 제어 (MVCC)를 구현하기 위해 데이터베이스에 저장된 실행 취소 정보의 양에 해당합니다.
# Aurora MySQL 버전 3에 대한 업그레이드 후 정리
Aurora MySQL 버전 2 클러스터를 Aurora MySQL 버전 3으로 업그레이드한 후 다음과 같은 기타 정리 작업을 수행할 수 있습니다.
+ 모든 사용자 지정 파라미터 그룹의 MySQL 8.0 호환 버전을 새로 만듭니다. 필요한 모든 사용자 파라미터 값을 새 파라미터 그룹에 적용합니다.
+ CloudWatch 경보, 설정 스크립트 등을 업데이트하여 이름이 포괄적 언어 변경의 영향을 받은 모든 표지에 새 이름을 사용합니다. 이런 지표 목록은 [Aurora MySQL 버전 3에 대한 포괄적 언어 변경](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language) 섹션을 참조하세요.
+ 모든 CloudFormation 템플릿을 업데이트하여 이름이 포괄적 언어 변경의 영향을 받은 모든 구성 파라미터에 새 이름을 사용합니다. 이런 파라미터 전체 목록은 [Aurora MySQL 버전 3에 대한 포괄적 언어 변경](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language) 섹션을 참조하세요.
## 공간 인덱스
Aurora MySQL 버전 3으로 업그레이드한 후 공간 인덱스와 관련된 객체 및 인덱스를 삭제하거나 다시 생성해야 하는지 확인합니다. MySQL 8.0 이전에 Aurora는 공간 리소스 식별자(SRID)를 포함하지 않은 인덱스를 사용하여 공간 쿼리를 최적화할 수 있었습니다. Aurora MySQL 버전 3은 SRID를 포함하는 공간 인덱스만 사용합니다. 업그레이드 중에 Aurora는 SRID 없는 모든 공간 인덱스를 자동으로 삭제하고 데이터베이스 로그에 경고 메시지를 인쇄합니다. 이러한 경고 메시지가 표시되면 업그레이드 후 SRID를 사용하여 새 공간 인덱스를 생성합니다. MySQL 8.0의 공간 함수와 데이터 유형 변경에 대한 자세한 내용은 *MySQL 참조 설명서*의 [MySQL 8.0의 변경 사항](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html)을 참조하세요.