Aurora MySQL 버전 3으로 업그레이드 - Amazon Aurora
Aurora MySQL 버전 3에 대한 업그레이드 계획스냅샷 복원 방법을 사용하여 Aurora MySQL 버전 2에서 버전 3으로 업그레이드하는 예Aurora MySQL 버전 3의 업그레이드 문제 해결Aurora MySQL 버전 3에 대한 업그레이드 후 정리

Aurora MySQL 버전 3으로 업그레이드

Aurora MySQL 버전 2에서 버전 3으로 데이터베이스를 업그레이드하는 특정 업그레이드 경로에 대해서는 다음 방법 중 하나를 사용할 수 있습니다.

작은 정보

경우에 따라 업그레이드할 때 데이터베이스 로그를 CloudWatch에 업로드하는 옵션을 지정할 수 있습니다. 그렇다면 CloudWatch의 로그를 검사하여 업그레이드 작업 중에 발생하는 문제를 진단합니다. 이 섹션의 CLI 예에서는 --enable-cloudwatch-logs-exports 옵션을 사용하여 진단하는 방법을 보여줍니다.

Aurora MySQL 버전 3에 대한 업그레이드 계획

업그레이드할 적절한 시간 및 방법을 결정할 수 있도록 Aurora MySQL 버전 3과 현재 Aurora 및 MySQL 환경 사이의 차이점을 알아볼 수 있습니다.

  • RDS for MySQL 8.0 또는 MySQL 8.0 Community Edition에서 변환하는 경우 Aurora MySQL 버전 3과 MySQL 8.0 커뮤니티 에디션 비교 단원을 참조하세요.

  • Aurora MySQL 버전 2, RDS for MySQL 5.7 또는 커뮤니티 MySQL 5.7에서 업그레이드하는 경우 Aurora MySQL 버전 2와 Aurora MySQL 버전 3의 비교 섹션을 참조하세요.

  • 모든 사용자 지정 파라미터 그룹의 MySQL 8.0 호환 버전을 새로 만듭니다. 필요한 모든 사용자 파라미터 값을 새 파라미터 그룹에 적용합니다. 파라미터 변경에 대해 알아보려면 Aurora MySQL 버전 3에 대한 파라미터 변경 사항 섹션을 참조하세요.

    참고

    대부분의 파라미터 설정에서는 두 지점에서 사용자 정의 파라미터 그룹을 선택할 수 있습니다. 클러스터를 만들 때와 나중에 파라미터 그룹을 클러스터와 연결할 때입니다.

    그러나 lower_case_table_names 파라미터에 대해 기본값이 아닌 설정을 사용하는 경우 미리 이 설정으로 사용자 정의 파라미터 그룹을 설정해야 합니다. 그런 다음, 클러스터를 생성하기 위해 스냅샷 복원을 수행하는 경우 파라미터 그룹을 지정합니다. lower_case_table_names 파라미터에 대한 모든 변경은 클러스터를 생성한 후에는 효력이 없습니다.

    Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때 lower_case_table_names에 동일한 설정을 사용하는 것이 좋습니다.

    Aurora MySQL 기반 Aurora Global Database 사용 시 lower_case_table_names 파라미터가 활성화 되어 있는 경우 Aurora MySQL 버전 2에서 버전 3으로 현재 위치 업그레이드를 수행할 수 없습니다. 사용할 수 있는 메서드에 대한 자세한 내용은 메이저 버전 업그레이드 섹션을 참조하세요.

  • MySQL 8.0 Community Edition에 도입된 새로운 예약 키워드의 사용에 대해 Aurora MySQL 버전 2 데이터베이스 스키마 및 객체 정의를 검토하세요. 업그레이드하기 전에 완료하세요. 자세한 내용은 MySQL 설명서의 MySQL 8.0 새 키워드 및 예약어를 참조하세요.

또한 MySQL별 업그레이드 고려 사항과 팁에 대한 자세한 내용은 MySQL 참조 설명서의 MySQL 8.0의 변경 사항을 참조하세요. 예를 들어 mysqlcheck --check-upgrade 명령을 사용하여 기존 Aurora MySQL 데이터베이스를 분석하고 잠재적인 업그레이드 문제를 식별할 수 있습니다.

참고

현재 위치 업그레이드 또는 스냅샷 복원 기술을 사용하여 Aurora MySQL 버전 3으로 업그레이드할 때는 더 큰 DB 인스턴스 클래스를 사용하는 것이 좋습니다. 예로는 db.r5.24xlarge 및 db.r6g.16xlarge가 있습니다. 이렇게 하면 DB 인스턴스에서 사용 가능한 CPU 용량의 대부분을 사용하여 업그레이드 프로세스를 더 빠르게 완료할 수 있습니다. 메이저 버전 업그레이드가 완료된 후 원하는 DB 인스턴스 클래스로 변경할 수 있습니다.

업그레이드를 완료하면 Aurora MySQL 버전 3에 대한 업그레이드 후 정리에서 업그레이드 후 절차를 따를 수 있습니다. 마지막으로 애플리케이션의 기능과 성능을 테스트합니다.

RDS에서 MySQL 또는 커뮤니티 MySQL로 변환하는 경우 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션에 설명된 마이그레이션 절차를 따르세요. 경우에 따라 마이그레이션의 일부로 이진 로그 복제를 사용하여 데이터를 Aurora MySQL 버전 3 클러스터와 동기화할 수 있습니다. 그렇다면 소스 시스템은 MySQL 5.7과 호환되는 버전 또는 8.0.23 이하인 MySQL 8.0 호환 버전을 실행해야 합니다.

스냅샷 복원 방법을 사용하여 Aurora MySQL 버전 2에서 버전 3으로 업그레이드하는 예

다음 AWS CLI 예에서는 Aurora MySQL 버전 2 클러스터를 Aurora MySQL 버전 3으로 업그레이드하는 단계를 보여줍니다.

첫 번째 단계는 업그레이드할 클러스터의 버전을 결정하는 것입니다. 다음 AWS CLI 명령은 방법을 보여줍니다. 출력을 통해 원본 클러스터가 Aurora MySQL 버전 2.09.2를 실행하는 MySQL 5.7 호환 클러스터임을 확인합니다.

이 클러스터에는 하나 이상의 DB 인스턴스가 있습니다. 업그레이드 프로세스가 제대로 작동하려면 이 원본 클러스터에 작성자 인스턴스가 필요합니다.

$ aws rds describe-db-clusters --db-cluster-id cluster-57-upgrade-ok \
  --query '*[].EngineVersion' --output text

5.7.mysql_aurora.2.09.2

다음 명령은 특정 버전에서 사용할 수 있는 업그레이드 경로를 확인하는 방법을 보여줍니다. 이 경우 원본 클러스터는 5.7.mysql_aurora.2.09.2 버전을 실행 중입니다. 출력을 통해 이 버전을 Aurora MySQL 버전 3으로 업그레이드할 수 있음을 보여줍니다.

원본 클러스터에서 Aurora MySQL 버전 3으로 업그레이드하기에는 너무 낮은 버전 번호를 사용하는 경우 추가 단계가 업그레이드에 필요합니다. 먼저 스냅샷을 복원하여 Aurora MySQL 버전 3으로 업그레이드할 수 있는 새 클러스터를 만듭니다. 그런 다음, 해당 중간 클러스터의 스냅샷을 만듭니다. 마지막으로 중간 클러스터의 스냅샷을 복원하여 새 Aurora MySQL 버전 3 클러스터를 만듭니다.

$ aws rds describe-db-engine-versions --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.09.2 \
  --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion'
[
    "5.7.mysql_aurora.2.09.3",
    "5.7.mysql_aurora.2.10.0",
    "5.7.mysql_aurora.2.10.1",
    "5.7.mysql_aurora.2.10.2",
    "8.0.mysql_aurora.3.01.1",
    "8.0.mysql_aurora.3.02.0"
]

다음 명령을 통해 클러스터의 스냅샷을 생성하여 Aurora MySQL 버전 3으로 업그레이드합니다. 원본 클러스터는 온전하게 유지됩니다. 나중에 스냅샷에서 Aurora MySQL 버전 3 클러스터를 생성합니다.

aws rds create-db-cluster-snapshot --db-cluster-id cluster-57-upgrade-ok \
  --db-cluster-snapshot-id cluster-57-upgrade-ok-snapshot
{
  "DBClusterSnapshotIdentifier": "cluster-57-upgrade-ok-snapshot",
  "DBClusterIdentifier": "cluster-57-upgrade-ok",
  "SnapshotCreateTime": "2021-10-06T23:20:18.087000+00:00"
}

다음 명령을 통해 스냅샷을 Aurora MySQL 버전 3을 실행하는 새 클러스터로 복원합니다.

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id cluster-57-upgrade-ok-snapshot \
  --db-cluster-id cluster-80-restored --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.02.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
  "DBClusterIdentifier": "cluster-80-restored",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "Status": "creating"
}

스냅샷을 복원하면 클러스터의 스토리지를 설정하고 클러스터에서 사용할 수 있는 데이터베이스 버전을 설정합니다. 클러스터의 컴퓨팅 파워는 스토리지와 별개입니다. 따라서 클러스터 자체가 생성되면 클러스터에 대한 DB 인스턴스를 설정합니다. 다음 예에서는 db.r5 인스턴스 클래스 중 하나를 사용하여 작성자 DB 인스턴스를 생성합니다.

작은 정보

db.r3, db.r4, db.t2 또는 db.t3 같은 이전 인스턴스 클래스를 사용하여 DB 인스턴스를 생성하는 관리 스크립트가 있을 수 있습니다. 그렇다면 Aurora MySQL 버전 3에서 지원되는 인스턴스 클래스 중 하나를 사용하도록 스크립트를 수정합니다. Aurora MySQL 버전 3에서 사용할 수 있는 인스턴스 클래스에 대한 자세한 내용은 인스턴스 클래스 지원 섹션을 참조하세요.

$ aws rds create-db-instance --db-instance-identifier instance-running-version-3 \
  --db-cluster-identifier cluster-80-restored \
  --db-instance-class db.r5.xlarge --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-running-version-3",
  "DBClusterIdentifier": "cluster-80-restored",
  "DBInstanceClass": "db.r5.xlarge",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceStatus": "creating"
}

업그레이드가 완료되면 AWS CLI를 사용하여 클러스터의 Aurora별 버전 번호를 확인할 수 있습니다.

$ aws rds describe-db-clusters --db-cluster-id cluster-80-restored \
  --query '*[].EngineVersion' --output text
8.0.mysql_aurora.3.02.0

version 함수를 호출하여 데이터베이스 엔진의 MySQL별 버전을 확인할 수도 있습니다.

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.23    |
+-----------+

Aurora MySQL 버전 3의 업그레이드 문제 해결

Aurora MySQL 버전 3으로의 업그레이드가 성공적으로 완료되지 않으면 문제의 원인을 진단할 수 있습니다. 그런 다음 원본 데이터베이스 스키마 또는 테이블 데이터에 필요한 변경을 수행하고 업그레이드 프로세스를 다시 실행할 수 있습니다.

Aurora MySQL 버전 3으로의 업그레이드 프로세스가 실패하면 복원된 스냅샷에 대한 라이터 인스턴스를 생성한 다음 업그레이드하는 동안 문제가 감지됩니다. Aurora는 원본 5.7 호환 라이터 인스턴스를 남겨둡니다. 이렇게 하면 업그레이드를 수행하기 전에 Aurora가 실행하는 예비 검사에서 로그를 검사할 수 있습니다. 다음 예제는 Aurora MySQL 버전 3으로 업그레이드하기 전에 약간의 변경이 필요한 5.7 호환 데이터베이스로 시작합니다. 예에서는 처음 시도한 업그레이드가 성공하지 못한 경위와 로그 파일을 검사하는 방법을 보여줍니다. 또한 문제를 해결하고 성공적인 업그레이드를 실행하는 방법도 보여줍니다.

먼저 problematic-57-80-upgrade라는 MySQL 5.7 호환 클러스터를 새로 생성합니다. 이름에서 알 수 있듯이 이 클러스터에는 MySQL 8.0 호환 버전으로 업그레이드하는 동안 문제를 일으키는 하나 이상의 스키마 객체가 포함되어 있습니다.

$ aws rds create-db-cluster --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.10.0 \
  --db-cluster-identifier problematic-57-80-upgrade \
  --master-username my_username \
  --manage-master-user-password 
{
  "DBClusterIdentifier": "problematic-57-80-upgrade",
  "Status": "creating"
}

$ aws rds create-db-instance \
  --db-instance-identifier instance-preupgrade \
  --db-cluster-identifier problematic-57-80-upgrade \
  --db-instance-class db.t2.small --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-preupgrade",
  "DBClusterIdentifier": "problematic-57-80-upgrade",
  "DBInstanceClass": "db.t2.small",
  "DBInstanceStatus": "creating"
}

$ aws rds wait db-instance-available \
  --db-instance-identifier instance-preupgrade

업그레이드하려는 클러스터에서 문제가 있는 테이블을 소개합니다. FULLTEXT 인덱스를 생성한 다음 인덱스를 삭제하면 업그레이드 중에 문제를 일으키는 일부 메타데이터가 남습니다. 이 예제에서는 마스터 사용자 암호를 생성하고 이를 Secrets Manager에서 관리하는 --manage-master-user-password 옵션을 지정합니다. 자세한 내용은 Amazon Aurora 및 AWS Secrets Manager를 통한 암호 관리 단원을 참조하십시오. 또는 --master-password 옵션을 사용하여 암호를 직접 지정하고 관리할 수 있습니다.

$ mysql -u my_username -p \
  -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com

mysql> create database problematic_upgrade;
Query OK, 1 row affected (0.02 sec)

mysql> use problematic_upgrade;
Database changed
mysql> CREATE TABLE dangling_fulltext_index
    ->   (id INT AUTO_INCREMENT PRIMARY KEY, txtcol TEXT NOT NULL)
    ->   ENGINE=InnoDB;
Query OK, 0 rows affected (0.05 sec)

mysql> ALTER TABLE dangling_fulltext_index ADD FULLTEXT(txtcol);
Query OK, 0 rows affected, 1 warning (0.14 sec)

mysql> ALTER TABLE dangling_fulltext_index DROP INDEX txtcol;
Query OK, 0 rows affected (0.06 sec)

이 예에서는 업그레이드 절차 수행을 시도합니다. 원본 클러스터의 스냅샷을 만들고 스냅샷 생성이 완료될 때까지 기다립니다. 그런 다음 MySQL 8.0 호환 버전 번호를 지정하여 스냅샷을 복원합니다. 클러스터에 대한 라이터 인스턴스도 생성합니다. 이때 업그레이드 처리가 실제로 발생합니다. 그런 다음 라이터 인스턴스를 사용할 수 있을 때까지 기다립니다. 성공했는지 실패했는지에 관계없이 이때 업그레이드 프로세스가 완료됩니다.

작은 정보

AWS Management Console을 사용하여 스냅샷을 복원하면 Aurora가 자동으로 라이터 인스턴스를 생성하고 요청한 엔진 버전으로 업그레이드합니다.

$ aws rds create-db-cluster-snapshot --db-cluster-id problematic-57-80-upgrade \
  --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot
{
  "DBClusterSnapshotIdentifier": "problematic-57-80-upgrade-snapshot",
  "DBClusterIdentifier": "problematic-57-80-upgrade",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.0"
}

$ aws rds wait db-cluster-snapshot-available \
  --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id problematic-57-80-upgrade-snapshot \
  --db-cluster-id cluster-80-attempt-1 --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.02.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
  "DBClusterIdentifier": "cluster-80-attempt-1",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "Status": "creating"
}

$ aws rds create-db-instance --db-instance-identifier instance-attempt-1 \
  --db-cluster-identifier cluster-80-attempt-1 \
  --db-instance-class db.r5.xlarge --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-attempt-1",
  "DBClusterIdentifier": "cluster-80-attempt-1",
  "DBInstanceClass": "db.r5.xlarge",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceStatus": "creating"
}

$ aws rds wait db-instance-available \
  --db-instance-identifier instance-attempt-1

이제 새로 생성된 클러스터와 관련 인스턴스를 검사하여 업그레이드가 성공했는지 확인합니다. 클러스터와 인스턴스는 여전히 MySQL 5.7 호환 버전을 실행하고 있습니다. 이는 업그레이드가 실패했음을 의미합니다. 업그레이드가 실패하면 Aurora는 사용자가 로그 파일을 검사할 수 있도록 라이터 인스턴스만 남겨둡니다. 새로 생성된 클러스터로는 업그레이드 프로세스를 다시 시작할 수 없습니다. 원본 클러스터를 변경하여 문제를 수정한 후에는 업그레이드 단계를 다시 실행해야 합니다. 원본 클러스터의 스냅샷을 새로 만들고 다른 MySQL 8.0 호환 클러스터로 복원합니다.

$ aws rds describe-db-clusters \
  --db-cluster-identifier cluster-80-attempt-1 \
  --query '*[].[Status]' --output text
available
$ aws rds describe-db-clusters \
  --db-cluster-identifier cluster-80-attempt-1 \
  --query '*[].[EngineVersion]' --output text
5.7.mysql_aurora.2.10.0

$ aws rds describe-db-instances \
  --db-instance-identifier instance-attempt-1 \
  --query '*[].{DBInstanceStatus:DBInstanceStatus}' --output text
available
$ aws rds describe-db-instances \
  --db-instance-identifier instance-attempt-1 \
  --query '*[].[EngineVersion]' --output text
5.7.mysql_aurora.2.10.0

업그레이드 프로세스 동안 발생한 일에 대한 요약을 얻기 위해 새로 생성된 작성기 인스턴스에 대한 이벤트 목록을 구합니다. 이 예에서는 업그레이드 프로세스의 전체 시간 간격을 포함하기 위해 지난 600분 동안의 이벤트를 나열합니다. 목록의 이벤트가 반드시 시간순으로 나열되지는 않습니다. 강조 표시된 이벤트는 클러스터를 업그레이드할 수 없음을 확인하는 문제를 보여줍니다.

$ aws rds describe-events \
  --source-identifier instance-attempt-1 --source-type db-instance \
  --duration 600
{
    "Events": [
        {
            "SourceIdentifier": "instance-attempt-1",
            "SourceType": "db-instance",
            "Message": "Binlog position from crash recovery is mysql-bin-changelog.000001 154",
            "EventCategories": [],
            "Date": "2021-12-03T20:26:17.862000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1"
        },
        {
            "SourceIdentifier": "instance-attempt-1",
            "SourceType": "db-instance",
            "Message": "Database cluster is in a state that cannot be upgraded: PreUpgrade checks failed. More details can 
             be found in the upgrade-prechecks.log file. Please refer to 
             https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html#AuroraMySQL.mysql80-upgrade-troubleshooting 
             for more details on troubleshooting the cause of the upgrade failure",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2021-12-03T20:26:50.436000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1"
        },
        {
            "SourceIdentifier": "instance-attempt-1",
            "SourceType": "db-instance",
            "Message": "DB instance created",
            "EventCategories": [
                "creation"
            ],
            "Date": "2021-12-03T20:26:58.830000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1"
        },
...

문제의 정확한 원인을 진단하려면 새로 생성된 라이터 인스턴스에 대한 데이터베이스 로그를 검사합니다. 8.0 호환 버전으로 업그레이드가 실패하면 인스턴스에 파일 이름이 upgrade-prechecks.log인 로그 파일이 포함됩니다. 이 예에서는 해당 로그의 존재를 감지한 다음 검사를 위해 로컬 파일로 다운로드하는 방법을 보여줍니다.

$ aws rds describe-db-log-files --db-instance-identifier instance-attempt-1 \
  --query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2021-12-03.20
error/mysql-error-running.log.2021-12-03.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log

$ aws rds download-db-log-file-portion --db-instance-identifier instance-attempt-1 \
  --log-file-name upgrade-prechecks.log --starting-token 0 \
  --output text >upgrade_prechecks.log

upgrade-prechecks.log 파일은 JSON 형식입니다. 다른 JSON 래퍼 내에서 JSON 출력을 인코딩하지 않도록 --output text 옵션을 사용하여 다운로드합니다. Aurora MySQL 버전 3 업그레이드의 경우 이 로그에는 항상 특정 정보 메시시지와 경고 메시지가 포함됩니다. 업그레이드가 실패하는 경우에만 오류 메시지가 포함됩니다. 업그레이드가 성공하면 로그 파일이 생성되지 않습니다. 다음 발췌문에서는 찾을 수 있는 항목의 종류를 보여줍니다.

$ cat upgrade-prechecks.log
{
    "serverAddress": "/tmp%2Fmysql.sock",
    "serverVersion": "5.7.12",
    "targetVersion": "8.0.23",
    "auroraServerVersion": "2.10.0",
    "auroraTargetVersion": "3.02.0",
    "outfilePath": "/rdsdbdata/tmp/PreChecker.log",
    "checksPerformed": [

"detectedProblems"가 비어 있으면 업그레이드에서 해당 유형의 문제가 발생하지 않은 것입니다. 이러한 항목은 무시할 수 있습니다.

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

제거된 변수 또는 변경된 기본값에 대한 검사는 자동으로 수행되지 않습니다. Aurora는 물리적 구성 파일 대신 파라미터 그룹 메커니즘을 사용합니다. 변수 변경이 데이터베이스에 영향을 미치는지 여부에 관계없이 항상 이 CONFIGURATION_ERROR 상태의 일부 메시지를 수신합니다. 이러한 변경 사항에 대한 자세한 내용은 MySQL 설명서를 참조하세요.

{
    "id": "removedSysLogVars",
    "title": "Removed system variables for error logging to the system log configuration",
    "status": "CONFIGURATION_ERROR",
    "description": "To run this check requires full path to MySQL server
configuration file to be specified at 'configPath' key of options dictionary",
    "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-logging"
},

사용되지 않는 날짜 및 시간 데이터 형식에 대한 이 경고는 파라미터 그룹의 SQL_MODE 설정이 기본값으로 남아 있는 경우 발생합니다. 데이터베이스에 영향을 받는 유형의 열이 포함될 수도 있고 포함되지 않을 수도 있습니다.

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

detectedProblems 필드에 level 값이 Error인 항목이 포함되어 있으면 해당 문제를 수정할 때까지 업그레이드에 성공할 수 없는 것입니다.

{
    "id": "getDanglingFulltextIndex",
    "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": "problematic_upgrade.dangling_fulltext_index",
           "description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
        }
    ]
},
작은 정보

이러한 모든 오류를 요약하고 관련 객체 및 설명 필드를 표시하려면 upgrade-prechecks.log 파일의 내용에 대해 명령 grep -A 2 '"level": "Error"'를 실행합니다. 그러기 위해 각 오류 줄과 그 뒤에 두 줄이 표시됩니다. 여기에는 해당 데이터베이스 객체의 이름과 문제 수정 방법에 대한 지침이 포함되어 있습니다.

$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'
"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."

이 defaultAuthenticationPlugin 검사는 Aurora MySQL 버전 3 업그레이드에 대해 항상 이 경고 메시지를 표시합니다. Aurora MySQL 버전 3에서는 caching_sha2_password 대신 mysql_native_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
...
    "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"
}

upgrade-prechecks.log 파일의 끝 부분에는 각 유형의 경미하거나 심각한 문제가 발생한 검사의 수가 요약되어 있습니다. 0이 아닌 errorCount는 업그레이드가 실패했음을 나타냅니다.

    ],
    "errorCount": 1,
    "warningCount": 2,
    "noticeCount": 0,
    "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues."
}

다음 예제 시퀀스에서는 이 특정 문제를 해결하고 업그레이드 프로세스를 다시 실행하는 방법을 보여줍니다. 이번에는 업그레이드가 성공합니다.

먼저 원래 클러스터로 돌아갑니다. 그런 다음 테이블에서 OPTIMIZE TABLE tbl_name [, tbl_name] ...을 실행하여 다음 오류를 발생시킵니다.

Table `tbl_name` contains dangling FULLTEXT index. Kindly recreate the table before upgrade.

$ mysql -u my_username -p \
  -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com
mysql> show databases;
+---------------------+
| Database            |
+---------------------+
| information_schema  |
| mysql               |
| performance_schema  |
| problematic_upgrade |
| sys                 |
+---------------------+
5 rows in set (0.00 sec)
mysql> use problematic_upgrade;
mysql> show tables;
+-------------------------------+
| Tables_in_problematic_upgrade |
+-------------------------------+
| dangling_fulltext_index       |
+-------------------------------+
1 row in set (0.00 sec)
mysql> OPTIMIZE TABLE dangling_fulltext_index;
Query OK, 0 rows affected (0.05 sec)

자세한 내용은 MySQL 설명서에서 InnoDB 전체 텍스트 인덱스 최적화 및 OPTIMIZE TABLE 문을 참조하십시오.

대체 솔루션으로 잘못된 메타데이터가 있는 테이블과 동일한 구조와 내용을 가진 테이블을 새로 만들 수 있습니다. 실제로는 업그레이드 후에 이 테이블의 이름을 원본 테이블 이름으로 다시 바꿀 수 있습니다.

$ mysql -u my_username -p \
  -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com

mysql> show databases;
+---------------------+
| Database            |
+---------------------+
| information_schema  |
| mysql               |
| performance_schema  |
| problematic_upgrade |
| sys                 |
+---------------------+
5 rows in set (0.00 sec)

mysql> use problematic_upgrade;
mysql> show tables;
+-------------------------------+
| Tables_in_problematic_upgrade |
+-------------------------------+
| dangling_fulltext_index       |
+-------------------------------+
1 row in set (0.00 sec)

mysql> desc dangling_fulltext_index;
+--------+---------+------+-----+---------+----------------+
| Field  | Type    | Null | Key | Default | Extra          |
+--------+---------+------+-----+---------+----------------+
| id     | int(11) | NO   | PRI | NULL    | auto_increment |
| txtcol | text    | NO   |     | NULL    |                |
+--------+---------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> CREATE TABLE recreated_table LIKE dangling_fulltext_index;
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO recreated_table SELECT * FROM dangling_fulltext_index;
Query OK, 0 rows affected (0.00 sec)

mysql> drop table dangling_fulltext_index;
Query OK, 0 rows affected (0.05 sec)

이제 이전과 동일한 프로세스를 거칩니다. 원본 클러스터에서 스냅샷을 생성하고 새로운 MySQL 8.0 호환 클러스터로 스냅샷을 복원합니다. 그런 다음 라이터 인스턴스를 만들어 업그레이드 프로세스를 완료합니다.

$ aws rds create-db-cluster-snapshot --db-cluster-id problematic-57-80-upgrade \
  --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot-2
{
  "DBClusterSnapshotIdentifier": "problematic-57-80-upgrade-snapshot-2",
  "DBClusterIdentifier": "problematic-57-80-upgrade",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.0"
}

$ aws rds wait db-cluster-snapshot-available \
  --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot-2

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id problematic-57-80-upgrade-snapshot-2 \
  --db-cluster-id cluster-80-attempt-2 --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.02.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
  "DBClusterIdentifier": "cluster-80-attempt-2",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "Status": "creating"
}

$ aws rds create-db-instance --db-instance-identifier instance-attempt-2 \
  --db-cluster-identifier cluster-80-attempt-2 \
  --db-instance-class db.r5.xlarge --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-attempt-2",
  "DBClusterIdentifier": "cluster-80-attempt-2",
  "DBInstanceClass": "db.r5.xlarge",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceStatus": "creating"
}

$ aws rds wait db-instance-available \
  --db-instance-identifier instance-attempt-2

이번에는 업그레이드 완료 후 버전을 확인하면 Aurora MySQL 버전 3을 반영하도록 버전 번호가 변경되었음을 확인할 수 있습니다. 데이터베이스에 연결하여 MySQL 엔진 버전이 8.0과 호환되는지 확인할 수 있습니다. 업그레이드된 클러스터에 원래 업그레이드 문제를 일으킨 고정 버전의 테이블이 포함되어 있는지 확인합니다.

$ aws rds describe-db-clusters \
  --db-cluster-identifier cluster-80-attempt-2 \
  --query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.02.0
$ aws rds describe-db-instances \
  --db-instance-identifier instance-attempt-2 \
  --query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.02.0

$ mysql -h cluster-80-attempt-2.cluster-example123.us-east-1.rds.amazonaws.com \
  -u my_username -p

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.23    |
+-----------+
1 row in set (0.00 sec)

mysql> show databases;
+---------------------+
| Database            |
+---------------------+
| information_schema  |
| mysql               |
| performance_schema  |
| problematic_upgrade |
| sys                 |
+---------------------+
5 rows in set (0.00 sec)

mysql> use problematic_upgrade;
Database changed
mysql> show tables;
+-------------------------------+
| Tables_in_problematic_upgrade |
+-------------------------------+
| recreated_table               |
+-------------------------------+
1 row in set (0.00 sec)

Aurora MySQL 버전 3에 대한 업그레이드 후 정리

Aurora MySQL 버전 2 클러스터를 Aurora MySQL 버전 3으로 업그레이드한 후 다음과 같은 기타 정리 작업을 수행할 수 있습니다.

  • 모든 사용자 지정 파라미터 그룹의 MySQL 8.0 호환 버전을 새로 만듭니다. 필요한 모든 사용자 파라미터 값을 새 파라미터 그룹에 적용합니다.

  • CloudWatch 경보, 설정 스크립트 등을 업데이트하여 이름이 포괄적 언어 변경의 영향을 받은 모든 표지에 새 이름을 사용합니다. 이런 지표 목록은 Aurora MySQL 버전 3에 대한 포괄적 언어 변경 섹션을 참조하세요.

  • 모든 AWS CloudFormation 템플릿을 업데이트하여 이름이 포괄적 언어 변경의 영향을 받은 모든 구성 파라미터에 새 이름을 사용합니다. 이런 파라미터 전체 목록은 Aurora MySQL 버전 3에 대한 포괄적 언어 변경 섹션을 참조하세요.

공간 인덱스

Aurora MySQL 버전 3으로 업그레이드한 후 공간 인덱스와 관련된 객체 및 인덱스를 삭제하거나 다시 생성해야 하는지 확인합니다. MySQL 8.0 이전에 Aurora는 공간 리소스 식별자(SRID)를 포함하지 않은 인덱스를 사용하여 공간 쿼리를 최적화할 수 있었습니다. Aurora MySQL 버전 3은 SRID를 포함하는 공간 인덱스만 사용합니다. 업그레이드 중에 Aurora는 SRID 없는 모든 공간 인덱스를 자동으로 삭제하고 데이터베이스 로그에 경고 메시지를 인쇄합니다. 이러한 경고 메시지가 표시되면 업그레이드 후 SRID를 사용하여 새 공간 인덱스를 생성합니다. MySQL 8.0의 공간 함수와 데이터 유형 변경에 대한 자세한 내용은 MySQL 참조 설명서의 MySQL 8.0의 변경 사항을 참조하세요.