Aurora MySQL에 대한 사전 확인 설명 참조

사전 확인 수준: 오류

mysql 스키마에 대해 check table x for upgrade 명령에서 보고되는 문제

Aurora MySQL 버전 3으로 업그레이드를 시작하기 전에 check table for upgrade는 DB 인스턴스의 mysql 스키마에 있는 각 테이블에서 실행됩니다. check table for upgrade 명령은 최신 버전의 MySQL로 업그레이드하는 동안 발생할 수 있는 잠재적 문제가 있는지 테이블을 검사합니다. 업그레이드를 시도하기 전에 이 명령을 실행하면 비호환성을 미리 식별하고 해결하는 데 도움이 되므로 실제 업그레이드 프로세스가 더 원활해집니다.

이 명령은 각 테이블에 대해 다음과 같은 다양한 검사를 수행합니다.

자세한 내용은 MySQL 설명서의 CHECK TABLE 문을 참조하세요.

출력 예제:

{
  "id": "checkTableMysqlSchema",
  "title": "Issues reported by 'check table x for upgrade' command for mysql schema.",
  "status": "OK",
  "detectedProblems": []
}

이 사전 확인의 출력은 check table for upgrade가 여러 검사를 수행하기 때문에 발생한 오류와 발생한 시간에 따라 달라집니다.

이 사전 확인에 오류가 발생하면 AWS 지원에서 사례를 열어 메타데이터 불일치를 해결하도록 요청합니다. 또는 논리적 덤프를 수행한 다음 새 Aurora MySQL 버전 3 DB 클러스터로 복원하여 업그레이드를 다시 시도할 수 있습니다.

사전 확인 수준: 오류

테이블스페이스 데이터 파일 경로의 원형 디렉터리 참조

MySQL 8.0.17부터 이 CREATE TABLESPACE ... ADD DATAFILE 절에서는 더 이상 원형 디렉터리 참조를 허용하지 않습니다. 업그레이드 문제를 방지하려면 Aurora MySQL 버전 3으로 업그레이드하기 전에 테이블스페이스 데이터 파일 경로에서 원형 디렉터리 참조를 제거합니다.

출력 예제:

{
  "id": "circularDirectory",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "description": "Error: Following tablespaces contain circular directory references (e.g. the reference '/../') in data file paths which as of MySQL 8.0.17 are not permitted by the CREATE TABLESPACE ... ADD DATAFILE clause. An exception to the restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-innodb-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "ts2",
        "description": "circular reference in datafile path: '/home/ec2-user/dbdata/mysql_5_7_44/../ts2.ibd'",
        "dbObjectType": "Tablespace"
      }
  ]
}

이 오류가 발생하면 file-per-table tablespace를 사용하여 테이블을 다시 빌드합니다. 모든 테이블스페이스 및 테이블 정의에 기본 파일 경로를 사용합니다.

다시 빌드한 후 사전 확인이 통과되어 업그레이드를 진행할 수 있습니다.

{
  "id": "circularDirectoryCheck",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "detectedProblems": []
},

사전 확인 수준: 오류

기본값을 가질 수 없는 열

MySQL 8.0.13 이전에는 BLOB, TEXT, GEOMETRY 및 JSON 열에 기본값이 있을 수 없습니다. Aurora MySQL 버전 3으로 업그레이드하기 전에 이러한 열에서 기본 절을 제거합니다. 이러한 데이터 유형의 기본 처리 변경 사항에 대한 자세한 내용은 MySQL 설명서의 데이터 유형 기본값을 참조하세요.

출력 예제:

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "description": "Error: The following columns are defined as either BLOB, TEXT, GEOMETRY or JSON and have a default value set. These data types cannot have default values in MySQL versions prior to 8.0.13, while starting with 8.0.13, the default value must be specified as an expression. In order to fix this issue, please use the ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT statement.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html#data-type-defaults-explicit",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test_blob_default.geo_col",
        "description": "geometry"
      }
  ]
},

사전 확인은 test.test_blob_default 테이블의 geo_col 열이 기본값이 지정된 BLOB, TEXT, GEOMETRY 또는 JSON 데이터 유형을 사용하므로 오류를 반환합니다.

테이블 정의를 보면 geo_col 열이 geo_col geometry NOT NULL default ''로 정의되어 있음을 알 수 있습니다.

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1

이 기본 절을 제거하여 사전 확인을 통과할 수 있도록 합니다.

mysql> ALTER TABLE test_blob_default modify COLUMN geo_col geometry NOT NULL;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

사전 확인이 통과하면 업그레이드를 다시 시도할 수 있습니다.

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "detectedProblems": []
},

사전 확인 수준: 오류

정의에서 사용되지 않는 키워드 사용

MySQL 8.0에서 쿼리 캐시가 제거되었습니다. 따라서 일부 쿼리 캐시별 SQL 구문이 제거되었습니다. 데이터베이스 객체에 QUERY CACHE, SQL_CACHE 또는 SQL_NO_CACHE 키워드가 포함된 경우 사전 확인 오류가 반환됩니다. 이 문제를 해결하려면 언급된 키워드를 제거하여 이러한 객체를 다시 생성합니다.

출력 예제:

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "description": "Error: The following DB objects contain keywords like 'QUERY CACHE', 'SQL_CACHE', 'SQL_NO_CACHE' which are not supported in major version 8.0. It is recommended to drop these DB objects or rebuild without any of the above keywords before upgrade.",
  "detectedProblems": [
      {
"level": "Error",
"dbObject": "test.no_query_cache_check",
"description": "PROCEDURE uses depreciated words in definition"
      }
  ]
}

사전 확인은 test.no_query_cache_check 저장된 프로시저가 제거된 키워드 중 하나를 사용하고 있음을 보고합니다. 프로시저 정의를 보면 SQL_NO_CACHE를 사용하는 것을 알 수 있습니다.

mysql> show create procedure test.no_query_cache_check\G
*************************** 1. row ***************************
           Procedure: no_query_cache_check
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`()
BEGIN
    SELECT SQL_NO_CACHE k from sbtest1 where id > 10 and id < 20 group by k asc;
END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

키워드를 제거합니다.

mysql> drop procedure test.no_query_cache_check;
Query OK, 0 rows affected (0.01 sec)

mysql> delimiter //

mysql> CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`() BEGIN     SELECT k from sbtest1 where id > 10 and id < 20 group by k asc; END//
Query OK, 0 rows affected (0.00 sec)

mysql> delimiter ;

키워드를 제거하면 사전 확인이 성공적으로 완료됩니다.

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "detectedProblems": []
}

사전 확인 수준: 오류

다른 엔진에 속하는 InnoDB에서 인식하는 테이블

schemaInconsistencyCheck와 마찬가지로 이 사전 확인은 업그레이드를 진행하기 전에 MySQL의 테이블 메타데이터가 일관적인지 확인합니다.

이 사전 확인에 오류가 발생하면 AWS 지원에서 사례를 열어 메타데이터 불일치를 해결하도록 요청합니다. 또는 논리적 덤프를 수행한 다음 새 Aurora MySQL 버전 3 DB 클러스터로 복원하여 업그레이드를 다시 시도할 수 있습니다.

출력 예제:

{
  "id": "engineMixupCheck",
  "title": "Tables recognized by InnoDB that belong to a different engine",
  "status": "OK",
  "description": "Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removes InnoDB table files manually from the disk and creates e.g. a MyISAM table with the same name.\n\nA possible way to solve this situation is to e.g. in case of MyISAM table:\n\n1. Rename the MyISAM table to a temporary name (RENAME TABLE).\n2. Create some dummy InnoDB table (its definition does not need to match), then copy (copy, not move) and rename the dummy .frm and .ibd files to the orphan name using OS file commands.\n3. The orphan table can be then dropped (DROP TABLE), as well as the dummy table.\n4. Finally the MyISAM table can be renamed back to its original name.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.general_log_backup",
        "description": "recognized by the InnoDB engine but belongs to CSV"
      }
  ]
}

사전 확인 수준: 오류

255자보다 긴 요소를 포함하는 ENUM 및 SET 열 정의

테이블 및 저장된 프로시저에는 255자 또는 1,020바이트를 초과하는 ENUM 또는 SET 열 요소가 없어야 합니다. MySQL 8.0 이전에는 최대 결합 길이가 64K였지만 8.0은 개별 요소를 255자 또는 1,020바이트(멀티바이트 지원)로 제한합니다. enumSetElementLengthCheck에 대한 사전 확인 실패가 발생하면 업그레이드를 다시 시도하기 전에 이러한 새 제한을 초과하는 요소를 수정합니다.

출력 예제:

{
  "id": "enumSetElementLengthCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "description": "Error: The following columns are defined as either ENUM or SET and contain at least one element longer that 255 characters. They need to be altered so that all elements fit into the 255 characters limit.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/string-type-overview.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.large_set.s",
        "description": "SET contains element longer than 255 characters"
      }
  ]
},

test.large_set 테이블의 s 열에 255자보다 긴 SET 요소가 포함되어 있기 때문에 사전 확인은 오류를 보고합니다.

이 열의 SET 크기를 줄이면 사전 확인이 통과되어 업그레이드를 진행할 수 있습니다.

{
  "id": "enumSetElementLenghtCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "detectedProblems": []
},

사전 확인 수준: 오류

64자보다 긴 외래 키 제약 조건 이름

MySQL 설명서에 설명된 대로 MySQL에서 식별자 길이는 64자로 제한됩니다. 외래 키 길이가 이 값 이상이어서 업그레이드 실패가 발생하는 문제가 확인되어 이 사전 확인이 구현되었습니다. 이 사전 확인에 오류가 발생하면 업그레이드를 다시 시도하기 전에 제약 조건을 64자 미만으로 변경하거나 이름을 변경해야 합니다.

출력 예제:

{
  "id": "foreignKeyLength",
  "title": "Foreign key constraint names longer than 64 characters",
  "status": "OK",
  "detectedProblems": []
}

사전 확인 수준: 오류

데이터베이스의 모든 트리거 이름은 고유해야 합니다.

데이터 딕셔너리 구현의 변경으로 인해 MySQL 8.0은 데이터베이스 내에서 대/소문자를 구분하는 트리거를 지원하지 않습니다. 이 사전 확인은 DB 클러스터에 중복 트리거가 포함된 데이터베이스가 하나 이상 없는지 확인합니다. 자세한 내용은 MySQL 설명서의 식별자 대/소문자 구분을 참조하세요.

출력 예제:

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "description": "Error: You have one or more database containing duplicate triggers. Mysql 8.0 does not support case sensitive triggers within a database https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html. To upgrade to MySQL 8.0, drop the triggers with case-insensitive duplicate names and recreate with distinct names.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_product"
      },
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_PRODUCT"
      }
  ]
}

사전 확인은 데이터베이스 클러스터에 이름이 같지만 대/소문자가 다른 두 개의 트리거(test.before_insert_product 및 test.before_insert_PRODUCT)가 있다는 오류를 보고합니다.

업그레이드하기 전에 트리거의 이름을 바꾸거나 삭제하고 새 이름으로 다시 생성합니다.

test.before_insert_PRODUCT의 이름을 test.before_insert_product_2로 변경하면 사전 확인이 성공합니다.

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "detectedProblems": []
}

사전 확인 수준: 오류

mysql.event에 대한 정의자 열은 Null이거나 공백일 수 없습니다.

DEFINER 속성은 트리거, 저장된 프로시저 또는 이벤트와 같은 저장된 객체 정의를 소유하는 MySQL 계정을 지정합니다. 이 속성은 저장된 객체가 실행되는 보안 컨텍스트를 제어하려는 상황에서 특히 유용합니다. 저장된 객체를 생성할 때 DEFINER가 지정되지 않은 경우 기본값은 객체를 생성한 사용자입니다.

MySQL 8.0으로 업그레이드할 때는 MySQL 데이터 딕셔너리에서 null 또는 빈 정의자가 있는 저장된 객체를 가질 수 없습니다. 이러한 저장된 객체가 있는 경우 사전 확인 오류가 발생합니다. 업그레이드를 진행하려면 먼저 문제를 해결해야 합니다.

오류 메시지 예:

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "description": "Error: Set definer column in mysql.event to a valid non-null definer.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.get_version",
        "description": "Set definer for event get_version in Schema test"
      }
  ]
}

사전 확인은 null 정의자가 있기 때문에 test.get_version 이벤트에 대한 오류를 반환합니다.

이를 해결하려면 이벤트 정의를 확인할 수 있습니다. 보시다시피 정의자는 null이거나 비어 있습니다.

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+---------+
| db   | name        | definer |
+------+-------------+---------+
| test | get_version |         |
+------+-------------+---------+
1 row in set (0.00 sec)

유효한 정의자를 사용하여 이벤트를 삭제하거나 다시 생성합니다.

mysql> drop event test.get_version;
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;
mysql> delimiter $$
mysql> CREATE EVENT get_version
    ->     ON SCHEDULE
    ->       EVERY 1 DAY
    ->     DO
    ->      ///DO SOMETHING //
    -> $$
Query OK, 0 rows affected (0.01 sec)

mysql> DELIMITER ;

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+------------+
| db   | name        | definer    |
+------+-------------+------------+
| test | get_version | reinvent@% |
+------+-------------+------------+
1 row in set (0.00 sec)

이제 사전 확인이 통과됩니다.

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "detectedProblems": []},

사전 확인 수준: 오류

InnoDB 데이터 딕셔너리와 실제 테이블 정의 간의 열 정의 불일치

schemaInconsistencyCheck와 마찬가지로 이 사전 확인은 업그레이드를 진행하기 전에 MySQL의 테이블 메타데이터가 일관적인지 확인합니다. 이 경우 사전 확인은 열 정의가 InnoDB 데이터 딕셔너리와 MySQL 테이블 정의 간에 일치하는지 확인합니다. 불일치가 감지되면 업그레이드가 진행되지 않습니다.

이 사전 확인에 오류가 발생하면 AWS 지원에서 사례를 열어 메타데이터 불일치를 해결하도록 요청합니다. 또는 논리적 덤프를 수행한 다음 새 Aurora MySQL 버전 3 DB 클러스터로 복원하여 업그레이드를 다시 시도할 수 있습니다.

출력 예제:

{
  "id": "getMismatchedMetadata",
  "title": "Column definition mismatch between InnoDB Data Dictionary and actual table definition.",
  "status": "OK",
  "description": "Error: Your database has mismatched metadata. The upgrade to mysql 8.0 will not succeed until this is fixed.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.mismatchTable",
        "description": "Table `test/mismatchTable` column names mismatch with InnoDb dictionary column names: iD <> id"
      }
  ]
}

사전 확인은 test.mismatchTable 테이블의 id 열에 대한 메타데이터의 불일치를 보고합니다. 특히 MySQL 메타데이터의 열 이름은 iD이고 InnoDB의 열 이름은 id입니다.

사전 확인 수준: 오류

information_schema.triggers에 대한 정의자 열은 null이거나 공백일 수 없습니다.

사전 확인은 데이터베이스에 null 또는 빈 정의자로 정의된 트리거가 없는지 확인합니다. 저장된 객체의 정의자 요구 사항에 대한 자세한 내용은 getEventsWithNullDefiner를 참조하세요.

출력 예제:

{
  "id": "getTriggersWithNullDefiner",
  "title": "The definer column for information_schema.triggers cannot be null or blank.",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.example_trigger",
        "description": "Set definer for trigger example_trigger in Schema test"
      }
  ]
}

test 스키마의 example_trigger 트리거에 null 정의자가 있으므로 사전 확인은 오류를 반환합니다. 이 문제를 해결하려면 유효한 사용자로 트리거를 다시 생성하거나 트리거를 삭제하여 정의자를 수정합니다. 자세한 내용은 getEventsWithNullDefiner의 예제를 참조하세요.

사전 확인 수준: 오류

lower_case_table_names 파라미터를 1로 설정하는 경우 모든 데이터베이스 또는 테이블 이름은 소문자여야 합니다.

MySQL 8.0 이전에는 데이터베이스 이름, 테이블 이름 및 기타 객체가 파일 기반 메타데이터(.frm)와 같은 데이터 디렉터리의 파일에 상응했습니다. lower_case_table_names 시스템 변수를 사용하면 서버가 데이터베이스 객체의 식별자 대/소문자 구분 여부를 처리하는 방식과 이러한 메타데이터 객체의 스토리지를 제어할 수 있습니다. 재부팅 후 이미 초기화된 서버에서 이 파라미터를 변경할 수 있습니다.

그러나 MySQL 8.0에서 이 파라미터는 서버가 식별자 대/소문자 구분 여부를 처리하는 방식을 여전히 제어하지만 데이터 딕셔너리가 초기화된 후에는 변경할 수 없습니다. MySQL 8.0 데이터베이스를 업그레이드하거나 생성할 때 데이터 딕셔너리가 MySQL 에서 처음 시작될 때 lower_case_table_names에 대해 설정된 값은 해당 데이터베이스의 수명 동안 사용됩니다. 이 제한은 데이터베이스 객체가 파일 기반 메타데이터에서 mysql 스키마의 내부 InnoDB 테이블로 마이그레이션되는 원자성 데이터 딕셔너리 구현의 일부로 적용되었습니다.

자세한 내용은 MySQL 설명서의 데이터 딕셔너리 변경 사항을 참조하세요.

파일 기반 메타데이터를 새 원자성 데이터 딕셔너리로 업데이트할 때 업그레이드 중에 문제가 발생하지 않도록 하기 위해 이 사전 확인은 lower_case_table_names = 1일 때 모든 테이블이 디스크에 소문자로 저장되는지 확인합니다. 그러지 않으면 사전 확인 오류가 반환되며 업그레이드를 진행하기 전에 메타데이터를 수정해야 합니다.

출력 예제:

{
  "id": "getValueOfVariablelower_case_table_names",
  "title": "MySQL pre-checks that all database or table names are lowercase when the lower_case_table_names parameter is set to 1.",
  "status": "OK",
  "description": "Error: You have one or more databases or tables with uppercase letters in the names, but the lower_case_table_names parameter is set to 1. To upgrade to MySQL 8.0, either change all database or table names to lowercase, or set the parameter to 0.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.TEST",
        "description": "Table test.TEST contains one or more capital letters in name while lower_case_table_names = 1"
      }
  ]
}

test.TEST 테이블에 대문자가 포함되어 있지만 lower_case_table_names가 1로 설정되어 있기 때문에 오류가 반환됩니다.

이 문제를 해결하려면 업그레이드를 시작하기 전에 소문자를 사용하도록 테이블의 이름을 바꾸거나 DB 클러스터의 lower_case_table_names 파라미터를 수정할 수 있습니다.

사전 확인 수준: 오류

제거된 GROUP BY ASC/DESC 구문 사용

MySQL 8.0.13부터 GROUP BY 절의 더 이상 사용되지 않는 ASC 또는 DESC 구문이 제거되었습니다. GROUP BY 정렬에 의존하는 쿼리는 이제 다른 결과를 생성할 수 있습니다. 특정 정렬 순서를 가져오려면 대신 ORDER BY 절을 사용합니다. 이 구문을 사용하는 데이터베이스에 객체가 있는 경우 업그레이드를 다시 시도하기 전에 ORDER BY 절을 사용하여 객체를 다시 생성해야 합니다. 자세한 내용은 MySQL 설명서에서 SQL 변경 사항을 참조하세요.

출력 예제:

{
  "id": "groupbyAscSyntaxCheck",
  "title": "Usage of removed GROUP BY ASC/DESC syntax",
  "status": "OK",
  "description": "Error: The following DB objects use removed GROUP BY ASC/DESC syntax. They need to be altered so that ASC/DESC keyword is removed from GROUP BY clause and placed in appropriate ORDER BY clause.",
  "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-sql-syntax",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.groupbyasc",
        "description": "PROCEDURE uses removed GROUP BY ASC syntax",
        "dbObjectType": "Routine"
      }
  ]
}

사전 확인 수준: 오류

루틴에 더 이상 사용되지 않는 .<table> 구문이 있는지 확인합니다.

MySQL 8.0에서 루틴에는 더 이상 사용되지 않는 식별자 구문(\".<table>\")이 포함될 수 없습니다. 저장된 루틴 또는 트리거에 이러한 식별자가 포함된 경우 업그레이드가 실패합니다. 예를 들어, 다음 .dot_table 참조는 더 이상 허용되지 않습니다.

mysql> show create procedure incorrect_procedure\G
*************************** 1. row ***************************
           Procedure: incorrect_procedure
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `incorrect_procedure`()
BEGIN delete FROM .dot_table; select * from .dot_table where 1=1; END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

올바른 식별자 구문과 이스케이핑을 사용하도록 루틴과 트리거를 다시 생성한 후 사전 확인이 통과되고 업그레이드를 진행할 수 있습니다. 자세한 내용은 MySQL 설명서의 스키마 객체 이름을 참조하세요.

출력 예제:

{
  "id": "mysqlEmptyDotTableSyntaxCheck",
  "title": "Check for deprecated '.<table>' syntax used in routines.",
  "status": "OK",
  "description": "Error: The following routines contain identifiers in deprecated identifier syntax (\".<table>\"), and should be corrected before upgrade:\n",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.incorrect_procedure",
        "description": " routine body contains deprecated identifiers."
      }
  ]
}

사전 확인은 더 이상 사용되지 않는 구문이 포함되어 있으므로 test 데이터베이스의 incorrect_procedure 루틴에 대한 오류를 반환합니다.

루틴을 수정하면 사전 확인이 성공하고 업그레이드를 다시 시도할 수 있습니다.

사전 확인 수준: 오류

5.7보다 높은 MySQL 버전에서 작업하기에 너무 큰 인덱스가 있는지 확인합니다.

컴팩트하거나 중복된 행 형식의 경우 접두사가 767바이트보다 큰 인덱스를 생성할 수 없습니다. 그러나 MySQL 버전 5.7.35 이전에는 이 작업이 가능했습니다. 자세한 내용은 MySQL 5.7.35 릴리스 정보를 참조하세요.

이 버그의 영향을 받은 인덱스는 MySQL 8.0으로 업그레이드한 후 액세스할 수 없게 됩니다. 이 사전 확인은 업그레이드를 진행할 수 있게 되기 전에 다시 빌드해야 하는 잘못된 인덱스를 식별합니다.

 {
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "description": "Error: The following indexes ware made too large for their format in an older version of MySQL (older than 5.7.34). Normally those indexes within tables with compact or redundant row formats shouldn't be larger than 767 bytes. To fix this problem those indexes should be dropped before upgrading or those tables will be inaccessible.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_large_idx",
        "description": "IDX_2"
      }
  ]
}

test.table_with_large_idx 테이블에는 767바이트보다 크고 컴팩트하거나 중복된 행 형식을 사용하는 테이블의 인덱스가 포함되어 있기 때문에 사전 확인은 오류를 반환합니다. MySQL 8.0으로 업그레이드한 후에는 이러한 테이블에 액세스할 수 없게 됩니다. 업그레이드를 진행하기 전에 다음 중 하나를 수행합니다.

여기서 사전 확인 실패를 해결하기 위해 테이블을 다시 빌드합니다. 테이블을 다시 빌드하기 전에 innodb_file_format이 Barracuda로 설정되어 있고 innodb_default_row_format이 dynamic으로 설정되어 있는지 확인합니다. 이는 MySQL 5.7의 기본값입니다. 자세한 내용은 MySQL 설명서의 InnoDB 행 형식 및 InnoDB 파일 형식 관리를 참조하세요.

mysql > select @@innodb_file_format,@@innodb_default_row_format;
+----------------------+-----------------------------+
| @@innodb_file_format | @@innodb_default_row_format |
+----------------------+-----------------------------+
| Barracuda            | dynamic                     |
+----------------------+-----------------------------+
1 row in set (0.00 sec)

mysql> optimize table table_with_large_idx;
+---------------------------+----------+----------+-------------------------------------------------------------------+
| Table                     | Op       | Msg_type | Msg_text                                                          |
+---------------------------+----------+----------+-------------------------------------------------------------------+
| test.table_with_large_idx | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.table_with_large_idx | optimize | status   | OK                                                                |
+---------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.02 sec)

# Verify FILE_FORMAT and ROW_FORMAT
mysql>  select * from information_schema.innodb_sys_tables where name like 'test/table_with_large_idx';
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
| TABLE_ID | NAME                      | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE | SPACE_TYPE |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
|       43 | test/table_with_large_idx |   33 |      4 |    26 | Barracuda   | Dynamic    |             0 | Single     |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
1 row in set (0.00 sec)

테이블을 다시 빌드한 후 사전 확인이 통과되고 업그레이드를 진행할 수 있습니다.

{
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "detectedProblems": []
},

사전 확인 수준: 오류

MySQL 5.7에 사용된 테이블 및 스키마 이름이 유효하지 않은지 확인

MySQL 8.0에서 새 데이터 딕셔너리로 마이그레이션할 때 데이터베이스 인스턴스에 #mysql50# 접두사가 붙은 스키마 또는 테이블이 포함될 수 없습니다. 이러한 객체가 있으면 업그레이드가 실패합니다. 이 문제를 해결하려면 반환된 스키마 및 테이블에 대해 mysqlcheck를 실행합니다.

출력 예제:

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "description": "The following tables and/or schemas have invalid names. In order to fix them use the mysqlcheck utility as follows:\n\n  $ mysqlcheck --check-upgrade --all-databases\n  $ mysqlcheck --fix-db-names --fix-table-names --all-databases\n\nOR via mysql client, for eg:\n\n  ALTER DATABASE `#mysql50#lost+found` UPGRADE DATA DIRECTORY NAME;",
  "documentationLink": "https://dev.mysql.com/doc/refman/5.7/en/identifier-mapping.html https://dev.mysql.com/doc/refman/5.7/en/alter-database.html https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "#mysql50#fix_db_names",
        "description": "Schema name"
      }
  ]
}

사전 확인은 #mysql50#fix_db_names 스키마의 이름이 유효하지 않다고 보고합니다.

스키마 이름을 수정한 후 사전 확인이 통과되어 업그레이드를 진행할 수 있습니다.

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "detectedProblems": []
},

사전 확인 수준: 오류

5.7에서 분리된 루틴 확인

MySQL 8.0의 새 데이터 딕셔너리로 마이그레이션할 때 스키마가 더 이상 존재하지 않는 데이터베이스에 저장된 프로시저가 있는 경우 업그레이드가 실패합니다. 이 사전 확인은 DB 인스턴스의 저장된 프로시저에 참조된 모든 스키마가 여전히 존재하는지 확인합니다. 업그레이드를 진행하려면 다음 저장 프로시저를 삭제합니다.

출력 예제:

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "description": "Error: The following routines have been orphaned. Schemas that they are referencing no longer exists.\nThey have to be cleaned up or the upgrade will fail.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "dropped_db.get_version",
        "description": "is orphaned"
      }
  ]
},

사전 확인은 dropped_db 데이터베이스의 get_version 저장된 프로시저가 분리되었음을 보고합니다.

이 프로시저를 정리하려면 누락된 스키마를 다시 생성할 수 있습니다.

mysql> create database dropped_db;
Query OK, 1 row affected (0.01 sec)

스키마를 다시 생성한 후 프로시저를 삭제하여 업그레이드를 진행할 수 있습니다.

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "detectedProblems": []
},

사전 확인 수준: 오류

mysql 스키마의 테이블 이름이 MySQL 8.0의 새 테이블과 충돌함

MySQL 8.0에 도입된 새로운 원자성 데이터 딕셔너리는 mysql 스키마의 내부 InnoDB 테이블 세트에 모든 메타데이터를 저장합니다. 업그레이드 중에 새 내부 데이터 딕셔너리 테이블이 mysql 스키마에 생성됩니다. 업그레이드 실패를 일으키는 이름 지정 충돌을 방지하기 위해 사전 확인은 mysql 스키마의 모든 테이블 이름을 검사하여 새 테이블 이름 중에 이미 사용 중인 것이 없는지 확인합니다. 있다면 오류가 반환되고 업그레이드를 진행할 수 없습니다.

출력 예제:

{
  "id": "mysqlSchema",
  "title": "Table names in the mysql schema conflicting with new tables in the latest MySQL.",
  "status": "OK",
  "description": "Error: The following tables in mysql schema have names that will conflict with the ones introduced in the latest version. They must be renamed or removed before upgrading (use RENAME TABLE command). This may also entail changes to applications that use the affected tables.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrade-before-you-begin.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.tablespaces",
        "description": "Table name used in mysql schema.",
        "dbObjectType": "Table"
      }
  ]
}

mysql 스키마에 이름이 지정된 테이블 tablespaces가 있으므로 오류가 반환됩니다. MySQL 8.0의 새로운 내부 데이터 딕셔너리 테이블 이름 중 하나입니다. RENAME TABLE 명령을 사용하여 업그레이드하기 전에 이러한 테이블의 이름을 바꾸거나 제거해야 합니다.

사전 확인 수준: 오류

기본이 아닌 파티셔닝이 있는 엔진을 사용하는 파티셔닝된 테이블

MySQL 8.0 설명서에 따르면 현재 두 개의 스토리지 엔진 InnoDB 및 NDB가 기본 파티셔닝 지원을 제공합니다. 이 중에서 Aurora MySQL 버전 3에서는 MySQL 8.0과 호환되는 InnoDB만 지원됩니다. 다른 스토리지 엔진을 사용하여 MySQL 8.0에서 파티셔닝된 테이블을 생성하려는 시도는 실패합니다. 이 사전 확인은 DB 클러스터에서 기본이 아닌 파티셔닝을 사용하는 테이블을 찾습니다. 반환되는 것이 있다면 파티셔닝을 제거하거나 스토리지 엔진을 InnoDB로 변환해야 합니다.

출력 예제:

{
  "id": "nonNativePartitioning",
  "title": "Partitioned tables using engines with non native partitioning",
  "status": "OK",
  "description": "Error: In the latest MySQL storage engine is responsible for providing its own partitioning handler, and the MySQL server no longer provides generic partitioning support. InnoDB and NDB are the only storage engines that provide a native partitioning handler that is supported in the latest MySQL. A partitioned table using any other storage engine must be altered—either to convert it to InnoDB or NDB, or to remove its partitioning—before upgrading the server, else it cannot be used afterwards.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-configuration-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partMyisamTable",
         "description": "MyISAM engine does not support native partitioning",
         "dbObjectType": "Table"
      }
  ]
}

여기서 MyISAM 테이블은 파티셔닝을 사용하며, 업그레이드를 진행하기 전에 작업이 필요합니다.

사전 확인 수준: 오류

이전 시간 유형 사용

‘이전 시간’은 MySQL 버전 5.5 이하에서 생성된 시간 유형 열(예: TIMESTAMP 및 DATETIME)을 나타냅니다. MySQL 8.0에서는 이러한 이전 시간 데이터 유형에 대한 지원이 제거되므로 데이터베이스에 이러한 이전 시간 유형이 포함된 경우 MySQL 5.7에서 8.0으로의 현재 위치 업그레이드가 불가능합니다. 이 문제를 해결하려면 업그레이드를 진행하기 전에 이전 시간 날짜 유형이 포함된 테이블을 다시 빌드해야 합니다.

MySQL 5.7의 이전 시간 데이터 유형 사용 중단에 대한 자세한 내용은 이 블로그를 참조하세요. MySQL 8.0의 이전 시간 데이터 유형 제거에 대한 자세한 내용은 이 블로그를 참조하세요.

출력 예제:

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "description": "Error: Following table columns use a deprecated and no longer supported temporal disk storage format. They must be converted to the new format before upgrading. It can by done by rebuilding the table using 'ALTER TABLE <table_name> FORCE' command",
  "documentationLink": "https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.55_temporal_table.timestamp_column",
        "description": "timestamp /* 5.5 binary format */",
        "dbObjectType": "Column"
      }
  ]
},

더 이상 지원되지 않는 이전 임시 디스크 스토리지 형식을 사용하기 때문에 test.55_temporal_table 테이블의 timestamp_column 열에 오류가 보고됩니다.

이 문제를 해결하고 업그레이드를 진행하려면 테이블을 다시 빌드하여 이전 시간 디스크 스토리지 형식을 MySQL 5.6에 도입된 새 스토리지 형식으로 변환합니다. 자세한 내용과 사전 요구 사항은 MySQL 설명서의 3바이트와 4바이트 유니코드 문자 세트 간 변환을 참조하세요.

다음 명령을 실행하여 이 사전 확인에 언급된 테이블을 다시 빌드하면 이전 시간 유형이 소수점 이하의 자릿수까지 정밀한 초 단위의 최신 형식으로 변환됩니다.

ALTER TABLE ... ENGINE=InnoDB;

테이블을 다시 빌드하는 것에 대한 자세한 내용은 MySQL 설명서의 ALTER TABLE 문을 참조하세요.

해당 테이블을 다시 빌드하고 업그레이드를 다시 시작한 후 호환성 검사를 통과하여 업그레이드를 진행할 수 있습니다.

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "detectedProblems": []
}

사전 확인 수준: 오류

공유 테이블스페이스에서 파티셔닝된 테이블 사용

MySQL 8.0.13부터 공유 테이블스페이스에 테이블 파티션을 적용하는 것이 더 이상 지원되지 않습니다. 업그레이드하기 전에 이러한 테이블을 공유 테이블스페이스에서 테이블당 파일 테이블스페이스로 이동합니다.

출력 예제:

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "description": "Error: The following tables have partitions in shared tablespaces. They need to be moved to file-per-table tablespace before upgrading. You can do this by running query like 'ALTER TABLE table_name REORGANIZE PARTITION X INTO (PARTITION X VALUES LESS THAN (30) TABLESPACE=innodb_file_per_table);'",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partInnoDBTable",
        "description": "Partition p1 is in shared tablespace innodb",
        "dbObjectType": "Table"
      }
  ]
}

테이블 test.partInnoDBTable의 파티션 p1이 시스템 테이블스페이스에 있으므로 사전 확인이 실패합니다.

이 문제를 해결하려면 test.partInnodbTable 테이블을 다시 빌드하여 문제가 되는 파티션 p1을 테이블당 파일 테이블스페이스에 배치합니다.

mysql > ALTER TABLE partInnodbTable REORGANIZE PARTITION p1
    ->   INTO (PARTITION p1 VALUES LESS THAN ('2014-01-01') TABLESPACE=innodb_file_per_table);
Query OK, 0 rows affected, 1 warning (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

이렇게 하면 사전 확인이 통과됩니다.

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "detectedProblems": []
}

사전 확인 수준: 오류

최신 MySQL 버전에서 제거된 함수 사용

MySQL 8.0에서는 여러 내장 함수가 제거되었습니다. 이 사전 확인은 이러한 함수를 사용할 수 있는 객체가 있는지 데이터베이스를 검사합니다. 발견된 경우 오류가 반환됩니다. 업그레이드를 다시 시도하기 전에 문제를 해결해야 합니다.

제거된 대부분의 함수는 공간 함수이며, 이는 동등한 ST_* 함수로 대체되었습니다. 이러한 경우 새 프로시저 이름 지정을 사용하도록 데이터베이스 객체를 수정합니다. 자세한 내용은 MySQL 설명서의 MySQL 8.0에서 제거된 기능을 참조하십시오.

출력 예제:

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "description": "Error: The following DB objects use functions that were removed in the latest MySQL version. Please make sure to update them to use supported alternatives before upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.GetLocationsInPolygon",
        "description": "PROCEDURE uses removed function POLYGONFROMTEXT (consider using ST_POLYGONFROMTEXT instead)",
        "dbObjectType": "Routine"
      },
      {
        "level": "Error",
        "dbObject": "test.InsertLocation",
        "description": "PROCEDURE uses removed function POINTFROMTEXT (consider using ST_POINTFROMTEXT instead)",
        "dbObjectType": "Routine"
      }
  ]
},

사전 확인은 test.GetLocationsInPolygon 저장된 프로시저가 POLYGONFROMTEXT 및 POINTFROMTEXT의 제거된 두 가지 함수를 사용하고 있음을 보고합니다. 또한 새 ST_POLYGONFROMTEXT 및 ST_POINTFROMTEXT를 대체용으로 사용할 것을 제안합니다. 제안을 사용하여 프로시저를 다시 생성하면 사전 확인이 성공적으로 완료됩니다.

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "detectedProblems": []
},

사전 확인 수준: 오류

루틴과 유사한 객체에 대한 MySQL 구문 확인

MySQL 8.0에서는 이전에 예약되지 않은 예약된 키워드가 도입되었습니다. 업그레이드 사전 확인기는 데이터베이스 객체의 이름과 정의 및 본문에서 예약된 키워드의 사용을 평가합니다. 저장된 프로시저, 함수, 이벤트 및 트리거와 같은 데이터베이스 객체에 사용되는 예약된 키워드를 감지하면 업그레이드가 실패하고 오류가 upgrade-prechecks.log 파일에 게시됩니다. 문제를 해결하려면 업그레이드하기 전에 이러한 객체 정의를 업데이트하고 이러한 참조를 작은따옴표(')로 묶어야 합니다. MySQL 에서 예약된 단어를 이스케이프하는 방법에 대한 자세한 내용은 MySQL 설명서의 문자열 리터럴을 참조하세요.

또는 이름을 다른 이름으로 변경할 수 있으며, 이로 인해 애플리케이션을 변경해야 할 수 있습니다.

출력 예제:

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "description": "The following objects did not pass a syntax check with the latest MySQL grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
         "level": "Error",
         "dbObject": "test.select_res_word",
         "description": "at line 2,18: unexpected token 'except'",
         "dbObjectType": "Routine"
      }
  ]
}

이 문제를 해결하려면 루틴 정의를 확인하세요.

SHOW CREATE PROCEDURE test.select_res_word\G

*************************** 1. row ***************************
           Procedure: select_res_word
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
    Create Procedure: CREATE PROCEDURE 'select_res_word'()
BEGIN
    SELECT * FROM except;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

이 프로시저에서는 MySQL 8.0의 새 키워드인 except라는 테이블을 사용합니다. 문자열 리터럴을 이스케이프하여 프로시저를 다시 생성합니다.

> drop procedure if exists select_res_word;
Query OK, 0 rows affected (0.00 sec)

> DELIMITER $$
 > CREATE PROCEDURE select_res_word()
    -> BEGIN
    ->     SELECT * FROM 'except';
    -> END$$
Query OK, 0 rows affected (0.00 sec)

 > DELIMITER ;

이제 사전 확인이 통과됩니다.

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "detectedProblems": []
}

사전 확인 수준: 오류

파일 제거 또는 손상으로 인한 스키마 불일치

앞서 설명한 대로 MySQL 8.0은 모든 메타데이터를 mysql 스키마의 내부 InnoDB 테이블 세트에 저장하는 원자성 데이터 딕셔너리를 도입했습니다. 이 새로운 아키텍처는 트랜잭션 ACID 규정을 준수하는 방식으로 데이터베이스 메타데이터를 관리하여 이전 파일 기반 접근 방식의 '원자성 DDL' 문제를 해결합니다. MySQL 8.0 이전에는 DDL 작업이 예기치 않게 중단된 경우 스키마 객체가 분리될 수 있었습니다. 업그레이드 중에 파일 기반 메타데이터를 새 원자성 데이터 딕셔너리 테이블로 마이그레이션하면 DB 인스턴스에 분리된 스키마 객체가 없습니다. 분리된 객체가 발생하면 업그레이드가 실패합니다.

업그레이드를 시작하기 전에 이러한 분리된 객체를 감지하는 데 도움이 되도록 schemaInconsistencyCheck 사전 확인을 실행하여 모든 데이터 딕셔너리 메타데이터 객체가 동기화되어 있는지 확인합니다. 분리된 메타데이터 객체가 감지되면 업그레이드가 진행되지 않습니다. 업그레이드를 진행하려면 분리된 메타데이터 객체를 정리합니다.

이 사전 확인에 오류가 발생하면 AWS 지원에서 사례를 열어 메타데이터 불일치를 해결하도록 요청합니다. 또는 논리적 덤프를 수행한 다음 새 Aurora MySQL 버전 3 DB 클러스터로 복원하여 업그레이드를 다시 시도할 수 있습니다.

출력 예제:

{
  "id": "schemaInconsistencyCheck",
  "title": "Schema inconsistencies resulting from file removal or corruption",
  "status": "OK",
  "description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.schemaInconsistencyCheck_failure",
        "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
      }
  ]
}

사전 확인은 test.schemaInconsistencyCheck_failure 테이블에 불일치하는 메타데이터가 있음을 보고합니다. 이 경우 테이블은 InnoDB 스토리지 엔진 메타데이터(information_schema.INNODB_SYS_TABLES)에 존재하지만 MySQL 메타데이터(information_schema.TABLES)에는 존재하지 않습니다.

사전 확인 수준: 오류

Aurora DDL 복구 기능과 관련된 아티팩트 확인

Aurora MySQL 의 데이터 정의 언어(DDL) 복구 구현의 일환으로, 진행 중인 DDL 문의 메타데이터는 mysql 스키마의 ddl_log_md_table 및 ddl_log_table 테이블에 유지됩니다. 이 기능은 MySQL 8.0의 새로운 원자성 데이터 딕셔너리 구현의 일부이므로 버전 3 이상에서는 Aurora의 DDL 복구 구현이 지원되지 않습니다. 호환성 검사 중에 실행 중인 DDL 문이 있는 경우 이 사전 검사가 실패할 수 있습니다. DDL 문이 실행되지 않는 동안 업그레이드를 시도하는 것이 좋습니다.

DDL 문을 실행하지 않았는데 이 사전 확인이 실패하면 AWS 지원에서 사례를 개설하여 메타데이터 불일치를 해결하도록 요청합니다. 또는 논리적 덤프를 수행한 다음 새 Aurora MySQL 버전 3 DB 클러스터로 복원하여 업그레이드를 다시 시도할 수 있습니다.

DDL 문이 실행 중인 경우 사전 확인 출력은 다음 메시지를 표시합니다.

“There are DDL statements in process. Please allow DDL statements to finish before upgrading.”

출력 예제:

{
  "id": "auroraCheckDDLRecovery",
  "title": "Check for artifacts related to Aurora DDL recovery feature",
  "status": "OK",
  "description": "Aurora implementation of DDL recovery is not supported from 3.x onwards. This check verifies that the database do not have artifacts realted to the feature",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_md_table",
        "description": "Table mysql.ddl_log_md_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_table",
        "description": "Table mysql.ddl_log_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "information_schema.processlist",
        "description": "There are DDL statements in process. Please allow DDL statements to finish before upgrading."
      }
  ]
}

사전 확인이 호환성 확인과 동시에 실행되는 진행 중인 DDL로 인해 오류를 반환했습니다. DDL을 실행하지 않고 업그레이드를 다시 시도하는 것이 좋습니다.

사전 확인 수준: 오류

mysql.rds_upgrade_prechecks 테이블의 존재 확인

RDS 서비스에서 수행하는 내부 전용 사전 확인입니다. 모든 오류는 업그레이드 시 자동으로 처리되며 안전하게 무시할 수 있습니다.

이 사전 확인에 오류가 발생하면 AWS 지원에서 사례를 열어 메타데이터 불일치를 해결하도록 요청합니다. 또는 논리적 덤프를 수행한 다음 새 Aurora MySQL 버전 3 DB 클러스터로 복원하여 업그레이드를 다시 시도할 수 있습니다.

{
  "id": "auroraCheckRdsUpgradePrechecksTable",
  "title": "Check existence of mysql.rds_upgrade_prechecks table",
  "status": "OK",
  "detectedProblems": []
}

사전 확인 수준: 오류

Aurora 빠른 DDL 기능과 관련된 아티팩트 확인

일부 DDL 작업의 효율성을 개선하기 위해 Aurora MySQL 버전 2의 랩 모드에서 빠른 DDL 최적화가 도입되었습니다. Aurora MySQL 버전 3에서는 랩 모드가 제거되었으며, 빠른 DDL 구현이 인스턴트 DDL이라는 MySQL 8.0 기능으로 대체되었습니다.

Aurora MySQL 버전 3으로 업그레이드하기 전에 랩 모드에서 빠른 DDL을 사용하는 모든 테이블은 Aurora MySQL 버전 3과의 호환성을 보장하기 위해 OPTIMIZE TABLE 또는 ALTER TABLE ... ENGINE=InnoDB 명령을 실행하여 다시 빌드해야 합니다.

이 사전 확인은 이러한 테이블의 목록을 반환합니다. 반환된 테이블을 다시 빌드한 후 업그레이드를 다시 시도할 수 있습니다.

출력 예제:

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "description": "Aurora fast DDL is not supported from 3.x onwards. This check verifies that the database does not have artifacts related to the feature",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html#AuroraMySQL.Managing.FastDDL-v2",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test",
        "description": "Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE <table name>' for the table to apply all the pending DDL updates. Then try the upgrade again."
      }
  ]
}

사전 확인은 테이블 test.test에 보류 중인 빠른 DDL 작업이 있음을 보고합니다.

업그레이드를 계속하려면 테이블을 다시 빌드한 다음 업그레이드를 다시 시도할 수 있습니다.

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": []
}

사전 확인 수준: 오류

누락된 FULLTEXT 인덱스 참조가 있는 테이블

MySQL 5.6.26 이전에는 전체 텍스트 검색 인덱스를 삭제한 후 숨겨진 FTS_DOC_ID 및 FTS_DOC_ID_INDEX 열이 분리될 수 있었습니다. 자세한 내용은 버그 #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": []
},

사전 확인 수준: 오류

ibd 파일 경로와 관련된 불일치 확인

이 사전 확인은 Aurora MySQL 버전 3.03.0 이하에만 적용됩니다. 이 사전 확인에 오류가 발생하면 Aurora MySQL 버전 3.04 이상으로 업그레이드하세요.

출력 예제:

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "OK",
  "detectedProblems": []
}

사전 확인 수준: 오류

스페이스 ID가 0인 전체 텍스트 인덱스 확인

MySQL에서 InnoDB 테이블에 전체 텍스트 인덱스를 추가하면 여러 보조 인덱스 테이블스페이스가 생성됩니다. 이전 버전의 MySQL에 버그(버전 5.6.20에서 수정됨)가 있어 이러한 보조 인덱스 테이블이 자체 InnoDB 테이블스페이스가 아닌 시스템 테이블스페이스에 생성되었을 수 있습니다.

이러한 보조 테이블스페이스가 있는 경우 업그레이드가 실패합니다. 사전 확인 오류에 언급된 전체 텍스트 인덱스를 다시 생성한 다음 업그레이드를 다시 시도합니다.

출력 예제:

{
  "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 인덱스를 삭제하고 다시 생성하면 사전 확인이 성공합니다.

{
 "id": "auroraUpgradeCheckForFtsSpaceIdZero",
 "title": "Check for fulltext index with space id as zero",
 "status": "OK",
 "detectedProblems": []
}

사전 확인 수준: 오류

준비된 상태의 XA 트랜잭션 확인

메이저 버전 업그레이드 프로세스를 실행하는 동안 Aurora MySQL 버전 2 DB 인스턴스가 완전히 종료되는 것이 중요합니다. 이렇게 하면 모든 트랜잭션이 커밋되거나 롤백되고 InnoDB가 모든 실행 취소 로그 레코드를 제거하게 됩니다. 트랜잭션 롤백이 필요하기 때문에 데이터베이스에 준비된 상태의 XA 트랜잭션이 있는 경우 완전한 종료가 계속되는 것을 차단할 수 있습니다. 따라서 준비된 XA 트랜잭션이 감지되면 커밋 또는 롤백 작업을 수행할 때까지 업그레이드를 진행할 수 없습니다.

XA RECOVER를 사용하여 준비된 상태의 XA 트랜잭션을 찾는 방법에 대한 자세한 내용은 MySQL 설명서의 XA 트랜잭션 SQL 문을 참조하세요. XA 트랜잭션 상태에 대한 자세한 내용은 MySQL 설명서의 XA 트랜잭션 상태를 참조하세요.

출력 예제:

{
  "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_schema.innodb_trx 테이블과 XA RECOVER 출력에서 자세한 내용을 확인할 수 있습니다.

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": []
}

사전 확인 수준: 오류

현재 인스턴스 클래스에서 업그레이드가 지원되는지 확인

라이터 DB 인스턴스 클래스가 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에서 실행 중이므로 오류를 반환합니다.

사전 확인 수준: 오류

8.0 내부 사용자 확인

이 사전 확인은 Aurora MySQL 버전 3.03.0 이하에만 적용됩니다. 이 사전 확인에 오류가 발생하면 Aurora MySQL 버전 3.04 이상으로 업그레이드하세요.

출력 예제:

{
  "id": "auroraUpgradeCheckForInternalUsers",
  "title": "Check for 8.0 internal users.",
  "status": "OK",
  "detectedProblems": []
}

사전 확인 수준: 오류

RDS 마스터 사용자가 존재하는지 확인

MySQL 8에는 권한 관리를 더 쉽고 세밀하게 만들 수 있도록 역할과 동적 권한을 지원하는 새로운 권한 모델이 추가되었습니다. 이 변경 사항의 일환으로 Aurora MySQL은 Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때 데이터베이스의 마스터 사용자에게 자동으로 부여되는 새로운 rds_superuser_role을 도입했습니다.

Aurora MySQL에서 마스터 사용자에게 할당되는 역할 및 권한에 대한 자세한 내용은 마스터 사용자 계정 권한 섹션을 참조하세요. Aurora MySQL 버전 3의 역할 기반 권한 모델에 대한 자세한 내용은 역할 기반 권한 모델 섹션을 참조하세요.

이 사전 확인은 마스터 사용자가 데이터베이스에 있는지 확인합니다. 마스터 사용자가 없는 경우 사전 확인이 실패합니다. 업그레이드를 계속하려면 마스터 사용자 암호를 재설정하거나 사용자를 수동으로 생성하여 마스터 사용자를 다시 생성합니다. 그런 다음 업그레이드를 다시 시도하세요. 마스터 사용자 암호 재설정에 대한 자세한 내용은 데이터베이스 마스터 사용자의 암호 변경 섹션을 참조하세요.

출력 예제:

{
  "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": []
}

사전 확인 수준: 오류

접두사 인덱스의 지오메트리 열 확인

MySQL 8.0.12부터는 GEOMETRY 데이터 유형을 사용하여 열에 접두사 인덱스를 더 이상 생성할 수 없습니다. 자세한 내용은 WL#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": []
}

사전 확인 수준: 오류

저장된 프로시저의 특수 문자와 관련된 불일치 확인

MySQL 8.0 이전에는 데이터베이스 이름, 테이블 이름 및 기타 객체가 데이터 디렉터리의 파일, 즉 파일 기반 메타데이터에 상응했습니다. MySQL 8.0으로 업그레이드하는 과정에서 모든 데이터베이스 객체가 mysql 스키마에 저장된 새 내부 데이터 딕셔너리 테이블로 마이그레이션되어 새로 구현된 원자성 데이터 딕셔너리를 지원합니다. 저장된 프로시저를 마이그레이션하는 과정에서 각 프로시저의 프로시저 정의와 본문은 새 데이터 딕셔너리로 수집될 때 검증됩니다.

MySQL 8 이전에는 경우에 따라 저장된 루틴을 생성하거나 특수 문자가 포함된 프로시저인 mysql.proc 테이블에 직접 삽입할 수 있었습니다. 예를 들어 규정을 준수하지 않는 줄 바꿈하지 않는 공백 \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": []
},

사전 확인 수준: 오류

sys 스키마에 대한 객체 유형 불일치 확인

sys 스키마는 사용자가 DB 인스턴스의 문제를 해결하고 최적화하고 모니터링하는 데 도움이 되는 MySQL 데이터베이스의 객체 및 뷰 세트입니다. Aurora MySQL 버전 2에서 버전 3으로 메이저 버전 업그레이드를 수행할 때 sys 스키마 뷰가 다시 생성되고 새 Aurora MySQL 버전 3 정의로 업데이트됩니다.

업그레이드의 일환으로 sys 스키마의 모든 객체가 뷰가 아닌 스토리지 엔진(INFORMATION_SCHEMA.TABLES의 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_global_by_latency 뷰에 유형 불일치가 있어 업그레이드가 진행되지 않는다고 보고합니다.

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)

이 문제를 해결하기 위해 뷰를 삭제하고 올바른 정의로 다시 생성하거나 이름을 바꿀 수 있습니다. 업그레이드 프로세스 중에 올바른 테이블 정의로 자동으로 생성됩니다.

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": []
}

사전 확인 수준: 오류

뷰에서 열 이름의 상한 확인

MySQL에서 열 이름의 최대 허용 길이는 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": []
}

사전 확인 수준: 오류

작은 열에서 접두사 길이가 255바이트를 초과하는 인덱스가 정의된 테이블 확인

MySQL에서 바이너리 데이터 유형을 사용하여 열에 인덱스를 생성할 때는 인덱스 정의에 접두사 길이를 추가해야 합니다. MySQL 8.0 이전에는 경우에 따라 이러한 데이터 유형의 최대 허용 크기보다 큰 접두사 길이를 지정할 수 있었습니다. 허용되는 최대 데이터 크기가 255바이트이지만 이보다 큰 인덱스 접두사가 허용된 TINYTEXT 및 TINYBLOB 열을 예로 들 수 있습니다. 자세한 내용은 MySQL 설명서의 InnoDB 한도를 참조하세요.

이 사전 확인이 실패하면 문제가 되는 인덱스를 삭제하거나 인덱스에서 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": []
}

사전 확인 수준: 오류

mysql.host 테이블에 누락된 InnoDB 메타데이터 불일치 확인

RDS 서비스에서 수행하는 내부 전용 사전 확인입니다. 모든 오류는 업그레이드 시 자동으로 처리되며 안전하게 무시할 수 있습니다.

이 사전 확인에 오류가 발생하면 AWS 지원에서 사례를 열어 메타데이터 불일치를 해결하도록 요청합니다. 또는 논리적 덤프를 수행한 다음 새 Aurora MySQL 버전 3 DB 클러스터로 복원하여 업그레이드를 다시 시도할 수 있습니다.

사전 확인 수준: 경고

새로운 기본 인증 플러그인 고려 사항

MySQL 8.0에는 caching_sha2_password 인증 플러그인이 도입되어 더 이상 사용되지 않는 mysql_native_password 플러그인보다 더 안전한 암호 암호화와 더 나은 성능을 제공합니다. Aurora MySQL 버전 3의 경우 데이터베이스 사용자에게 사용되는 기본 인증 플러그인은 mysql_native_password 플러그인입니다.

이 사전 확인은 이 플러그인이 제거되고 향후 메이저 버전 릴리스에서 기본값이 변경된다는 것을 경고합니다. 이 변경 전에 애플리케이션 클라이언트와 사용자의 호환성을 평가하는 것이 좋습니다.

자세한 내용은 MySQL 설명서의 caching_sha2_password 호환성 문제 및 해결 방법을 참조하세요.

출력 예제:

{
  "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"
},

사전 확인 수준: 경고

더 이상 사용되지 않는 MAXDB sql_mode 플래그 사용

MySQL 8.0에서는 더 이상 사용되지 않는 여러 sql_mode 시스템 변수 옵션이 제거되었으며, 그 중 하나는 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를 설정한 후 프로시저를 다시 생성합니다.

지원되지 않는 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": []
}

사전 확인 수준: 경고

객체 이름에서 더 이상 사용되지 않는 단일 달러 기호 사용 확인

MySQL 8.0.32부터 인용되지 않은 식별자의 첫 번째 문자로 달러 기호($)를 사용하는 것은 더 이상 지원되지 않습니다. $ 기호를 첫 번째 문자로 포함하는 스키마, 테이블, 뷰, 열 또는 루틴이 있는 경우 이 사전 확인은 경고를 반환합니다. 이 경고로 인해 업그레이드가 차단되지는 않지만 이 문제를 해결하기 위해 조만간 조치를 취하는 것이 좋습니다. MySQL 8.4에서 이러한 식별자는 경고가 아닌 구문 오류를 반환합니다.

출력 예제:

{
  "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 테이블에는 $ 기호가 첫 번째 문자로 포함되어 있으므로 사전 확인은 경고를 보고합니다.

사전 확인 수준: 경고

이름이 예약된 새 키워드와 충돌하는 데이터베이스 객체 사용

이 확인은 이름이 예약된 새 키워드와 충돌하는 데이터베이스 객체의 사용을 확인한다는 점에서 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"
      }
  ]
}

이 경고를 통해 검토할 몇 가지 애플리케이션 쿼리가 있을 수 있음을 알 수 있습니다. 애플리케이션 쿼리가 문자열 리터럴을 올바르게 이스케이프하지 않는 경우 MySQL 8.0으로 업그레이드한 후 오류가 발생할 수 있습니다. 애플리케이션을 검토하여 버전 3에서 실행되는 Aurora MySQL DB 클러스터의 복제본 또는 스냅샷을 기준으로 테스트하는 방법으로 확인합니다.

업그레이드 후 실패하는 이스케이프되지 않은 애플리케이션 쿼리의 예:

SELECT * FROM escape;

업그레이드 후 성공하는 올바르게 이스케이프된 애플리케이션 쿼리의 예:

SELECT * FROM 'escape';

사전 확인 수준: 경고

utf8mb3 문자 세트 사용

MySQL 8.0에서는 utf8mb3 문자 세트가 더 이상 사용되지 않으며 향후 MySQL 메이저 버전에서 제거됩니다. 이 사전 확인은 이 문자 세트를 사용하는 데이터베이스 객체가 감지되는 경우 경고를 표시하기 위해 구현됩니다. 이렇게 해도 업그레이드가 차단되지는 않지만 테이블을 MySQL 8.0의 기본값인 utf8mb4 문자 세트로 마이그레이션하는 것이 좋습니다. utf8mb3 및 utf8mb4에 대한 자세한 내용은 MySQL 설명서의 3바이트와 4바이트 유니코드 문자 세트 간 변환을 참조하세요.

출력 예제:

{
  "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바이트 유니코드 문자 세트 간 변환을 참조하세요.

사전 확인 수준: 경고

날짜, 날짜/시간 및 타임스탬프 값이 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"
      }
  ]
}

사전 확인 수준: 경고

클러스터의 롤백 세그먼트 기록 목록 길이가 높은지 확인합니다.

auroraUpgradeCheckForIncompleteXATransactions에서 언급한 바와 같이 메이저 버전 업그레이드 프로세스를 실행하는 동안 Aurora MySQL 버전 2 DB 인스턴스가 완전히 종료되는 것이 중요합니다. 이렇게 하면 모든 트랜잭션이 커밋되거나 롤백되고 InnoDB가 모든 실행 취소 로그 레코드를 제거하게 됩니다.

DB 클러스터의 롤백 세그먼트 기록 목록 길이(HLL)가 길면 InnoDB가 실행 취소 로그 레코드 제거를 완료하는 데 걸리는 시간이 길어져 메이저 버전 업그레이드 프로세스 중에 가동 중지 시간이 길어질 수 있습니다. 사전 확인에서 DB 클러스터의 HLL이 높음을 감지하면 경고가 발생합니다. 이렇게 해도 업그레이드가 차단되지는 않지만 DB 클러스터의 HLL을 면밀히 모니터링하는 것이 좋습니다. 이를 낮은 수준으로 유지하면 메이저 버전 업그레이드 중에 필요한 가동 중지 시간이 줄어듭니다. HLL 모니터링에 대한 자세한 내용은 InnoDB 기록 목록 길이가 크게 늘어남 섹션을 참조하세요.

출력 예제:

{
  "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 클러스터에서 열린 트랜잭션을 조사하여 HLL이 관리 가능한 크기로 유지되도록 하는 것이 좋습니다.

사전 확인 수준: 경고

커밋되지 않은 행 수정이 많은지 확인

auroraUpgradeCheckForIncompleteXATransactions에서 언급한 바와 같이 메이저 버전 업그레이드 프로세스를 실행하는 동안 Aurora MySQL 버전 2 DB 인스턴스가 완전히 종료되는 것이 중요합니다. 이렇게 하면 모든 트랜잭션이 커밋되거나 롤백되고 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_schema.innodb_trx 테이블을 사용할 수 있습니다. 라이터 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 트랜잭션 관리 최적화를 참조하세요.

사전 확인 수준: 알림

더 이상 사용되지 않는 sql_mode 플래그 사용

MAXDB 외에도 DB2, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS 및 NO_TABLE_OPTIONS 등의 다른 sql_mode 옵션이 제거되었습니다. MySQL 8.0부터 이러한 값 중 어느 것도 sql_mode 시스템 변수에 할당할 수 없습니다. 이 사전 확인에서 이러한 sql_mode 설정을 사용하여 열려 있는 세션을 찾으면 DB 인스턴스 및 DB 클러스터 파라미터 그룹과 클라이언트 애플리케이션 및 구성을 업데이트하여 비활성화해야 합니다. 자세한 내용은 MySQL 설명서를 참조하세요.

출력 예제:

{
  "id": "sqlModeFlagCheck",
  "title": "Usage of obsolete sql_mode flags",
  "status": "OK",
  "detectedProblems": []
}

이러한 사전 확인 실패를 해결하려면 maxdbFlagCheck를 참조하세요.

사전 확인 수준: 오류, 경고 또는 알림

check table x for upgrade 명령에서 보고되는 문제

Aurora MySQL 버전 3으로 업그레이드를 시작하기 전에 check table for upgrade는 DB 클러스터의 사용자 스키마에 있는 각 테이블에서 실행됩니다. 이 사전 확인은 checkTableMysqlSchema와 동일하지 않습니다.

check table for upgrade 명령은 최신 버전의 MySQL로 업그레이드하는 동안 발생할 수 있는 잠재적 문제가 있는지 테이블을 검사합니다. 업그레이드를 시도하기 전에 이 명령을 실행하면 비호환성을 미리 식별하고 해결하는 데 도움이 되므로 실제 업그레이드 프로세스가 더 원활해집니다.

이 명령은 각 테이블에 대해 다음과 같은 다양한 검사를 수행합니다.

다른 사전 확인과 달리 check table 출력에 따라 오류, 경고 또는 알림을 반환할 수 있습니다. 이 사전 확인에서 테이블을 반환하는 경우 업그레이드를 시작하기 전에 반환 코드 및 메시지와 함께 테이블을 주의 깊게 검토합니다. 자세한 내용은 MySQL 설명서의 CHECK TABLE 문을 참조하세요.

여기서는 오류 예제와 경고 예제를 제공합니다.

오류 예제

{
  "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 외래 키 제약 조건에 누락된 인덱스 또는 데이터 유형 불일치가 있음을 보고합니다. 외래 키 제약 조건에 대한 MySQL 설명서에는 외래 키에서 참조되는 열에 연결된 인덱스가 있어야 하고 상위/하위 열은 동일한 데이터 유형을 사용해야 한다고 명시되어 있습니다.

누락된 인덱스 또는 데이터 유형 불일치와 관련이 있는지 확인하려면 데이터베이스에 로그인하고 세션 변수 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 설명서의 버전 호환성 확인에 따르면 이 메시지는 정보 제공용이며 MySQL 5.7.2 이전에 생성된 트리거에 대해 표시됩니다.

이는 경고이므로 업그레이드를 계속 진행하지 못하도록 차단하지 않습니다. 그러나 문제를 해결하려면 해당 트리거를 다시 생성할 수 있으며 사전 확인이 성공하고 경고가 표시되지 않습니다.

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": []
},