Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード - Amazon Aurora
エンジンバージョンの変更マイナーバージョン間の自動アップグレードの有効化Aurora MySQL DB クラスターへの保留中のメンテナンスの適用ダウンタイムのないパッチ適用の使用代替の Blue/Green のアップグレードテクニック

Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード

DB クラスターのマイナーバージョンをアップグレードしたり、DB クラスターにパッチを適用したりするには、次の方法を使用できます。

ダウンタイムなしのパッチ適用によってアップグレードプロセス中の中断を減らす方法については、「ダウンタイムのないパッチ適用の使用」を参照してください。

エンジンのバージョンを変更して Aurora MySQL アップグレードする

Aurora MySQL クラスターのマイナーバージョンをアップグレードすると、既存のクラスターに追加の修正と新しい機能が適用されます。この種のアップグレードは、Amazon Aurora MySQL バージョン 1.19.0 以降または 2.03.2 以降を実行しているクラスターに対して実行できます。

この種のアップグレードは、元のバージョンとアップグレードされたバージョンの両方が Aurora MySQL 1.x シリーズであるか、両方が Aurora MySQL 2.x シリーズである Aurora MySQL クラスターに適用されます。このプロセスは、Aurora MySQL メタデータの変換やテーブルデータの再編成を必要としないため、迅速で単純明快です。

この種のアップグレードを実行するには、AWS Management Console、AWS CLI、RDS API のいずれかを使用して DB クラスターのエンジンバージョンを変更します。クラスターで Aurora MySQL 1.x が実行されている場合は、より高い 1.x バージョンを選択します。クラスターで Aurora MySQL 2.x が実行されている場合は、より高い 2.x バージョンを選択します。

注記

Aurora Global Database でマイナーアップグレードを実行する場合は、プライマリクラスターをアップグレードする前に、すべてのセカンダリクラスターをアップグレードします。

DB クラスターのエンジンバージョンを変更するには

  • コンソールを使用する場合 -クラスターのプロパティを変更します。[DB クラスターの変更] ウィンドウの [DB エンジンバージョン] ボックスで、Aurora MySQL エンジンバージョンを変更します。クラスターを変更するための一般的な手順に慣れていない場合は、「コンソール、CLI、API を使用した DB クラスターの変更」の手順に従ってください。

  • AWS CLI を使用する場合 - AWS CLI コマンドの modify-db-cluster を呼び出し、DB クラスターの名前を --db-cluster-identifier オプションで指定しながら、エンジンバージョンを --engine-version オプションで指定します。

    例えば、Aurora MySQL バージョン 2.03.2 にアップグレードするには、--engine-version オプションを 5.7.mysql_aurora.2.03.2 に設定します。DB クラスターのエンジンバージョンをすぐに更新するには、--apply-immediately オプションを指定します。

  • RDS API を使用する場合 - ModifyDBCluster API オペレーションを呼び出し、DBClusterIdentifier で DB クラスターの名前を指定して EngineVersion パラメータでエンジンバージョンを指定します。DB クラスターのエンジンバージョンをすぐに更新するには、ApplyImmediately パラメータを true に設定します。

Aurora MySQL マイナーバージョン間の自動アップグレードの有効化

Amazon Aurora MySQL DB クラスターの場合、Aurora で DB クラスターを自動的に新しいマイナーバージョンにアップグレードするように指定できます。これを行うには、AWS Management Console、AWS CLI、RDS API のいずれかを使用して DB クラスターのマイナーバージョン自動アップグレードプロパティを使います。

自動アップグレードは、データベースのメンテナンス期間中に実行されます。

マイナーバージョンの自動アップグレードは、次の種類の Aurora MySQL クラスターには適用されません。

  • マルチマスタークラスター。

  • Aurora Global Database の一部であるクラスター。

  • クロスリージョンレプリカを持つクラスター。

停止時間は、ワークロード、クラスターサイズ、バイナリログデータの量、および Aurora がゼロダウンタイムパッチ適用 (ZDP) 機能を使用できるかどうかによって異なります。Aurora はデータベースクラスターを再起動するため、クラスターの使用を再開する前に、可用性が短時間失われることがあります。特に、バイナリログデータの量が復旧時間に影響を与えます。DB インスタンスは、復旧中にバイナリログデータを処理します。したがって、バイナリログデータが大量である場合、復旧時間が長くなります。

Aurora MySQL DB クラスターのマイナーバージョン自動アップグレードを有効にするには

  1. 「DB クラスター内の DB インスタンスの変更」で説明しているように、一般的な手順に従ってクラスター内の DB インスタンスを変更します。クラスター内の DB インスタンスごとに、この手順を繰り返します。

  2. クラスターのマイナーバージョン自動アップグレードを有効化するには、以下の手順を実行します。

  • コンソールを使用する場合 - 以下のステップを実行します。

    1. Amazon RDS コンソールにサインインして [データベース] を選択し、マイナーバージョン自動アップグレードを有効化または無効化する DB クラスターを探します。

    2. 変更する DB クラスター内の各 DB インスタンスを選択します。各 DB インスタンスに順番に次の変更を適用します。

      1. 変更を選択します。

      2. [マイナーバージョン自動アップグレードの有効化] 設定を選択します。この設定は、[メンテナンス] セクションの一部です。

      3. [続行] を選択して、変更の概要を確認します。

      4. (省略可能) 変更をすぐに適用するには、[すぐに適用] を選択します。

      5. 確認ページで、[DB インスタンスの変更] を選択します。

  • AWS CLI を使用する場合 - AWS CLI コマンドの modify-db-instance を呼び出します。--db-instance-identifier オプションで DB インスタンスの名前を指定し、true オプションで --auto-minor-version-upgrade を指定します。必要に応じて、この設定を DB インスタンスですぐに有効にするための --apply-immediately オプションを指定します。クラスター内の DB インスタンスごとに modify-db-instance コマンドを別個に実行します。

  • RDS API を使用する場合 - ModifyDBInstance API オペレーションを呼び出して、DBInstanceIdentifier パラメータで DB クラスターの名前を指定し、true パラメータで AutoMinorVersionUpgrade を指定します。必要に応じて、ApplyImmediately パラメータを true に設定し、この設定を DB インスタンスですぐに有効にします。クラスター内の各 DB インスタンスで ModifyDBInstance オペレーションを個別に呼び出します。

次のような CLI コマンドを使用すると、Aurora MySQL クラスター内のすべての DB インスタンスで [マイナーバージョン自動アップグレードの有効化] のステータスを確認できます。

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

このコマンドでは、次のような出力が生成されます。

[
  {
      "DBInstanceIdentifier": "db-t2-medium-instance",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": true
  },
  {
      "DBInstanceIdentifier": "db-t2-small-original-size",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": false
  },
  {
      "DBInstanceIdentifier": "instance-2020-05-01-2332",
      "DBClusterIdentifier": "cluster-57-2020-05-01-4615",
      "AutoMinorVersionUpgrade": true
  },
... output omitted ...

Aurora MySQL DB クラスターに保留中のメンテナンスを適用して Aurora MySQL をアップグレードする

Aurora MySQL バージョン 1.x のバージョンにアップグレードする場合、新しいデータベースエンジンのマイナーバージョンとパッチは、DB クラスターの使用可能なメンテナンスアップグレードとして表示されます。使用可能なメンテナンスアクションを適用することで、DB クラスターのデータベースバージョンをアップグレードまたは修正できます。新しいバージョンの変更がインスタンスやアプリケーションに及ぼす影響を確認するために、初期に本番稼働用以外の DB クラスターに更新を適用することをお勧めします。

保留中のメンテナンスアクションを適用するには

  • コンソールを使用する場合 - 以下のステップを実行します。

    1. Amazon RDS コンソールにサインインして [Databases (データベース)] をクリックし、利用可能なメンテナンスのアップグレードを示す DB クラスターを選択します。

    2. [アクション] で、[今すぐアップグレード] を選択して DB クラスターのデータベースバージョンをすぐに更新するか、[次のウィンドウでアップグレード] を選択して DB クラスターの次のメンテナンスウィンドウ中にデータベースバージョンを更新します。

  • AWS CLI を使用する場合 - AWS CLI コマンドの apply-pending-maintenance-action を呼び出して、--resource-id オプションで DB クラスターの Amazon リソースネーム (ARN) を指定し、--apply-action オプションで system-update を指定します。--opt-in-type オプションを immediate に設定して DB インスタンスのデータベースバージョンをすぐに更新するか、next-maintenance に設定して DB クラスターの次のメンテナンスウィンドウ中にデータベースバージョンを更新します。

  • RDS API を使用する場合 - ApplyPendingMaintenanceAction API オペレーションを呼び出して、ResourceId パラメータに DB クラスターの ARN を指定し、system-update パラメータに ApplyAction を指定します。OptInType パラメータを immediate に設定して DB クラスターのデータベースバージョンをすぐに更新するか、next-maintenance に設定して クラスターの次のメンテナンスウィンドウ中にインスタンスのデータベースバージョンを更新します。

Amazon RDS がデータベースとオペレーティングシステムの更新を管理する方法の詳細については、「Amazon Aurora DB クラスターのメンテナンス」を参照してください。

注記

現在お使いの Aurora MySQL バージョンが 1.14.x で、1.14.4 より前のバージョンの場合は、1.14.4 (db.r4 インスタンスクラスをサポート) にのみアップグレードできます。また、Aurora MySQL を 1.14.x からより高いマイナーバージョン (例: 1.17) にアップグレードするには、1.14.x バージョンが 1.14.4 であることが必要です。

ダウンタイムのないパッチ適用の使用

Aurora MySQL DB クラスターのアップグレードを実行する場合、データベースがシャットダウンされたときおよびアップグレード中に停止する可能性があります。デフォルトでは、データベースがビジー状態のときにアップグレードをスタートすると、DB クラスターが処理しているすべての接続とトランザクションが失われます。アップグレードを実行するためにデータベースがアイドル状態になるまで待機する場合は、長時間待機しなければならない場合があります。

ダウンタイムのないパッチ適用 (ZDP) 機能では、ベストエフォートに基づいて、Aurora MySQL アップグレード中のクライアント接続を維持するよう試みます。ZDP が正常に完了されると、アプリケーションのセッションが保持され、アップグレードの進行中にデータベースエンジンが再起動します。データベースエンジンの再起動により、数秒から約 1 分間スループットが低下する可能性があります。

次の表は、ZDP が使用可能な Aurora MySQL バージョンと DB インスタンスクラスを示しています。

バージョン db.r* インスタンスクラス db.t* インスタンスクラス db.serverless インスタンスクラス
2.07.2 以降の 2.07 バージョン いいえ はい 該当なし
2.10.0 以降の 2.10 バージョン はい はい 該当なし
3.01.0 および 3.01.1 はい はい 該当なし
3.02.0 以降の 3.x バージョン はい はい はい

MySQL エラーログで ZDP 中に重要な属性のメトリクスを確認できます。AWS Management Console の [イベント] ページでは、Aurora MySQL で ZDP を使用する場合や、ZDP の使用を選択しない場合に関する情報も確認できます。

Aurora MySQL 2.10 以降およびバージョン 3 でバイナリログレプリケーションが有効になっている場合、Aurora はダウンタイムゼロでパッチを実行できます。Aurora MySQL は、ZDP オペレーション中にバイナリログターゲットへの接続を自動的に切断します。Aurora MySQL は自動的にバイナリログターゲットに再接続し、再起動の完了後にレプリケーションを再開します。

また、ZDP は、Aurora MySQL 2.10 以降の再起動の機能拡張と組み合わせて機能させることもできます。ライター DB インスタンスにパッチを適用すると、同時にリーダーにパッチが自動適用されます。パッチの実行後、Aurora は、ライター DB インスタンスとリーダー DB インスタンスの両方で接続を復元します。Aurora MySQL 2.10 より前のバージョンでは、ZDP はクラスターのライター DB インスタンスにのみ適用されます。

ZDP は、以下の状態では正常に完了されない場合があります。

  • 長期実行クエリまたはトランザクションが進行中である。この場合、Aurora が ZDP を実行すると、未処理のトランザクションはすべてキャンセルされます。

  • Open Secure Socket Layer (SSL) 接続が存在します。

  • データ定義言語 (DDL) ステートメントの実行中などは、一時テーブルまたはテーブルロックが使用中です。この場合、Aurora が ZDP を実行すると、未処理のトランザクションはすべてキャンセルされます。

  • パラメータの変更が保留中である。

上記の状態のいずれかにより、ZDP を実行するための適切な時間枠が確保されない場合、パッチ適用はスタンダードの動作に戻ります。

ZDP オペレーションが成功した後も接続はそのまま残りますが、一部の可変と機能は再初期化されます。次の種類の情報は、ダウンタイムのないパッチ適用によって生じる再起動を通じては保持されません。

  • グローバル可変 Aurora はセッション可変を復元しますが、再起動後のグローバル可変の復元は行いません。

  • ステータス可変。特に、エンジンステータスによって報告される稼働時間の値は、ZDR または ZDP メカニズムを使用する再起動後にリセットされます。

  • LAST_INSERT_ID.

  • テーブルのメモリ内 auto_increment 状態。メモリ内自動インクリメント状態が再初期化されます。自動インクリメント値の詳細については、MySQL リファレンスマニュアルを参照してください。

  • INFORMATION_SCHEMA および PERFORMANCE_SCHEMA テーブルからの診断情報。この診断情報は、SHOW PROFILE や SHOW PROFILES などのコマンドの出力にも表示されます。

ダウンタイムのない再起動に関連する次のアクティビティが [Events] (イベント) ページで報告されます。

  • ダウンタイムなしでのデータベースのアップグレードを試みています。

  • ダウンタイムなしでのデータベースのアップグレードを試みます。イベントは、プロセスにかかった時間を報告します。このイベントでは、再起動中に保持された接続の数とドロップされた接続の数も報告されます。データベースエラーログを参照して、再起動中に発生した処理の詳細を確認できます。

次の表は、特定の Aurora MySQL 1.x および 2.x バージョンから、または当該バージョンにアップグレードするための ZDP の仕組みをまとめたものです。DB インスタンスのインスタンスクラスは、Aurora が ZDP メカニズムを使用するかどうかにも影響します。

初版 アップグレード版 ZDP は適用されますか?

Aurora MySQL 1.*

すべて

いいえ

Aurora MySQL 2.*、2.07.2 より前

すべて

いいえ

Aurora MySQL 2.07.2、2.07.3

2.07.4 以降の 2.07 バージョン、2.10.*

はい、T2 および T3 インスタンスクラスのライターインスタンスでのみ可能です。Aurora は、タイムアウトが発生する前に静かなポイントが見つかった場合にのみ ZDP を実行します。タイムアウト後、Aurora は定期的な再起動を実行します。

Aurora MySQL 2.07.4 以降の 2.07 バージョン

2.10.*

はい。T2 および T3 インスタンスのライターインスタンスでのみ可能です。Aurora は、アクティブおよびアイドル状態のトランザクションをロールバックします。SSL、一時テーブル、テーブルロック、またはユーザーロックを使用する接続は切断されます。ZDP の完了後にエンジンの起動に時間がかかりすぎると、Aurora がエンジンを再起動し、すべての接続が切断されることがあります。

Aurora MySQL 2.10.*

 2.10.*

はい。db.t* および db.r* インスタンスのライターインスタンスで可能です。Aurora は、アクティブおよびアイドル状態のトランザクションをロールバックします。SSL、一時テーブル、テーブルロック、またはユーザーロックを使用する接続は切断されます。ZDP の完了後にエンジンの起動に時間がかかりすぎると、Aurora がエンジンを再起動し、すべての接続が切断されることがあります。

代替の Blue/Green のアップグレードテクニック

ブログ記事の「最小限のダウンタイムで Aurora MySQL のメジャーバージョンアップグレードを実行する」を参照してください。