Aurora MySQL에 대한 메이저 버전 업그레이드 사전 확인 - Amazon Aurora

Aurora MySQL에 대한 메이저 버전 업그레이드 사전 확인

MySQL 5.7에서 MySQL 8.0으로 전환하는 등 MySQL을 하나의 메이저 버전에서 다른 메이저 버전으로 업그레이드하려면 신중한 계획 및 준비가 필요한 몇 가지 중요한 아키텍처 변경이 필요합니다. 주로 데이터베이스 엔진 소프트웨어 업데이트와 경우에 따라 시스템 테이블 업데이트에 중점을 두는 마이너 버전 업그레이드와 달리, 메이저 MySQL 업그레이드는 데이터베이스가 메타데이터를 저장하고 관리하는 방식에 근본적인 변화를 가져오는 경우가 많습니다.

이러한 비호환성을 식별하는 데 도움이 되도록 Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때 Aurora는 업그레이드 호환성 검사(사전 확인)를 자동으로 실행하여 데이터베이스 클러스터의 객체를 검사하고 업그레이드를 계속하지 못하도록 차단할 수 있는 알려진 비호환성을 식별합니다. Aurora MySQL 사전 확인에 대한 자세한 내용은 Aurora MySQL에 대한 사전 확인 설명 참조 섹션을 참조하세요. Aurora 사전 검사는 Community MySQL 업그레이드 확인기 유틸리티에서 실행하는 검사 외에 추가로 실행됩니다.

이러한 사전 점검은 필수입니다. 건너뛸 수 없습니다. 사전 점검은 다음과 같은 이점을 제공합니다.

  • 업그레이드 실패로 가동 중지 시간이 길어질 가능성을 줄일 수 있습니다.

  • 비호환성이 있는 경우 Amazon Aurora가 업그레이드 진행을 차단하고 이에 대해 알 수 있는 로그를 제공합니다. 그러면 로그를 사용해 비호환성을 해결함으로써 버전 3으로 업그레이드하기 위한 데이터베이스 준비를 마칠 수 있습니다. 비호환성 문제를 해결하는 방법에 대한 자세한 내용은 MySQL 설명서의 업그레이드를 위한 설치 준비MySQL 8.0으로 업그레이드할 때를 참조하세요. 알아야 할 내용을 참조하세요.

    MySQL 8.0으로 업그레이드하는 방법에 대한 자세한 내용은 MySQL 설명서에서 MySQL 업그레이드를 참조하세요.

사전 확인은 메이저 버전 업그레이드를 위해 DB 클러스터를 오프라인으로 전환하기 전에 실행됩니다. 사전 확인에서 비호환성이 발견되면 Aurora는 DB 인스턴스가 중지되기 전에 자동으로 업그레이드를 취소합니다. 또한 Aurora는 비호환성에 대한 이벤트를 생성합니다. Amazon Aurora 이벤트에 대한 자세한 내용은 Amazon RDS 이벤트 알림 작업 섹션을 참조하세요.

사전 확인이 완료되면 Aurora는 upgrade-prechecks.log 파일의 각 비호환성에 대한 세부 정보를 기록합니다. 대부분의 경우 로그 항목에는 비호환성 문제를 해결하기 위한 MySQL 설명서 링크가 포함되어 있습니다. 로그 파일 보기에 대한 자세한 내용은 데이터베이스 로그 파일 보기 및 나열 단원을 참조하십시오.

참고

사전 점검의 특성으로 인해 데이터베이스의 객체를 분석합니다. 이 분석은 리소스를 소비하고 업그레이드가 완료되는 시간을 늘립니다. 사전 확인 성능 고려 사항에 대한 자세한 내용은 Aurora MySQL 사전 확인 프로세스 섹션을 참조하세요.

Aurora MySQL 사전 확인 프로세스

앞서 설명한 대로 Aurora MySQL 업그레이드 프로세스에는 메이저 버전 업그레이드를 진행하기 전에 데이터베이스에서 호환성 검사(사전 확인)를 실행하는 작업이 포함됩니다.

현재 위치 업그레이드의 경우 사전 확인은 온라인 상태인 동안 라이터 DB 인스턴스에서 실행됩니다. 사전 확인에 성공하면 업그레이드가 진행됩니다. 오류가 발견되면 upgrade-prechecks.log 파일에 기록되고 업그레이드가 취소됩니다. 업그레이드를 다시 시도하기 전에 upgrade-prechecks.log 파일에 반환된 오류를 해결합니다.

스냅샷 복원 업그레이드의 경우 복원 프로세스 중에 사전 확인이 실행됩니다. 성공하면 데이터베이스가 새 Aurora MySQL 버전으로 업그레이드됩니다. 오류가 발견되면 upgrade-prechecks.log 파일에 기록되고 업그레이드가 취소됩니다. 업그레이드를 다시 시도하기 전에 upgrade-prechecks.log 파일에 반환된 오류를 해결합니다.

자세한 내용은 Aurora MySQL 주 버전 업그레이드 실패 원인 조사Aurora MySQL에 대한 사전 확인 설명 참조 단원을 참조하세요.

사전 확인 상태를 모니터링하려면 DB 클러스터에서 다음 이벤트를 볼 수 있습니다.

사전 확인 상태 이벤트 메시지 작업

시작됨

업그레이드 준비 진행 중: 온라인 업그레이드 사전 확인 시작.

None

Failed

데이터베이스 클러스터를 업그레이드할 수 없는 상태: 업그레이드 사전 확인 실패. 자세한 내용은 upgrade-prechecks.log 파일을 참조하세요.

업그레이드 실패의 원인 해결에 대한 자세한 내용은 다음을 참조하세요.

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html

upgrade-prechecks.log에 오류가 있는지 검토합니다.

오류를 수정합니다.

업그레이드를 다시 시도합니다.

성공

업그레이드 준비 진행 중: 온라인 업그레이드 사전 확인 완료.

오류가 반환되지 않고 사전 확인이 성공했습니다.

upgrade-prechecks.log에 경고 및 알림이 있는지 검토합니다.

이벤트 보기에 대한 자세한 내용은 Amazon RDS 이벤트 보기 섹션을 참조하세요.

Aurora MySQL의 사전 확인 로그 형식

업그레이드 호환성 확인(사전 확인)이 완료되면 upgrade-prechecks.log 파일을 검토할 수 있습니다. 로그 파일에는 각 사전 확인에 대한 결과, 영향을 받는 객체 및 수정 정보가 포함됩니다.

오류로 인해 업그레이드가 차단되었습니다. 업그레이드를 다시 시도하기 전에 문제를 해결해야 합니다.

경고 및 알림은 덜 중요하지만 애플리케이션 워크로드와의 호환성 문제가 없는지 주의 깊게 검토하는 것이 좋습니다. 식별된 문제를 이른 시일 내에 해결합니다.

로그 파일의 형식은 다음과 같습니다.

  • targetVersion – Aurora MySQL 업그레이드의 MySQL 호환 버전입니다.

  • auroraServerVersion – 사전 확인이 실행된 Aurora MySQL 버전입니다.

  • auroraTargetVersion - 업그레이드하려는 Aurora MySQL 버전입니다.

  • checksPerformed - 수행된 사전 확인 목록을 포함합니다.

  • id - 실행 중인 사전 확인의 이름입니다.

  • title – 실행 중인 사전 확인에 대한 설명입니다.

  • status - 사전 확인이 성공했는지 실패했는지는 표시하지 않지만 다음과 같은 사전 확인 쿼리의 상태를 보여 줍니다.

    • OK – 사전 확인 쿼리가 성공적으로 실행되고 완료되었습니다.

    • ERROR – 사전 확인 쿼리를 실행하지 못했습니다. 이는 리소스 제약, 예기치 않은 인스턴스 재시작 또는 호환성 사전 확인 쿼리 중단과 같은 문제로 인해 발생할 수 있습니다.

      자세한 내용은 이 예제를 참조하세요.

  • description - 비호환성에 대한 일반적인 설명 및 문제 해결 방법입니다.

  • documentationLink - 해당하는 경우 관련 Aurora MySQL 또는 MySQL 설명서 링크가 여기에 표시됩니다. 자세한 내용은 Aurora MySQL에 대한 사전 확인 설명 참조 단원을 참조하십시오.

  • detectedProblems - 사전 확인에서 오류, 경고 또는 알림이 반환되면 비호환성 및 해당하는 경우 비호환 객체에 대한 세부 정보가 표시됩니다.

    • level - 사전 확인에서 감지한 비호환성 수준입니다. 유효한 수준은 다음과 같습니다.

      • Error – 비호환성을 해결할 때까지 업그레이드를 진행할 수 없습니다.

      • Warning - 업그레이드를 진행할 수 있지만 더 이상 사용되지 않는 객체, 구문 또는 구성이 감지되었습니다. 경고를 주의 깊게 검토하고 향후 릴리스에서 문제가 발생하지 않도록 조만간 해결하세요.

      • Notice - 업그레이드를 진행할 수 있지만 더 이상 사용되지 않는 객체, 구문 또는 구성이 감지되었습니다. 알림을 주의 깊게 검토하고 향후 릴리스에서 문제가 발생하지 않도록 조만간 해결하세요.

    • dbObject - 비호환성이 감지된 데이터베이스 객체의 이름입니다.

    • description - 비호환성에 대한 세부 설명 및 문제 해결 방법입니다.

  • errorCount – 감지된 비호환성 오류 수입니다. 이렇게 하면 업그레이드가 차단됩니다.

  • warningCount – 감지된 비호환성 경고 수입니다. 업그레이드는 차단되지 않지만 향후 릴리스에서 문제를 방지하기 위해 이른 시일 내에 해결하세요.

  • noticeCount – 감지된 비호환성 알림 수입니다. 업그레이드는 차단되지 않지만 향후 릴리스에서 문제를 방지하기 위해 이른 시일 내에 해결하세요.

  • Summary – 사전 확인 호환성 오류, 경고 및 알림 수에 대한 요약입니다.

Aurora MySQL에 대한 사전 확인 로그 출력 예제

다음 예제에서는 표시될 수 있는 사전 확인 로그 출력을 보여줍니다. 실행 중인 사전 검사에 대한 자세한 내용은 Aurora MySQL에 대한 사전 확인 설명 참조 섹션을 참조하세요.

사전 확인 상태 정상, 비호환성이 감지되지 않음.

사전 확인 쿼리가 성공적으로 완료됨. 비호환성이 감지되지 않음.

{ "id": "auroraUpgradeCheckIndexLengthLimitOnTinytext", "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny text columns", "status": "OK", "detectedProblems": [] },
사전 확인 상태 정상, 오류 감지됨

사전 확인 쿼리가 성공적으로 완료됨. 한 가지 오류가 감지됨.

{ "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns", "title": "Check for geometry columns on prefix indexes", "status": "OK", "description": "Consider dropping the prefix indexes of geometry columns and restart the upgrade.", "detectedProblems": [ { "level": "Error", "dbObject": "test25.sbtest1", "description": "Table `test25`.`sbtest1` has an index `idx_t1` 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 `idx_t1` ON `test25`.`sbtest1`;" }, }
사전 확인 상태 정상, 경고 감지됨

사전 확인에 성공하거나 실패하면 경고를 반환할 수 있음.

여기서 사전 확인 쿼리가 성공적으로 완료됨. 두 개의 경고가 감지됨.

{ "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" } ] }
사전 확인 상태 오류, 비호환성이 보고되지 않음

오류로 인해 사전 확인 쿼리가 실패했으므로 비호환성을 확인할 수 없음.

{ "id": "auroraUpgradeCheckForDatafilePathInconsistency", "title": "Check for inconsistency related to ibd file path.", "status": "ERROR", "description": "Can't connect to MySQL server on 'localhost:3306' (111) at 13/08/2024 12:22:20 UTC. This failure can occur due to low memory available on the instance for executing upgrade prechecks. Please check 'FreeableMemory' Cloudwatch metric to verify the available memory on the instance while executing prechecks. If instance ran out of memory, we recommend to retry the upgrade on a higher instance class." }

이 오류는 예기치 않은 인스턴스 재시작 또는 실행 중에 데이터베이스에서 호환성 사전 확인 쿼리가 중단되어 발생할 수 있습니다. 예를 들어 더 작은 DB 인스턴스 클래스에서는 인스턴스에서 사용 가능한 메모리가 부족할 때 이러한 현상이 발생할 수 있습니다.

FreeableMemory Amazon CloudWatch 지표를 사용하여 사전 확인을 실행하는 동안 인스턴스에서 사용 가능한 메모리를 확인할 수 있습니다. 인스턴스의 메모리가 부족하면 더 큰 DB 인스턴스 클래스에서 업그레이드를 다시 시도하는 것이 좋습니다. 경우에 따라 블루/그린 배포를 사용할 수 있습니다. 이를 통해 프로덕션 워크로드와 관계없이 ‘그린’ DB 클러스터에서 사전 확인 및 업그레이드를 실행할 수 있으며, 시스템 리소스도 사용합니다.

자세한 내용은 Aurora MySQL 데이터베이스의 메모리 사용량 문제 해결 단원을 참조하십시오.

사전 확인 요약, 오류 1개 및 경고 3개 감지됨

호환성 사전 확인에는 소스 및 대상 Aurora MySQL 버전에 대한 정보와 사전 확인 출력 끝부분의 오류, 경고 및 알림 수 요약도 포함됩니다.

예를 들어 다음 출력은 Aurora MySQL 2.11.6에서 Aurora MySQL 3.07.1로 업그레이드하려고 시도했음을 보여줍니다. 업그레이드에서 오류 1개, 경고 3개가 반환되었으며 알림은 반환되지 않았습니다. 오류가 반환되면 업그레이드를 진행할 수 없으므로 routineSyntaxCheck 호환성 문제를 해결하고 업그레이드를 다시 시도해야 합니다.

{ "serverAddress": "/tmp%2Fmysql.sock", "serverVersion": "5.7.12 - MySQL Community Server (GPL)", "targetVersion": "8.0.36", "auroraServerVersion": "2.11.6", "auroraTargetVersion": "3.07.1", "outfilePath": "/rdsdbdata/tmp/PreChecker.log", "checksPerformed": [{ ... output for each individual precheck ... . . { "id": "oldTemporalCheck", "title": "Usage of old temporal type", "status": "OK", "detectedProblems": [] }, { "id": "routinesSyntaxCheck", "title": "MySQL 8.0 syntax check for routine-like objects", "status": "OK", "description": "The following objects did not pass a syntax check with the latest MySQL 8.0 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'" }] }, . . . { "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 8 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" } ] }, . . . }], "errorCount": 1, "warningCount": 3, "noticeCount": 0, "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues." }

Aurora MySQL의 사전 확인 성능

호환성 사전 검사는 업그레이드를 위해 DB 인스턴스를 오프라인으로 전환하기 전에 실행되므로, 일반적인 상황에서는 실행 중에 DB 인스턴스 가동 중지가 발생하지 않습니다. 그러나 라이터 DB 인스턴스에서 실행되는 애플리케이션 워크로드에 영향을 미칠 수 있습니다. 사전 확인은 information_schema 테이블을 통해 데이터 딕셔너리에 액세스하며, 데이터베이스 객체가 많은 경우 속도가 느릴 수 있습니다. 다음 요인을 고려하세요.

  • 사전 확인 시간은 테이블, 열, 루틴 및 제약 조건과 같은 데이터베이스 객체 수에 따라 달라집니다. 객체 수가 많은 DB 클러스터를 실행하는 데 시간이 더 걸릴 수 있습니다.

    예를 들어 removedFunctionsCheck는 더 오래 걸리고 저장된 객체 수에 따라 더 많은 리소스를 사용할 수 있습니다.

  • 현재 위치 업그레이드의 경우 더 큰 DB 인스턴스 클래스(예: db.r5.24xlarge 또는 db.r6g.16xlarge)를 사용하면 더 많은 CPU를 사용하여 업그레이드가 더 빠르게 완료될 수 있습니다. 업그레이드 후 크기를 줄일 수 있습니다.

  • 여러 데이터베이스의 information_schema에 대한 쿼리는 느릴 수 있습니다. 특히 많은 객체와 더 작은 DB 인스턴스의 경우 더욱 그렇습니다. 이러한 경우 업그레이드에 복제, 스냅샷 복원 또는 블루/그린 배포를 사용하는 것이 좋습니다.

  • 사전 확인 리소스 사용량(CPU, 메모리)은 객체가 많을수록 증가할 수 있으므로 더 작은 DB 인스턴스에서 실행 시간이 길어집니다. 이러한 경우 업그레이드에 복제, 스냅샷 복원 또는 블루/그린 배포를 사용하여 테스트하는 것이 좋습니다.

    리소스 부족으로 인해 사전 확인이 실패하는 경우 상태 출력을 사용하여 사전 확인 로그에서 이를 감지할 수 있습니다.

    "status": "ERROR",

자세한 내용은 Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식Aurora MySQL 클러스터에 대한 주 버전 업그레이드 계획 단원을 참조하세요.

커뮤니티 MySQL 업그레이드 사전 확인 요약

MySQL 버전 5.7 및 8.0 간의 일반적인 비호환 목록은 다음과 같습니다.

  • MySQL 8.0에 지원되지 않는 기능을 MySQL 5.7 호환 DB 클러스터에서 사용해서는 안 됩니다.

    자세한 내용은 MySQL 설명서의 MySQL 8.0에서 제거된 기능을 참조하십시오.

  • 키워드 또는 예약된 단어 위반이 없어야 합니다. 이전에 예약되지 않은 일부 키워드는 MySQL 8.0에서 예약할 수 있습니다.

    자세한 내용은 MySQL 설명서의 키워드 및 예약어를 참조하십시오.

  • 유니코드 지원을 개선하기 위해 utf8mb3 charset을 사용하는 객체가 utf8mb4 charset을 사용하도록 변환하는 것을 고려하십시오. utf8mb3 문자 집합은 사용되지 않습니다. 또한, 현재 utf8mb4utf8 charset의 별칭이므로 utf8 대신 문자 집합 참조를 위한 utf8mb3 사용을 고려하십시오.

    자세한 내용은 MySQL 설명서의 utf8mb3 문자 집합(3바이트 UTF-8 유니코드 인코딩)을 참조하십시오.

  • 기본값이 아닌 행 형식을 가진 InnoDB 테이블은 없어야 합니다.

  • ZEROFILL 또는 display 길이 유형 속성이 없어야 합니다.

  • 기본 파티셔닝 지원이 없는 스토리지 엔진을 사용하는 분할된 테이블이 없어야 합니다.

  • MySQL 5.7 mysql 시스템 데이터베이스에는 MySQL 8.0 데이터 딕셔너리가 사용하는 테이블과 동일한 이름의 테이블이 없어야 합니다.

  • 사용되지 않는 데이터 형식이나 함수를 사용하는 테이블이 없어야 합니다.

  • 64자를 초과하는 외래 키 제약 조건 이름이 없어야 합니다.

  • sql_mode 시스템 변수 설정에 정의된 사용되지 않는 SQL 모드가 없어야 합니다.

  • 255자 길이를 초과하는 개별 ENUM 또는 SET 열 요소가 있는 테이블이나 저장 프로시저가 없어야 합니다.

  • 공유 InnoDB 테이블스페이스에 있는 테이블 파티션이 없어야 합니다.

  • 테이블스페이스 데이터 파일 경로에는 순환 참조가 없어야 합니다.

  • GROUP BY 절에서 ASC 또는 DESC 한정자를 사용하는 쿼리 및 저장 프로그램 정의가 없어야 합니다.

  • 제거된 시스템 변수가 없어야 하며, 시스템 변수는 MySQL 8.0의 새 기본값을 사용해야 합니다.

  • 날짜, 날짜/시간 또는 타임스탬프 값이 0(영)이면 안 됩니다.

  • 파일 제거 또는 손상으로 인한 스키마 불일치가 없어야 합니다.

  • FTS 문자열을 포함하는 테이블 이름이 없어야 합니다.

  • 다른 엔진에 속하는 InnoDB 테이블이 없어야 합니다.

  • MySQL 5.7에 유효하지 않은 테이블 또는 스키마 이름이 없어야 합니다.

실행 중인 사전 검사에 대한 자세한 내용은 Aurora MySQL에 대한 사전 확인 설명 참조 섹션을 참조하세요.

MySQL 8.0으로 업그레이드하는 방법에 대한 자세한 내용은 MySQL 설명서에서 MySQL 업그레이드를 참조하세요. MySQL 8.0의 변경 사항에 대한 일반적인 설명은 MySQL 설명서의 MySQL 8.0의 새로운 기능을 참조하세요.

Aurora MySQL 업그레이드 사전 확인

Aurora MySQL에는 버전 2에서 버전 3으로 업그레이드하는 데 필요한 다음과 같은 고유한 요구 사항이 있습니다.

  • 뷰, 루틴, 트리거 및 이벤트에는 SQL_CACHE, SQL_NO_CACHE, QUERY_CACHE와 같이 더 이상 사용되지 않는 SQL 구문이 없어야 합니다.

  • FTS 인덱스가 없는 테이블에는 FTS_DOC_ID 열이 없어야 합니다.

  • InnoDB 데이터 사전과 실제 테이블 정의 간에 열 정의 불일치가 없어야 합니다.

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

  • 이벤트 및 트리거에는 누락되었거나 빈 definer 또는 잘못된 생성 컨텍스트가 없어야 합니다.

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

  • Aurora MySQL 버전 3에서는 DDL 복구 및 빠른 DDL이 지원되지 않습니다. 데이터베이스에는 이러한 기능과 관련된 아티팩트가 없어야 합니다.

  • REDUNDANT 또는 COMPACT 행 형식의 테이블은 767바이트보다 큰 인덱스를 가질 수 없습니다.

  • tiny 텍스트 열에 정의된 인덱스의 접두사 길이는 255바이트를 초과할 수 없습니다. utf8mb4 문자 집합의 경우 지원되는 접두사 길이가 63자로 제한됩니다.

    MySQL 5.7에서는 innodb_large_prefix 파라미터를 사용하여 더 큰 접두사 길이를 허용했습니다. 이 파라미터는 MySQL 8.0에서 더 이상 사용되지 않습니다.

  • mysql.host 테이블에 InnoDB 메타데이터 불일치가 없어야 합니다.

  • 시스템 테이블에 열 데이터 유형 불일치가 없어야 합니다.

  • prepared 상태의 XA 트랜잭션이 없어야 합니다.

  • 뷰의 열 이름은 64자를 초과할 수 없습니다.

  • 저장 프로시저의 특수 문자 불일치가 없어야 합니다.

  • 테이블에 데이터 파일 경로 불일치가 없어야 합니다.

실행 중인 사전 검사에 대한 자세한 내용은 Aurora MySQL에 대한 사전 확인 설명 참조 섹션을 참조하세요.