' for the table to apply all the pending DDL updates. Then try the upgrade again."
}
]
}
```
事前チェックでは、テーブル `test.test` に保留中の高速 DDL オペレーションがあることが報告されます。
アップグレードを続行できるようにするには、テーブルを再構築し、アップグレードを再試行します。
テーブルスペースを再構築する前に、MySQL ドキュメントの「[Online DDL Operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html)」を参照して、フォアグラウンドトランザクションに対するロックとデータ移動の影響を理解してください。
```
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": []
}
```
**auroraGetDanglingFulltextIndex**
**事前チェックレベル: Error**
**ダングリング `FULLTEXT` インデックス参照を含むテーブル**
MySQL 5.6.26 より前では、全文検索インデックスを削除すると、非表示の `FTS_DOC_ID` 列と `FTS_DOC_ID_INDEX` 列が孤立する可能性があります。詳細については、「[バグ \$176012](https://bugs.mysql.com/bug.php?id=76012)」を参照してください。
これが発生した MySQL の以前のバージョンでテーブルが作成されている場合、Aurora MySQL バージョン 3 へのアップグレードが失敗する可能性があります。この事前チェックでは、MySQL 8.0 にアップグレードする前に、このような孤立した、または "ダングリング" FULLTEXT インデックスが DB クラスターに存在しないことを確認します。この事前チェックが失敗した場合は、そのようなダングリング FULLTEXT インデックスを含むテーブルを再構築します。
**出力例:**
```
{
"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` テーブルにダングリング FULLTEXT インデックスが含まれているため、エラーが事前チェックによってレポートされます。アップグレードを続行できるようにするには、FULLTEXT インデックスの補助テーブルをクリーンアップするようにテーブルを再構築します。`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": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**事前チェックレベル: Error**
**`ibd` ファイルパスに関連する不整合をチェックする**
この事前チェックは、Aurora MySQL バージョン 3.03.0 以前にのみ適用されます。この事前チェックでエラーが発生した場合は、Aurora MySQL バージョン 3.04 以降にアップグレードします。
**出力例:**
```
{
"id": "auroraUpgradeCheckForDatafilePathInconsistency",
"title": "Check for inconsistency related to ibd file path.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**事前チェックレベル: Error**
**スペース ID がゼロの FULLTEXT インデックスをチェックする**
MySQL では、InnoDB テーブルに [FULLTEXT インデックス](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html)を追加すると、多数の補助インデックステーブルスペースが作成されます。バージョン 5.6.20 で修正された以前のバージョンの MySQL の[バグ](https://bugs.mysql.com/bug.php?id=72132)により、これらの補助インデックステーブルが、独自の InnoDB テーブルスペースではなく、[システムテーブルスペース](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace)に作成された可能性があります。
このような補助テーブルスペースが存在する場合、アップグレードは失敗します。事前チェックエラーに記載されている FULLTEXT インデックスを再作成し、アップグレードを再試行します。
**出力例:**
```
{
"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 インデックスを削除して再作成すると、事前チェックは成功します。
テーブルスペースを再構築する前に、MySQL ドキュメントの「[Partitioning Operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning)」を参照して、フォアグラウンドトランザクションに対するロックとデータ移動の影響を理解してください。
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**事前チェックレベル: Error**
**準備済み状態の XA トランザクションをチェックする**
メジャーバージョンアップグレードプロセスの実行中に、Aurora MySQL バージョン 2 DB インスタンスを[クリーンシャットダウン](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)する必要があります。これにより、すべてのトランザクションがコミットまたはロールバックされ、InnoDB がすべての undo ログレコードを消去します。トランザクションのロールバックが必要なため、データベースに準備済み状態の [XA トランザクション](https://dev.mysql.com/doc/refman/5.7/en/xa.html)がある場合、クリーンシャットダウンの進行をブロックできます。このため、準備済みの XA トランザクションが検出されると、コミットまたはロールバックするアクションを実行するまでアップグレードを続行できなくなります。
`XA RECOVER` を使用して準備された状態で XA トランザクションを検索する方法の詳細については、MySQL ドキュメントの「[XA Transaction SQL Statements](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html)」を参照してください。XA トランザクションの状態の詳細については、MySQL ドキュメントの「[XA Transaction States](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html)」を参照してください。
**出力例:**
```
{
"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\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) テーブルと `XA RECOVER` 出力で詳細を確認できます。
トランザクションをコミットまたはロールバックする前に、[MySQL ドキュメント](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html)とアプリケーション要件を確認することをお勧めします。
```
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": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**事前チェックレベル: Error**
**現在のインスタンスクラスでアップグレードがサポートされているかどうかを確認する**
ライター [DB インスタンスクラス](Concepts.DBInstanceClass.md)が 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 で実行されているため、事前チェックはエラーを返します。
**auroraUpgradeCheckForInternalUsers**
**事前チェックレベル: Error**
**8.0 の内部ユーザーをチェックする**
この事前チェックは、Aurora MySQL バージョン 3.03.0 以前にのみ適用されます。この事前チェックでエラーが発生した場合は、Aurora MySQL バージョン 3.04 以降にアップグレードします。
**出力例:**
```
{
"id": "auroraUpgradeCheckForInternalUsers",
"title": "Check for 8.0 internal users.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForMasterUser**
**事前チェックレベル: Error**
**RDS マスターユーザーが存在するかどうかを確認する**
MySQL 8 は、権限管理をより簡単かつきめ細かなものにするために、[ロール](https://dev.mysql.com/doc/refman/8.0/en/roles.html)と[動的権限](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges)をサポートする新しい権限モデルを追加しました。この変更の一環として、Aurora MySQL は新しい `rds_superuser_role` を導入しました。これは、Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード時にデータベースのマスターユーザーに自動的に付与されます。
Aurora MySQL のマスターユーザーに割り当てられたロールと権限の詳細については、「[マスターユーザーアカウント権限](UsingWithRDS.MasterAccounts.md)」を参照してください。Aurora MySQL バージョン 3 のロールベースの特権モデルの詳細については、「[ロールベースの特権モデル](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)」を参照してください。
この事前チェックは、マスターユーザーがデータベースに存在することを確認します。マスターユーザーが存在しない場合、事前チェックに失敗します。アップグレードを続行できるようにするには、マスターユーザーのパスワードをリセットするか、ユーザーを手動で作成して、マスターユーザーを再作成します。次に、アップグレードを再試行します。マスターユーザーのパスワードのリセットについての詳細は、「[データベースマスターユーザーのパスワードの変更](Aurora.Modifying.md#Aurora.Modifying.Password)」を参照してください。
**出力例:**
```
{
"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": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**事前チェックレベル: Error**
**プレフィックスインデックスのジオメトリ列をチェックする**
[MySQL 8.0.12](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-12.html#mysqld-8-0-12-spatial-support) 以降、[GEOMETRY](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html) データ型を使用して列に[プレフィックス付き](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix)インデックスを作成することはできなくなります。詳細については、[WL\$111808](https://dev.mysql.com/worklog/task/?id=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": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**事前チェックレベル: Error**
**ストアドプロシージャの特殊文字に関連する不整合をチェックする**
MySQL 8.0 より前では、データベース名、テーブル名、およびその他のオブジェクトは、データディレクトリ内のファイル、つまりファイルベースのメタデータに対応していました。MySQL 8.0 へのアップグレードの一環として、すべてのデータベースオブジェクトは、`mysql` スキーマに保存されている新しい内部データディクショナリテーブルに移行され、新しく実装された[アトミックデータディクショナリ](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html)をサポートします。ストアドプロシージャの移行の一環として、各プロシージャのプロシージャ定義と本文は、新しいデータディクショナリに取り込まれるときに検証されます。
MySQL 8 より前では、場合によっては、保存されたルーチンを作成したり、特殊文字を含むプロシージャを `mysql.proc` テーブルに直接挿入したりできました。例えば、非準拠の[改行なしスペース文字](https://en.wikipedia.org/wiki/Non-breaking_space) `\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": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**事前チェックレベル: Error**
**`sys` スキーマのオブジェクトタイプの不一致を確認する**
[sys スキーマ](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html)は、ユーザーが DB インスタンスのトラブルシューティング、最適化、モニタリングを行うのに役立つ MySQL データベース内のオブジェクトとビューのセットです。Aurora MySQL バージョン 2 からバージョン 3 へのメジャーバージョンアップグレードを実行すると、`sys` スキーマビューが再作成され、新しい Aurora MySQL バージョン 3 定義に更新されます。
アップグレードの一環として、`sys` スキーマ内のオブジェクトがビューではなくストレージエンジン ([INFORMATION\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html) の `sys_config/BASE TABLE`) を使用して定義されている場合、アップグレードは失敗します。このようなテーブルは、`information_schema.tables` テーブルにあります。これは予想される動作ではありませんが、ユーザーエラーが原因で発生する場合があります。
この事前チェックでは、すべての `sys` スキーマオブジェクトを検証して、ユーザーが正しいテーブル定義を使用し、ビューが誤って InnoDB または MyISAM テーブルとして定義されていないことを確認します。問題を解決するには、返されたオブジェクトの名前を変更または削除して手動で修正します。次に、アップグレードを再試行します。
**出力例:**
```
{
"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\$1global\$1by\$1latency](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) ビューに、アップグレードの進行を妨げているタイプの不一致があることが報告されます。
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)
```
この問題を解決するには、[正しい定義](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql)でビューを削除して再作成するか、名前を変更します。アップグレードプロセス中に、ビューは正しいテーブル定義で自動的に作成されます。
```
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": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**事前チェックレベル: Error**
**ビュー内の列名の上限を確認する**
MySQL の[列名の最大許容長](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html)は 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": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**事前チェックレベル: Error**
**小さな列でプレフィックスの長さが 255 バイトを超えるインデックスが定義されているテーブルをチェックする**
MySQL で[バイナリデータ型](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html)を使用して列にインデックスを作成する場合は、インデックス定義に[プレフィックス](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix)の長さを追加する必要があります。MySQL 8.0 より前では、場合によっては、このようなデータ型の最大許容サイズを超えるプレフィックス長を指定できました。例として `TINYTEXT` 列と `TINYBLOB` 列があります。最大許容データサイズは 255 バイトですが、これより大きいインデックスプレフィックスが許可されていました。詳細については、MySQL ドキュメントの「[InnoDB Limits](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html)」を参照してください。
この事前チェックが失敗した場合は、問題のあるインデックスを削除するか、`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` テーブルのエラーを報告します。
このテーブルの定義を見ると、プライマリキーの `TINYTEXT` 列 `col1` のプレフィックスが 65 であることがわかります。テーブルは、1 文字あたり 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": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**事前チェックレベル: Error**
**`mysql.host` テーブルに欠落している InnoDB メタデータの不整合を確認する**
これは、RDS サービスによって実行される内部のみの事前チェックです。エラーはアップグレード時に自動的に処理されます。これらのエラーは無視して問題ありません。
この事前チェックでエラーが発生した場合は、[AWS サポート](https://aws.amazon.com/support)でケースを開き、メタデータの不整合の解決をリクエストします。または、論理ダンプを実行してから新しい Aurora MySQL バージョン 3 DB クラスターに復元することで、アップグレードを再試行することもできます。
**auroraUpgradeCheckForInvalidUtf8mb3ColumnComments**
**事前チェックレベル: Error**
**無効な utf8mb3 列コメントをチェックする**
この事前チェックでは、無効な utf8mb3 文字エンコーディングの列コメントを含むテーブルを特定します。MySQL 8.0 では、列コメントを含むメタデータの文字エンコーディングに、より厳格な検証が適用されます。列コメントに含まれている文字が utf8mb3 文字セットの有効な文字でない場合、アップグレードは失敗します。
この問題の最も一般的な原因は、列コメントに BMP (基本多言語面) 以外の文字が存在することです。BMP 以外の文字には 4 バイトの UTF-8 エンコード (utf8mb4) が必要ですが、utf8mb3 は 3 バイトのシーケンスのみをサポートしており、これらの文字を表すことはできません。
この問題を解決するには、アップグレードを試みる前に、列コメントを変更して BMP 以外の文字を削除または置換する必要があります。列コメントを更新するには、`ALTER TABLE` ステートメントを使用できます。
**出力例:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.t2",
"description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
}
```
事前チェックでは、1 つ以上の列コメントに無効な utf8mb3 文字 (特に BMP 以外の文字) が `test.t2` テーブルに含まれていることがレポートされます。
この問題を解決するには、問題のある列を特定し、コメントを更新できます。まず、テーブル構造を調べて、コメントのある列を特定します。
```
mysql> SHOW CREATE TABLE test.t2\G
```
問題のあるコメントを含む列を特定したら、`ALTER TABLE` ステートメントを使用して更新します。例:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
または、コメントを完全に削除することもできます。
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
問題のある列コメントをすべて更新すると、事前チェックに合格し、アップグレードを続行できます。
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
列コメントを変更する前に、これらのコメントに依存するアプリケーションコードやドキュメントが適切に更新されていることを確認してください。アプリケーションで BMP 以外の文字が必要な場合は、Unicode サポートを強化するために utf8mb4 文字セットへの移行を検討してください。
## 警告
次の事前チェックは、事前チェックが失敗してもアップグレードを続行できるときに警告を生成します。
**Topics**
+ [警告を報告する MySQL の事前チェック](#precheck-descriptions-warnings.mysql)
+ [警告を報告する Aurora MySQL の事前チェック](#precheck-descriptions-warnings.aurora)
### 警告を報告する MySQL の事前チェック
次の事前チェックは、コミュニティ MySQL から提供されています。
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**事前チェックレベル: Warning**
**デフォルトの認証プラグインに関する新しい考慮事項**
MySQL 8.0 では、`caching_sha2_password` 認証プラグインが導入され、廃止された `mysql_native_password` プラグインよりもパスワード暗号化の安全性とパフォーマンスが向上しました。Aurora MySQL バージョン 3 の場合、データベースユーザーに使用されるデフォルトの認証プラグインは `mysql_native_password` プラグインです。
この事前チェックは、このプラグインが削除され、将来のメジャーバージョンリリースでデフォルトが変更されることを警告します。この変更の前に、アプリケーションクライアントとユーザーの互換性を評価することを検討してください。
詳細については、MySQL ドキュメントの「[caching\$1sha2\$1password Compatibility Issues and Solutions](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues)」を参照してください。
**出力例:**
```
{
"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"
},
```
**maxdbFlagCheck**
**事前チェックレベル: Warning**
**廃止された `MAXDB` `sql_mode` フラグの使用**
MySQL 8.0 では、非推奨の [sql\$1mode](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode) システム変数オプションがいくつか[削除](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)されました。そのうちの 1 つは `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` を設定した後にプロシージャを再作成します。
[MySQL ドキュメント](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html)によると、MySQL は、ルーチンを作成または変更したときに有効な `sql_mode` 設定を保存します。ルーチンの開始時の `sql_mode` 設定に関係なく、常にこの設定でルーチンを実行します。
`sql_mode` を変更する前に、MySQL ドキュメントの「[Server SQL Modes](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html)」を参照してください。アプリケーションへの影響の可能性を慎重に評価します。
サポートされていない `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": []
}
```
**mysqlDollarSignNameCheck**
**事前チェックレベル: Warning**
**オブジェクト名に非推奨の単一のドル記号が使用されているかどうかをチェックする**
[MySQL 8.0.32](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-32.html#mysqld-8-0-32-deprecation-removal) 以降、引用符で囲まれていない識別子の最初の文字としてドル記号 (`$`) の使用が廃止されます。`$` を最初の文字として含むスキーマ、テーブル、ビュー、列、またはルーチンがある場合、この事前チェックは警告を返します。この警告はアップグレードの進行を妨げませんが、すぐに対応して解決することをお勧めします。[MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html) 以降、このような識別子は警告ではなく構文エラーを返します。
**出力例:**
```
{
"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` テーブルに最初の文字として `$` が含まれているため、事前チェックは警告を報告します。
**reservedKeywordsCheck**
**事前チェックレベル: Warning**
**新しい予約キーワードと競合する名前を持つデータベースオブジェクトの使用**
このチェックは、新しい予約キーワードと競合する名前を持つデータベースオブジェクトの使用を確認する点で、[routineSyntaxCheck](#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"
}
]
}
```
この警告は、確認すべきアプリケーションクエリが存在する可能性があることを知らせます。アプリケーションクエリが[文字列リテラルから正しくエスケープ](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html)されていない場合、MySQL 8.0 にアップグレードした後にエラーが発生する可能性があります。アプリケーションを確認するために、バージョン 3 で実行されている Aurora MySQL DB クラスターのクローンまたはスナップショットに対してテストを実行します。
アップグレード後に失敗するエスケープされていないアプリケーションクエリの例:
```
SELECT * FROM escape;
```
アップグレード後に成功する、正しくエスケープされたアプリケーションクエリの例:
```
SELECT * FROM 'escape';
```
**utf8mb3Check**
**事前チェックレベル: Warning**
**`utf8mb3` 文字セットの使用**
MySQL 8.0 では、`utf8mb3` 文字セットは廃止され、今後の MySQL メジャーバージョンで削除されます。この事前チェックは、この文字セットを使用するデータベースオブジェクトが検出された場合に警告を生成するために実装されます。これによりアップグレードの進行が妨げられることはありませんが、MySQL 8.0 のデフォルトである `utf8mb4` 文字セットにテーブルを移行することを検討するよう強くお勧めします。[utf8mb3](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html) と [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html) の詳細については、MySQL ドキュメントの「[Converting Between 3-Byte and 4-Byte Unicode Character Sets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html)」を参照してください。
**出力例:**
```
{
"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 ドキュメントの「[Converting Between 3-Byte and 4-Byte Unicode Character Sets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html)」を参照してください。
**zeroDatesCheck**
**事前チェックレベル: Warning**
**DATE、DATETIME、および TIMESTAMP のゼロ値**
MySQL では、DATE、DATETIME、および TIMESTAMP の列でゼロ値の使用に関するより厳格なルールが適用されるようになりました。`NO_ZERO_IN_DATE` および `NO_ZERO_DATE SQL` モードは、今後の MySQL リリースで `strict` モードとマージされるため、`strict` モードと組み合わせて使用することをお勧めします。
事前チェックの実行時に、データベース接続の `sql_mode` 設定にこれらのモードが含まれていない場合、事前チェックで警告が発生します。ユーザーは、ゼロ値を含む DATE、DATETIME、および TIMESTAMP 値を挿入できる場合があります。ただし、ゼロ値は、将来動作が変化し、正しく機能しない可能性があるため、有効な値に置き換えることを強くお勧めします。これは警告であるため、アップグレードはブロックされませんが、アクションを実行する計画を開始することをお勧めします。
**出力例:**
```
{
"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"
}
]
}
```
### 警告を報告する Aurora MySQL の事前チェック
次の事前チェックは、Aurora MySQL に固有のものです。
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**事前チェックレベル: Warning**
**クラスターのロールバックセグメント履歴リストの長さが長いかどうかを確認する**
[auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions) で説明されているように、メジャーバージョンアップグレードプロセスの実行中に、Aurora MySQL バージョン 2 DB インスタンスを[クリーンシャットダウン](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)する必要があります。これにより、すべてのトランザクションがコミットまたはロールバックされ、InnoDB がすべての undo ログレコードを消去します。
DB クラスターのロールバックセグメント履歴リストの長さ (HLL) が長い場合、InnoDB が undo ログレコードの消去を完了するのにかかる時間が長くなり、メジャーバージョンのアップグレードプロセス中にダウンタイムが長くなる可能性があります。事前チェックで DB クラスターの HLL が高いことが検出されると、警告を発生します。これによりアップグレードの進行が妨げられることはありませんが、DB クラスターの HLL を注意深くモニタリングすることをお勧めします。低いレベルに保つと、メジャーバージョンのアップグレードに必要なダウンタイムが短縮されます。HLL のモニタリングの詳細については、「[InnoDB 履歴リストの長さが大幅に増加しました](proactive-insights.history-list.md)」を参照してください。
**出力例:**
```
{
"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."
}
]
}
```
事前チェックでは、データベースクラスターの InnoDB undo HLL が長い (82989114) ことが検出されたため、警告が返されます。アップグレードは続行されますが、パージする undo の量によっては、アップグレードプロセスに必要なダウンタイムが延長される可能性があります。
本番環境でアップグレードを実行する前に、DB クラスターの[オープントランザクション](proactive-insights.history-list.md)を調査し、HLL が管理可能なサイズに保たれていることを確認することをお勧めします。
**auroraUpgradeCheckForUncommittedRowModifications**
**事前チェックレベル: Warning**
**コミットされていない行の変更が多数あるかどうかを確認する**
[auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions) で説明されているように、メジャーバージョンアップグレードプロセスの実行中に、Aurora MySQL バージョン 2 DB インスタンスを[クリーンシャットダウン](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)する必要があります。これにより、すべてのトランザクションがコミットまたはロールバックされ、InnoDB がすべての undo ログレコードを消去します。
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\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) テーブルを使用します。ライター 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 ドキュメントの「[Optimizing InnoDB Transaction Management](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)」を参照してください。
## 注意
次の事前チェックは、事前チェックに失敗してもアップグレードを続行できるときに通知を生成します。
**sqlModeFlagCheck**
**事前チェックレベル: Notice**
**廃止された `sql_mode` フラグの使用**
`MAXDB` に加えて、次のその他の `sql_mode` オプションが[削除](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)されました: `DB2`、`MSSQL`、`MYSQL323`、`MYSQL40`、`ORACLE`、`POSTGRESQL`、`NO_FIELD_OPTIONS`、`NO_KEY_OPTIONS`、`NO_TABLE_OPTIONS`。MySQL 8.0 以降、これらの値を `sql_mode` システム変数に割り当てることはできません。この事前チェックでこれらの `sql_mode` 設定を使用して開いているセッションが見つかった場合は、DB インスタンスと DB クラスターのパラメータグループ、およびクライアントアプリケーションと設定が無効にするよう更新されていることを確認してください。– 詳細については、「[MySQL ドキュメント](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)」を参照してください。
**出力例:**
```
{
"id": "sqlModeFlagCheck",
"title": "Usage of obsolete sql_mode flags",
"status": "OK",
"detectedProblems": []
}
```
これらの事前チェックの失敗を解決するには、「[maxdbFlagCheck](#maxdbFlagCheck)」を参照してください。
## エラー、警告、または通知
次の事前チェックは、事前チェックの出力に応じてエラー、警告、または通知を返す場合があります。
**checkTableOutput**
**事前チェックレベル: Error、Warning、または Notice**
**`check table x for upgrade` コマンドによって報告された問題**
Aurora MySQL バージョン 3 へのアップグレードを開始する前に、`check table for upgrade` は DB クラスター内のユーザースキーマの各テーブルで実行されます。この事前チェックは [checkTableMysqlSchema](#checkTableMysqlSchema) とは異なります。
`check table for upgrade` コマンドは、MySQL の新しいバージョンへのアップグレード中に発生する可能性のある問題がないかテーブルを調べます。アップグレードを試行する前にこのコマンドを実行すると、互換性がない箇所を事前に特定して解決できるため、実際のアップグレードプロセスがよりスムーズになります。
このコマンドは、次のような各テーブルに対してさまざまなチェックを実行します。
+ テーブル構造とメタデータがターゲットの MySQL バージョンと互換性があることを確認する
+ テーブルで使用される廃止または削除された機能を確認する
+ データ損失なしでテーブルを適切にアップグレードできることを確認する
他の事前チェックとは異なり、`check table` の出力に応じてエラー、警告、または通知を返すことがあります。この事前チェックでテーブルが返された場合は、アップグレードを開始する前に、それらをリターンコードとメッセージとともに慎重に確認してください。詳細については、MySQL ドキュメントの「[CHECK TABLE Statement](https://dev.mysql.com/doc/refman/5.7/en/check-table.html)」を参照してください。
ここでは、エラーの例と警告の例を示します。
**エラーの例:**
```
{
"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 Constraints](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html)」によると、外部キーで参照される列には関連付けられたインデックスが必要であり、親/子列は同じデータ型を使用する必要があります。
これがインデックスの欠落またはデータ型の不一致に関連しているかどうかを確認するには、データベースにログインし、セッション変数 [foreign\$1key\$1checks](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#foreign-key-checks) を一時的に無効にしてテーブル定義を確認します。そうすると、問題の子制約 (`fk_pname`) が `p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL` を使用して親テーブル `name varchar(20) NOT 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."
}
]
}
```
`test.orders` テーブルの `delete_audit_trigg` トリガーに `CREATED` 属性がないため、事前チェックは警告を報告します。MySQL ドキュメントの「[Checking Version Compatibility](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-version-compatibility)」によると、このメッセージは情報であり、MySQL 5.7.2 より前に作成されたトリガーに対して印刷されます。
これは警告であるため、アップグレードの進行は妨げられません。ただし、問題を解決する場合は、問題のトリガーを再作成できます。事前チェックは警告なしで成功します。
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": []
},
```
# インプレースアップグレードの実行手順
[メジャーバージョンの Aurora MySQL インプレースアップグレードの仕組み](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence) の背景のマテリアルを確認することをお勧めします。
「[Aurora MySQL クラスターのメジャーバージョンアップグレードの計画](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning)」の説明に従い、アップグレード前の計画とテストを行います。
## コンソール
次の例では、`mydbcluster-cluster` DB クラスターを Aurora MySQL バージョン 3.04.1 にアップグレードします。
**Aurora MySQL DB クラスターのメジャーバージョンをアップグレードするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. 元の DB クラスターでカスタムパラメータグループを使用した場合は、新しいメジャーバージョン互換のパラメータグループを作成します。新しいパラメータグループの設定パラメータに必要な調整を行います。詳細については、「[インプレースアップグレードはクラスターのパラメータグループにどのような影響を与えるか](#AuroraMySQL.Upgrading.ParamGroups)」を参照してください。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. リストから、変更する DB クラスターを選択します。
1. **Modify** を選択します。
1. **[Version]** (バージョン) で、新しい Aurora MySQL のメジャーバージョンを選択します。
通常、メジャーバージョンの最新のマイナーバージョンを使用することをお勧めします。ここでは、現在のデフォルトバージョンを選択します。
![\[Aurora MySQL DB クラスターのバージョン 2 からバージョン 3 へのインプレースアップグレード\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. **[Continue]** (続行) をクリックします。
1. 次のページで、アップグレードを実行するタイミングを指定します。[**次の定期メンテナンス期間中**] または [**今すぐ**] を選択します。
1. (オプション) アップグレード中、RDS コンソールの [**イベント**] ページを定期的に確認します。これにより、アップグレードの進行状況をモニタリングし、問題を特定することができます。アップグレードで問題が発生した場合は、[Aurora MySQL インプレースアップグレードのトラブルシューティング](AuroraMySQL.Upgrading.Troubleshooting.md) を参照してステップを実行してください。
1. この手順のスタート時に、新しいパラメータグループを作成した場合は、アップグレードしたクラスターにカスタムパラメータグループを関連付けます。詳細については、「[インプレースアップグレードはクラスターのパラメータグループにどのような影響を与えるか](#AuroraMySQL.Upgrading.ParamGroups)」を参照してください。
**注記**
このステップを実行するには、クラスターを再起動して新しいパラメータグループを適用する必要があります。
1. (オプション) アップグレード後のテストが完了したら、アップグレードのスタート時に Aurora によって作成された手動スナップショットを削除します。
## AWS CLI
Aurora MySQL DB クラスターのメジャーバージョンをアップグレードするには、次の必須パラメータを指定しながら、AWS CLI の [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを実行します。
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` または `--no-apply-immediately`
クラスターでカスタムパラメータグループを使用する場合は、次のオプションの 1 つ、または両方を含めます。
+ `--db-cluster-parameter-group-name`、クラスターがカスタムクラスターのパラメータグループを使用している場合
+ `--db-instance-parameter-group-name`、クラスター内のインスタンスがカスタム DB のパラメータグループを使用している場合
次の例では、`sample-cluster` DB クラスターを Aurora MySQL バージョン 3.04.1 にアップグレードします。アップグレードは、次のメンテナンスウィンドウを待つことなく、すぐに実行されます。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 8.0.mysql_aurora.3.04.1 \
--allow-major-version-upgrade \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 8.0.mysql_aurora.3.04.1 ^
--allow-major-version-upgrade ^
--apply-immediately
```
他の CLI `modify-db-cluster` コマンドをと組み合わせて、アップグレードを実行および検証するための自動化されたエンドツーエンドのプロセスを作成できます。詳細な説明と例については、「[Aurora MySQL インプレースアップグレードのチュートリアル](AuroraMySQL.Upgrading.Tutorial.md)」を参照してください。
**注記**
クラスターが Aurora Global Database の一部である場合、インプレースアップグレードの手順は若干異なります。`modify-db-cluster` の代わりに、[modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) コマンドオペレーションを呼び出します。詳細については、「[グローバルデータベースのインプレースメジャーアップグレード](#AuroraMySQL.Upgrading.GlobalDB)」を参照してください。
## RDS API
Aurora MySQL DB クラスターのメジャーバージョンをアップグレードするには、次の必須パラメータを指定して RDS API の [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) オペレーションを使用します。
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` (`true`、または `false` に設定)
**注記**
クラスターが Aurora Global Database の一部である場合、インプレースアップグレードの手順は若干異なります。 `ModifyDBCluster` の代わりに、[ modifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) オペレーションを呼び出します。詳細については、「[グローバルデータベースのインプレースメジャーアップグレード](#AuroraMySQL.Upgrading.GlobalDB)」を参照してください。
## インプレースアップグレードはクラスターのパラメータグループにどのような影響を与えるか
Aurora パラメータグループには、MySQL 5.7 または 8.0 と互換性のあるクラスターとは異なる構成設定のセットがあります。インプレースアップグレードを実行する際、アップグレードされたクラスターとそのすべてのインスタンスで、対応するクラスターおよびインスタンスのパラメータグループを使用する必要があります。
クラスターとインスタンスは、デフォルトの 5.7 互換パラメータグループを使用する場合があります。その場合、アップグレードされたクラスターとインスタンスは、デフォルトの 8.0 互換パラメータグループで開始されます。クラスターとインスタンスでカスタムパラメータグループを使用している場合は、対応する、または 8.0 互換のパラメータグループを作成してください。また、アップグレード処理中に必ずそれらを指定してください。
**注記**
ほとんどのパラメータ設定では、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 へのインプレースアップグレードを実行できません。使用できる方法の詳細については、「[メジャーバージョンのアップグレード](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major)」を参照してください。
**重要**
アップグレードプロセス中にカスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動してください。再起動すると、クラスターがカスタムパラメータ設定の使用をスタートできます。
## Aurora MySQL バージョン間のクラスターのプロパティの変更
Aurora MySQL バージョン 2 からバージョン 3 にアップグレードする場合は、Aurora MySQL クラスターと DB インスタンスのセットアップと管理に使用するアプリケーションやスクリプトを確認してください。
また、5.7 および 8.0 互換クラスターではデフォルトのパラメータグループ名が異なることを考慮して、パラメータグループを操作するコードを変更します。Aurora MySQL バージョン 2 と 3 のクラスターのデフォルトのパラメータグループ名は、それぞれ `default.aurora-mysql5.7` と `default.aurora-mysql8.0` です。
例えば、アップグレード前にクラスターに適用される次のようなコードがあるとします。
```
# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1
```
クラスターのメジャーバージョンをアップグレードした後、そのコードを次のように変更します。
```
# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1
```
## グローバルデータベースのインプレースメジャーアップグレード
Aurora Global Database の場合は、グローバルデータベースクラスターをアップグレードします。Aurora は、すべてのクラスターを同時かつ自動的にアップグレードし、すべてのクラスターで、同じエンジンバージョンが実行されることを保証します。これは、システムテーブルやデータファイル形式などの変更が、すべてのセカンダリクラスターに自動的にレプリケートされるためです。
「[メジャーバージョンの Aurora MySQL インプレースアップグレードの仕組み](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence)」の手順に従います。アップグレードする対象を指定するときは、そのデータベースに含まれるクラスターの 1 つではなく、グローバルデータベースクラスターを選択してください。
AWS マネジメントコンソール を使用する場合、**[Global database]** (グローバルデータベース) のロールを持つアイテムを選択します。
![\[グローバルデータベースクラスターをアップグレードする\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
AWS CLI または RDS API を使用する場合は、[modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) コマンドまたは [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html) オペレーションを呼び出して、アップグレードプロセスをスタートします。`modify-db-cluster` または `ModifyDBCluster` の代わりにこれらのいずれかを使用します。
**注記**
Aurora グローバルデータベースのメジャーバージョンアップグレードを実行している間、グローバルデータベースクラスターのカスタムパラメータグループを指定することはできません。グローバルクラスターの各リージョンにカスタムパラメータグループを作成します。次に、アップグレード後に手動でリージョンクラスターに適用します。
AWS CLI を使用して Aurora MySQL グローバルデータベースクラスターのメジャーバージョンをアップグレードするには、以下の必須パラメータを指定して、[modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) コマンドを使用します。
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
次の例では、グローバルデータベースクラスターを Aurora MySQL バージョン 2.10.2 にアップグレードします。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine aurora-mysql \
--engine-version 5.7.mysql_aurora.2.10.2 \
--allow-major-version-upgrade
```
Windows の場合:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine aurora-mysql ^
--engine-version 5.7.mysql_aurora.2.10.2 ^
--allow-major-version-upgrade
```
## バックトラックに関する考慮事項
アップグレードしたクラスターでバックトラック機能が有効になっている場合、アップグレードしたクラスターをアップグレード前の時間にバックトラックすることはできません。
# Aurora MySQL インプレースアップグレードのチュートリアル
次の Linux の例では、AWS CLI を使用してインプレースアップグレードの一般的なステップを実行する方法を示します。
この最初の例では、2.x バージョンの Aurora MySQL を実行する Aurora DB クラスターを作成します。クラスターには、ライター DB インスタンスとリーダー DB インスタンスが含まれます。`wait db-instance-available` コマンドは、ライター DB インスタンスが利用可能になるまで一時停止します。クラスターをアップグレードする準備ができた時点です。
```
aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
--db-cluster-version 5.7.mysql_aurora.2.11.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
--db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
クラスターをアップグレードできる Aurora MySQL 3.x バージョンは、クラスターが現在実行している 2.x バージョンと、クラスターがある AWS リージョン によって異なります。`--output text` による初期のコマンドは、使用可能なターゲットバージョンだけを表示させます。2 番目のコマンドは、レスポンスの完全な JSON 出力を表示します。その応答では、`engine` パラメータに使用した `aurora-mysql` 値などの詳細を確認できます。また、3.04.0 へのアップグレードがメジャーバージョンアップグレードであることがわかります。
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.2 \
--query '*[].[ValidUpgradeTarget]'
...
{
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.04.0",
"Description": "Aurora MySQL 3.04.0 (compatible with MySQL 8.0.28)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": true,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsIntegrations": false
},
...
```
この例では、クラスターの有効なアップグレードターゲットではないターゲットバージョン番号が入力された場合に、Aurora がアップグレードを実行しないようにする方法を示しています。Aurora は、`--allow-major-version-upgrade` パラメータを指定しない限り、メジャーバージョンのアップグレードを実行しません。これにより、アプリケーションコードの大規模なテストや変更を必要とする可能性のあるアップグレードを誤って実行することはありません。
```
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.11.2 with requested version 5.7.mysql_aurora.2.09.2.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --apply-immediately --allow-major-version-upgrade
{
"DBClusterIdentifier": "mynewdbcluster",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2"
}
```
クラスターおよび関連付けられた DB インスタンスのステータスが `upgrading` に変わるまで、しばらく時間がかかります。クラスターおよび DB インスタンスのバージョン番号は、アップグレードが完了したときにのみ変更されます。この場合も、ライター DB インスタンスの `wait db-instance-available` コマンドを使用して、アップグレードが完了するまで待機してから続行します。
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.11.2
aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
--query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
"DBInstanceIdentifier": "mynewdbcluster-instance1",
"DBInstanceStatus": "upgrading"
}
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
この時点で、クラスターのバージョン番号が、アップグレード用に指定されたバージョン番号と一致します。
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
前の例では、`--apply-immediately` パラメータを指定して即時のアップグレードを実行しました。クラスターがビジー状態ではないと予想される都合の良いときにアップグレードを実行するために、`--no-apply-immediately` パラメータを指定できます。これにより、クラスターの次のメンテナンスウィンドウの表示中にアップグレードがスタートされます。メンテナンスウィンドウでは、メンテナンスオペレーションをスタートできる期間を定義します。長時間実行されるオペレーションは、メンテナンスウィンドウの中で終了しない場合があります。したがって、アップグレードに長時間かかることが予想される場合でも、より大きなメンテナンスウィンドウを定義する必要はありません。
次の例では、初期に Aurora MySQL バージョン 2.11.2 を実行しているクラスターをアップグレードします。`describe-db-engine-versions` 出力では、`False` および `True` 値は `IsMajorVersionUpgrade` プロパティを表します。バージョン 2.11.2 から、他の 2.\$1 バージョンにアップグレードできます。これらのアップグレードはメジャーバージョンアップグレードとはみなされないため、一括アップグレードは必要ありません。インプレースアップグレードは、リストに示されている 3.\$1 バージョンへのアップグレードでのみ利用できます。
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
--query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.7.mysql_aurora.2.11.3 False
5.7.mysql_aurora.2.11.4 False
5.7.mysql_aurora.2.11.5 False
5.7.mysql_aurora.2.11.6 False
5.7.mysql_aurora.2.12.0 False
5.7.mysql_aurora.2.12.1 False
5.7.mysql_aurora.2.12.2 False
5.7.mysql_aurora.2.12.3 False
8.0.mysql_aurora.3.04.0 True
8.0.mysql_aurora.3.04.1 True
8.0.mysql_aurora.3.04.2 True
8.0.mysql_aurora.3.04.3 True
8.0.mysql_aurora.3.05.2 True
8.0.mysql_aurora.3.06.0 True
8.0.mysql_aurora.3.06.1 True
8.0.mysql_aurora.3.07.1 True
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --no-apply-immediately --allow-major-version-upgrade
...
```
指定されたメンテナンスウィンドウを使用せずにクラスターを作成する場合、Aurora はランダムな曜日を選択します。この場合、`modify-db-cluster` コマンドは月曜日に送信されます。したがって、メンテナンスウィンドウを火曜日の朝に変更します。すべての時刻は UTC タイムゾーンで表されます。`tue:10:00-tue:10:30` 期間は、太平洋標準時の午前 2 時から 2 時 30 分に相当します。メンテナンスウィンドウの変更はすぐに有効になります。
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"sat:08:20-sat:08:50"
]
]
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"tue:10:00-tue:10:30"
]
]
```
次に、アップグレードによって生成されたイベントのレポートを取得する例を示します。`--duration` 引数は、イベント情報を取得する時間 (分) を表します。デフォルトでは、`describe-events` は過去 1 時間のイベントのみを返すため、この引数が必要です。
```
aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
"Events": [
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "DB cluster created",
"EventCategories": [
"creation"
],
"Date": "2022-11-17T01:24:11.093000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing online pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:08.450000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:59.519000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:00:22.318000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Cloning volume.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:01:45.428000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:02:25.141000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:23.036000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Upgrading database objects.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:48.208000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster major version has been upgraded",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:10:28.999000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
}
]
}
```
# Aurora MySQL メジャーバージョンアップグレードが失敗する理由を確認する
[チュートリアル](AuroraMySQL.Upgrading.Tutorial.md)では、Aurora MySQL バージョン 2 からバージョン 3 へのアップグレードに成功しました。ただし、アップグレードが失敗した場合は、必要に応じて、その理由を確認できます。
まず、`describe-events` AWS CLI コマンドを使用して DB クラスターのイベントを表示できます。この例は、過去 10 時間の `mydbcluster` のイベントを示しています。
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
この例では、アップグレードの事前チェックが失敗しています。
```
{
"Events": [
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster engine version upgrade started.",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:22.846000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
},
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the
upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:24.373000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
}
]
}
```
問題の正確な原因を診断するには、ライター DB インスタンスのデータベースログを調べます。Aurora MySQL バージョン 3 へのアップグレードが失敗すると、ライターインスタンスに `upgrade-prechecks.log` という名前のログファイルが追加されます。この例では、そのログの存在を検出し、それを調査のためにローカルファイルにダウンロードする方法を示します。
```
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
--query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log
aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
--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 のアップグレードでは、このログには常に、特定の情報と警告メッセージが含まれます。エラーメッセージは、アップグレードが失敗した場合にのみ含まれます。アップグレードが成功すると、ログファイルはまったく生成されません。
すべてのエラーを集約して関連するオブジェクトや説明のフィールドを表示するには、`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."
```
この例では、問題のあるテーブルに対して次の SQL コマンドを実行して問題の解決を試みるか、ダングリングインデックスなしでテーブルを再作成することができます。
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
次に、アップグレードを再試行します。
# Aurora MySQL インプレースアップグレードのトラブルシューティング
以下のヒントを使用して、Aurora MySQL インプレースアップグレードに関する問題のトラブルシューティングを行います。これらのヒントは、Aurora Serverless DB クラスターには適用されません。
| インプレースアップグレードがキャンセルされた、または遅い理由 | 効果 | メンテナンス期間内にインプレースアップグレードを完了するためのソリューション |
| --- | --- | --- |
| 関連する Aurora クロスリージョンレプリカに対するパッチが未適用 | Aurora はアップグレードをキャンセルします。 | Aurora クロスリージョンレプリカをアップグレードして、もう一度試します。 |
| クラスターに準備済み状態の XA トランザクションがある | Aurora はアップグレードをキャンセルします。 | 準備済みのすべての XA トランザクションをコミットまたはロールバックします。 |
| クラスターはデータ定義言語 (DDL) ステートメントを処理しています | Aurora はアップグレードをキャンセルします。 | すべての DDL ステートメントが終了したら、アップグレードを待って実行することをお勧めします。 |
| クラスターの多くの行で、コミットされていない変更があります | アップグレードには長時間かかる場合があります。 | アップグレードプロセスは、コミットされていない変更をロールバックします。この条件のインジケータは、`TRX_ROWS_MODIFIED` テーブル内の `INFORMATION_SCHEMA.INNODB_TRX` の値です。 すべての大きなトランザクションがコミットまたはロールバックされた後にのみ、アップグレードを実行することをお勧めします。 |
| クラスターには多数の UNDO レコードがあります | アップグレードには長時間かかる場合があります。 | コミットされていないトランザクションが多数の行に影響を与えない場合でも、大量のデータが含まれる可能性があります。例えば、大きな BLOB を挿入する場合などです。Aurora は、この種のトランザクションアクティビティのイベントを自動的に検出または生成しません。この条件のインジケータは、履歴リスト (HLL) の長さです。アップグレードプロセスは、コミットされていない変更をロールバックします。 HLL は、`SHOW ENGINE INNODB STATUS` SQL コマンドからの出力で確認することも、次の SQL クエリを使用して直接確認することもできます。 SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
また、Amazon CloudWatch で `RollbackSegmentHistoryListLength` メトリクスをモニタリングすることもできます。 HLL の長さが短くなった後にのみ、アップグレードを実行することをお勧めします。 |
| クラスターは、大きなバイナリログトランザクションをコミット中です | アップグレードには長時間かかる場合があります。 | アップグレードプロセスは、バイナリログの変更が適用されるまで待ちます。この期間中にさらに多くのトランザクションまたは DDL ステートメントがスタートされる可能性があり、アップグレードプロセスの速度はさらに低下します。 クラスターがバイナリログレプリケーションの変更を生成するためのビジー状態でない場合に、アップグレードプロセスがスケジュールされます。Aurora は、この条件のイベントを自動的に検出または生成しません。 |
| ファイルの削除または破損によるスキーマの不一致 | Aurora はアップグレードをキャンセルします。 | 一時テーブルのデフォルトのストレージエンジンを MyISAM から InnoDB に変更します。以下のステップを実行します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| マスターユーザーが削除されました | Aurora はアップグレードをキャンセルします。 | マスターユーザーを削除しないでください。 ただし、何らかの理由でマスターユーザーを削除する必要がある場合は、次の SQL コマンドを使用して復元します。 CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT,
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;
|
アップグレードの事前チェックの失敗を起こす問題のトラブルシューティングの詳細については、以下のブログを参照してください。
+ [Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードチェックリスト、パート 1](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/)
+ [Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードチェックリスト、パート 2](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
以下のステップを使用して、上記の表の一部の条件に対して独自のチェックを実行できます。これにより、データベースがアップグレードを正常かつ迅速に完了できる状態にあることが分かっているときに、アップグレードをスケジュールすることができます。
+ `XA RECOVER` ステートメントを実行することで、開いている XA トランザクションを確認できます。アップグレードのスタート前に、XA トランザクションをコミットまたはロールバックできます。
+ `SHOW PROCESSLIST` ステートメントを実行し、出力で`CREATE`、`DROP`、`ALTER`、`RENAME`、および `TRUNCATE` ステートメントを探して、DDL ステートメントを確認できます。アップグレードのスタート前に、すべての DDL ステートメントを完了させます。
+ `INFORMATION_SCHEMA.INNODB_TRX` テーブルをクエリすることで、コミットされていない行の総数を確認できます。テーブルには、トランザクションごとに 1 つの行が含まれます。`TRX_ROWS_MODIFIED` 列には、トランザクションによって変更または挿入された行の数が含まれます。
+ InnoDB 履歴リストの長さを確認するには、`SHOW ENGINE INNODB STATUS SQL` ステートメントを実行し、出力で `History list length` を探します。次のクエリを実行して、値を直接確認することもできます。
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
履歴リストの長さは、マルチバージョン同時実行制御 (MVCC) の実装のためにデータベースに保存される UNDO 情報の量に対応します。
# Aurora MySQL バージョン 3 のアップグレード後のクリーンアップ
Aurora MySQL バージョン 2 クラスターを Aurora MySQL バージョン 3 にアップグレードした後、次のようなその他のクリーンアップアクションを実行できます。
+ カスタム パラメータグループの新しい MySQL 8.0 互換バージョンを作成します。必要なカスタムパラメータ値を新しいパラメータグループに適用します。
+ CloudWatch アラーム、セットアップスクリプトなどを更新して、インクルーシブな言語変更の影響を受けた名前のメトリクスに、新しい名前を使用します。このようなメトリクスの一覧は、[Aurora MySQL バージョン 3 に対する包括的な言語変更](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language) をご覧ください。
+ CloudFormation テンプレートをすべて更新して、包括的な言語の変更によって影響を受けるすべてのコンフィギュレーション パラメータの名前を新しくします。そのようなパラメータのリストについては、[Aurora MySQL バージョン 3 に対する包括的な言語変更](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language) を参照してください。
## 空間インデックス
Aurora MySQL バージョン 3 にアップグレードした後、空間インデックスに関連するオブジェクトおよびインデックスを削除または再作成する必要があるかどうかをチェックします。MySQL 8.0 より前では、Aurora は空間リソース識別子 (SRID) を含まないインデックスを使用して空間クエリを最適化できました。Aurora MySQL バージョン 3 では、SRID を含む空間インデックスのみを使用します。アップグレード中、Aurora は SRID のない空間インデックスを自動的にドロップし、警告メッセージをデータベースログに出力します。このような警告メッセージが表示された場合は、アップグレード後に SRID を使用して新しい空間インデックスを作成します。MySQL 8.0 での空間関数とデータ型の変更の詳細については、[MySQL リファレンスマニュアル](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html)の「*MySQL 8.0 での変更*」を参照してください。
# Amazon Aurora MySQL に関するデータベースエンジンの更新と修正
「*Amazon Aurora MySQL 互換エディションのリリースノート*」では、以下の情報を参照できます。
+ [Amazon Aurora MySQL バージョン 3 のデータベースエンジンの更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)
+ [Amazon Aurora MySQL バージョン 2 のデータベースエンジンの更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.20Updates.html)
+ [Amazon Aurora MySQL バージョン 1 のデータベースエンジンの更新 (非推奨)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.11Updates.html)
+ [Aurora MySQL データベースエンジンの更新で修正された MySQL のバグ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.MySQLBugs.html)
+ [Amazon Aurora MySQL で修正されたセキュリティの脆弱性](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.CVE_list.html)