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、MySQL 5.7 の RDS、またはコミュニティ MySQL 5.7 からアップグレードする場合は、Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較 を参照してください。

  • カスタムパラメータグループの新しい MySQL 8.0 互換バージョンを作成します。必要なカスタムパラメータ値を新しいパラメータグループに適用します。Aurora MySQL バージョン 3 のパラメータ変更 に相談して、パラメータの変更について学びます。

    注記

    ほとんどのパラメータ設定では、2 つのポイントでカスタムパラメータグループを選択できます。これらは、クラスターの作成時や、パラメータグループをクラスターに関連付ける場合です。

    ただし、デフォルト以外の設定を lower_case_table_names パラメータに使用する場合は、事前にこの設定を使用してカスタム パラメータグループを設定する必要があります。その後、スナップショット復元を実行してクラスターを作成する際、パラメータグループを指定します。クラスター作成後のlower_case_table_names パラメータへの変更は、影響がありません。

    Aurora MySQL バージョン 2 からバージョン 3 にアップグレードする場合にも、同じ lower_case_table_names の設定を使用することをお勧めします。

    Aurora MySQL に基づく Aurora グローバルデータベースでは、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 のアップグレード後のクリーンアップ」のアップグレード後の手順に従います。最後に、アプリケーションの機能とパフォーマンスをテストします。

MySQL またはコミュニティ MySQL の RDS から変換する場合は、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 互換のクラスターであることが確認されます。

このクラスターには、少なくとも 1 つの 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 でサポートされているインスタンスクラスの 1 つを使用するようにスクリプトを変更します。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

また、データベースエンジンの MySQL 固有のバージョンを確認するには、version 関数を呼び出します。

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 互換バージョンへのアップグレード中に問題を引き起こすスキーマオブジェクトが、少なくとも 1 つ含まれています。

$ 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フィールドに、Error の level 値を持つエントリーが含まれる場合、これらの問題を修正するまでアップグレードは成功しません。

{
    "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"' コマンドを実行します。これにより、各エラー行とその後の 2 行が表示されます。これらの行には、対応するデータベースオブジェクトの名前と、問題の修正方法に関するガイダンスが含まれています。

$ 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."

Aurora MySQL バージョン 3 へのアップグレードでは、この defaultAuthenticationPlugin チェックは常にこの警告メッセージを表示します。これは、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 ファイルでは最後に、軽微なまたは重大な問題の種類ごとに、それらが検出されたチェックの数が要約されます。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] ... を実行すると次のようなエラーが発生します。

テーブル「tbl_name」には、ダングリング FULLTEXT インデックスが含まれています。アップグレードする前に、テーブルを再作成してください。

$ 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 ドキュメントの「Optimizing InnoDB Full-Text Indexes」(InnoDB フルテキストインデックスの最適化) および「OPTIMIZE TABLE Statement」(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 での変更」を参照してください。