Aurora MySQL インプレースアップグレードのトラブルシューティング
以下のヒントを使用して、Aurora MySQL インプレースアップグレードに関する問題のトラブルシューティングを行います。これらのヒントは、Aurora Serverless DB クラスターには適用されません。
インプレースアップグレードがキャンセルされた、または遅い理由 | 効果 | メンテナンス期間内にインプレースアップグレードを完了するためのソリューション |
---|---|---|
関連する Aurora クロスリージョンレプリカに対するパッチが未適用 | Aurora はアップグレードをキャンセルします。 | Aurora クロスリージョンレプリカをアップグレードして、もう一度試します。 |
クラスターに準備済み状態の XA トランザクションがある | Aurora はアップグレードをキャンセルします。 | 準備済みのすべての XA トランザクションをコミットまたはロールバックします。 |
クラスターはデータ定義言語 (DDL) ステートメントを処理しています | Aurora はアップグレードをキャンセルします。 | すべての DDL ステートメントが終了したら、アップグレードを待って実行することをお勧めします。 |
クラスターの多くの行で、コミットされていない変更があります | アップグレードには長時間かかる場合があります。 |
アップグレードプロセスは、コミットされていない変更をロールバックします。この条件のインジケータは、 すべての大きなトランザクションがコミットまたはロールバックされた後にのみ、アップグレードを実行することをお勧めします。 |
クラスターには多数の UNDO レコードがあります | アップグレードには長時間かかる場合があります。 |
コミットされていないトランザクションが多数の行に影響を与えない場合でも、大量のデータが含まれる可能性があります。例えば、大きな BLOB を挿入する場合などです。Aurora は、この種のトランザクションアクティビティのイベントを自動的に検出または生成しません。この条件のインジケータは、履歴リスト (HLL) の長さです。アップグレードプロセスは、コミットされていない変更をロールバックします。 HLL は、
また、Amazon CloudWatch で HLL の長さが短くなった後にのみ、アップグレードを実行することをお勧めします。 |
クラスターは、大きなバイナリログトランザクションをコミット中です | アップグレードには長時間かかる場合があります。 |
アップグレードプロセスは、バイナリログの変更が適用されるまで待ちます。この期間中にさらに多くのトランザクションまたは DDL ステートメントがスタートされる可能性があり、アップグレードプロセスの速度はさらに低下します。 クラスターがバイナリログレプリケーションの変更を生成するためのビジー状態でない場合に、アップグレードプロセスがスケジュールされます。Aurora は、この条件のイベントを自動的に検出または生成しません。 |
ファイルの削除または破損によるスキーマの不一致 | Aurora はアップグレードをキャンセルします。 |
一時テーブルのデフォルトのストレージエンジンを MyISAM から InnoDB に変更します。以下のステップを実行します。
|
マスターユーザーが削除されました | Aurora はアップグレードをキャンセルします。 |
重要マスターユーザーを削除しないでください。 ただし、何らかの理由でマスターユーザーを削除する必要がある場合は、次の SQL コマンドを使用して復元します。
|
アップグレードの事前チェックの失敗を起こす問題のトラブルシューティングの詳細については、以下のブログを参照してください。
以下のステップを使用して、上記の表の一部の条件に対して独自のチェックを実行できます。これにより、データベースがアップグレードを正常かつ迅速に完了できる状態にあることが分かっているときに、アップグレードをスケジュールすることができます。
-
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 情報の量に対応します。