Aurora MySQL バージョン 3 へのアップグレード - Amazon Aurora

Aurora MySQL バージョン 3 へのアップグレード

Aurora MySQL バージョン 1 または 2 からバージョン 3 にデータベースをアップグレードするための特定のアップグレードパスについては、次のいずれかの方法を使用できます。

  • Aurora MySQL バージョン 2 クラスターをバージョン 3 にアップグレードするには、インプレースアップグレードを実行します。「インプレースアップグレードの実行手順」の手順に従います。

    バージョン 2 クラスターのスナップショットを作成し、そのスナップショットを復元して新しいバージョン 3 クラスターを作成することもできます。「DB クラスターのスナップショットからの復元」の手順に従います。

  • Aurora MySQL バージョン 1 からアップグレードするには、まず Aurora MySQL バージョン 2 への中間アップグレードを実行します。Amazon Aurora MySQL DB クラスターのアップグレード に記載されているアップグレード方法のいずれかを使用します。

    その後、Aurora MySQL バージョン 2 から Aurora MySQL バージョン 3 にアップグレードします。Aurora MySQL バージョン 1 クラスター (MySQL 5.6 互換) から Aurora MySQL バージョン 3 への直接アップグレードは使用できません。

  • バックトラックを使用する Aurora MySQL バージョン 2 クラスターがある場合、インプレースアップグレードまたはスナップショットの復元方法を使用して Aurora MySQL バージョン 3 にアップグレードすることは現状できません。この制限は、バックトラック設定が有効になっているかどうかにかかわらず、バックトラックを使用するすべてのクラスタに適用されます。

    この場合、mysqldump のようなツールを使用して、論理的なダンプと復元を実行します。Aurora MySQL の mysqldump の使用の詳細については、mysqldump を使用した MySQL から Amazon Aurora への移行 を参照してください。

ヒント

場合によっては、アップグレードするときに 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 の設定を使用することをお勧めします。

  • MySQL 8.0 Community Edition で導入された新しい予約キーワードの使用方法について、Aurora MySQL バージョン 2 のデータベーススキーマとオブジェクト定義を確認してください。アップグレードの前に行ってください。詳細については、MySQL ドキュメントの「MySQL 8.0 の新しいキーワードと予約語」を参照してください。

MySQL 固有のアップグレードに関する考慮事項とヒントについては、MySQL リファレンスマニュアルMySQL 8.0 での変更を参照してください。例えば、コマンド mysqlcheck --check-upgrade を使用して、既存の Aurora MySQL データベースを分析し、潜在的なアップグレードの問題を特定します。

Aurora MySQL バージョン 1 からアップグレードするには、2 段階のプロセスを使用します。まず Aurora MySQL バージョン 2 にアップグレードし、その後、Aurora MySQL バージョン 3 にアップグレードします。Aurora MySQL バージョン 1 または 2 からのアップグレード手順については、Aurora MySQL バージョン 3 へのアップグレード を参照してください。インプレースアップグレードまたはスナップショット復元方法のいずれかを使用します。

注記

インプレースアップグレードまたはスナップショット復元技術を使用して 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 バージョン 1 からバージョン 3 へのアップグレードの例

次の例は、元のスナップショットが Aurora MySQL バージョン 3 に直接復元できないバージョンの場合の 2 段階アップグレードプロセスを示しています。代わりにそのスナップショットは、Aurora MySQL バージョン 3 にアップグレードできる中間バージョンを実行しているクラスターに復元されます。この中間クラスターには、関連付けられた DB インスタンスは必要ありません。次に、中間クラスターから別のスナップショットが作成されます。最後に、2 番目のスナップショットが復元され、新しい Aurora MySQL バージョン 3 クラスターとライター DB インスタンスが作成されます。

初期に使用スタートする Aurora MySQL バージョン 1 クラスターは、aurora-mysql-v1-to-v2 と名付けられています。Aurora MySQL バージョン 1.23.4 を実行しています。クラスター内に少なくとも 1 つの DB インスタンスがあります。

この例では、Aurora MySQL バージョン 2 のどのバージョンを 8.0.mysql_aurora.3.02.0 バージョンにアップグレードして、アップグレードされたクラスター上で使用できるかを確認します。この例では、中間バージョンとしてバージョン 2.10.2 を選択します。

$ aws rds describe-db-engine-versions --engine aurora-mysql \ --query '*[].{EngineVersion:EngineVersion,TargetVersions:ValidUpgradeTarget[*].EngineVersion} | [?contains(TargetVersions, `'8.0.mysql_aurora.3.02.0'`) == `true`]|[].EngineVersion' \ --output text ... 5.7.mysql_aurora.2.08.3 5.7.mysql_aurora.2.09.1 5.7.mysql_aurora.2.09.2 5.7.mysql_aurora.2.10.0 5.7.mysql_aurora.2.10.1 5.7.mysql_aurora.2.10.2 ...

次の例では、Aurora MySQL バージョン 1.23.4 から 2.10.2 が利用可能なアップグレードパスであることを確認します。したがって、実行している Aurora MySQL バージョンは 2.10.2 にアップグレードできます。その後、そのクラスターを 3.02.0 にアップグレードできます。

aws rds describe-db-engine-versions --engine aurora \ --query '*[].{EngineVersion:EngineVersion,TargetVersions:ValidUpgradeTarget[*].EngineVersion} | [?contains(TargetVersions, `'5.7.mysql_aurora.2.10.2'`) == `true`]|[].[EngineVersion]' \ --output text ... 5.6.mysql_aurora.1.22.5 5.6.mysql_aurora.1.23.0 5.6.mysql_aurora.1.23.1 5.6.mysql_aurora.1.23.2 5.6.mysql_aurora.1.23.3 5.6.mysql_aurora.1.23.4 ...

次の例では、aurora-mysql-v1-to-v2-snapshot という名前のスナップショットを作成します。これは元の Aurora MySQL バージョン 1 クラスターに基づいています。

$ aws rds create-db-cluster-snapshot \ --db-cluster-id aurora-mysql-v1-to-v2 \ --db-cluster-snapshot-id aurora-mysql-v1-to-v2-snapshot { "DBClusterSnapshotIdentifier": "aurora-mysql-v1-to-v2-snapshot", "DBClusterIdentifier": "aurora-mysql-v1-to-v2" }

次の例では、バージョン 1 のスナップショットから中間 Aurora MySQL バージョン 2 クラスターを作成します。この中間クラスターには aurora-mysql-v2-to-v3 という名前が付けられています。Aurora MySQL バージョン 2.10.2 を実行しています。

$ aws rds restore-db-cluster-from-snapshot \ --snapshot-id aurora-mysql-v1-to-v2-snapshot \ --db-cluster-id aurora-mysql-v2-to-v3 \ --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBCluster": { "AllocatedStorage": 1, "AvailabilityZones": [ "us-east-1a", "us-east-1d", "us-east-1f" ], ...

次の例では、中間 Aurora MySQL バージョン 2 クラスターからスナップショットを作成します。このスナップショットにはaurora-mysql-v2-to-v3-snapshot という名前が付けられています。これは、Aurora MySQL バージョン 3 クラスターを作成するために復元されるスナップショットです。

$ aws rds create-db-cluster-snapshot \ --db-cluster-id aurora-mysql-v2-to-v3 \ --db-cluster-snapshot-id aurora-mysql-v2-to-v3-snapshot { "DBClusterSnapshotIdentifier": "aurora-mysql-v2-to-v3-snapshot", "DBClusterIdentifier": "aurora-mysql-v2-to-v3" }

次のコマンドは、Aurora MySQL バージョン 3 クラスターを作成します。クラスターは aurora-mysql-v3-fully-upgraded と名付けられています。

$ aws rds restore-db-cluster-from-snapshot \ --snapshot-id aurora-mysql-v2-to-v3-snapshot \ --db-cluster-id aurora-mysql-v3-fully-upgraded \ --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.02.0 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBCluster": { "AllocatedStorage": 1, "AvailabilityZones": [ "us-east-1b", "us-east-1c", "us-east-1d" ], ...

Aurora MySQL バージョン 3 クラスターが作成されたので、次の例では、そのクラスターのライター DB インスタンスを作成します。クラスターとライターインスタンスが利用可能になったら、クラスターに接続して使用をスタートできます。元のクラスターのすべてのデータは、スナップショットステージごとに保持されます。

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

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 \ --master-user-password my_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 インデックスを作成し後にそのインデックスを削除すると、メタデータが残され、アップグレード中に問題を引き起こします。

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

{ "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 バージョン 1 または 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 での変更」を参照してください。