Aurora MySQL インプレースアップグレードのトラブルシューティング - Amazon Aurora

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 に変更します。以下のステップを実行します。

  1. default_tmp_storage_engine DB パラメータを InnoDB に変更します。

  2. DB クラスターを再起動します。

  3. 再起動後、default_tmp_storage_engine DB パラメータが InnoDB に設定されていることを確認します。以下のコマンドを使用します。

    show global variables like 'default_tmp_storage_engine';
  4. MyISAM ストレージエンジンを使用する一時テーブルは作成しないでください。間もなくアップグレードを行う予定なので、データベースワークロードを一時停止し、新しいデータベース接続を作成しないことをお勧めします。

  5. インプレースアップグレードを再試行してください。

マスターユーザーが削除されました 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;

アップグレードの事前チェックの失敗を起こす問題のトラブルシューティングの詳細については、以下のブログを参照してください。

以下のステップを使用して、上記の表の一部の条件に対して独自のチェックを実行できます。これにより、データベースがアップグレードを正常かつ迅速に完了できる状態にあることが分かっているときに、アップグレードをスケジュールすることができます。

  • XA RECOVER ステートメントを実行することで、開いている XA トランザクションを確認できます。アップグレードのスタート前に、XA トランザクションをコミットまたはロールバックできます。

  • SHOW PROCESSLIST ステートメントを実行し、出力でCREATEDROPALTERRENAME、および 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 情報の量に対応します。