# 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 情報の量に対応します。