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

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

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

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

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

Aurora MySQL クラスターのマイナーバージョンをアップグレードすると、既存のクラスターに追加の修正と新しい機能が適用されます。

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

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

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

注記

Aurora MySQL バージョン 3.03* 以上またはバージョン 2.12.* へのマイナーバージョンアップグレードを実行するには、次のプロセスを使用します。

  1. グローバルクラスターからすべてのセカンダリリージョンを削除します。「Amazon Aurora Global Database からのクラスターの削除」の手順を実行します。

  2. 必要に応じて、プライマリリージョンのエンジンバージョンをバージョン 3.03.* 以上、またはバージョン 2.12.* にアップグレードします。「To modify the engine version of a DB cluster」の手順を実行します。

  3. グローバルクラスターにセカンダリリージョンを追加します。「AWS リージョン の Amazon 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.11.1 にアップグレードするには、--engine-version オプションを 5.7.mysql_aurora.2.11.1 に設定します。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 クラスターのマイナーバージョン自動アップグレードプロパティを使います。

自動アップグレードはメンテナンスウィンドウ中に実行されます。DB クラスター内の個々の DB インスタンスのメンテナンスウィンドウがクラスターメンテナンスウィンドウと異なる場合は、クラスターメンテナンスウィンドウが優先されます。

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

  • Aurora グローバルデータベースの一部であるクラスター

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

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

注記

Aurora は、DB クラスター内のすべての DB インスタンスでこの設定が有効になっている場合にのみ、自動アップグレードを実行します。[マイナーバージョン自動アップグレード] の設定方法、およびクラスターレベルとインスタンスレベルで適用した場合にどのように機能するかについては、 Aurora DB クラスターのマイナーバージョン自動アップグレード を参照してください。

マイナーバージョンの自動アップグレードは、デフォルトのマイナーバージョンについて実行されます。

次のような CLI コマンドを使用すると、Aurora MySQL クラスター内のすべての DB インスタンスで AutoMinorVersionUpgrade 設定のステータスを確認できます。

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 ...

この例では、DB クラスター cluster-57-2020-06-03-6411 の [マイナーバージョン自動アップグレードの有効化] がオフになっています。これは、クラスター内の DB インスタンスの 1 つでオフになっているためです。

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

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

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

ZDP は以下には適用されません。

  • オペレーティングシステム (OS) のパッチとアップグレード

  • メジャーバージョンのアップグレード

  • 2.11.0 より前のバージョンからバージョン 2.11.0 以降へのアップグレード、および 3.03.0 未満のバージョンからバージョン 3.03.0 以降へのアップグレード

    これらのアップグレードには、基盤となる Amazon EC2 インスタンスのオペレーティングシステムのパッチ適用またはアップグレードのため、ホストを交換する必要があります。

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

Version db.r* インスタンスクラス db.t* インスタンスクラス db.x* インスタンスクラス db.serverless インスタンスクラス
2.07.2 以降の 2.07 バージョン いいえ はい いいえ 該当なし
2.10.0 以降の 2.10 バージョン いいえ いいえ いいえ 該当なし
2.11.0 以降の 2.11 バージョン はい はい はい 該当なし
2.12.0 以降の 2.12 バージョン はい はい はい 該当なし
3.01.0 および 3.01.1 はい はい はい 該当なし
3.02.0 以降の 3.02 バージョン はい はい はい はい
3.03.0 以降の 3.03 バージョン はい はい はい はい
3.04.0 以降の 3.04 バージョン はい はい はい はい
注記

T DB インスタンスクラスは、開発サーバーおよびテストサーバー、またはその他の本稼働以外のサーバーにのみ使用することをお勧めします。T インスタンスクラスの詳細については、「開発やテストのための T インスタンスクラスの使用」を参照してください。

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] (イベント) ページで報告されます。

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

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

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

状況によっては、古いクラスターからアップグレードされたクラスターへの即時の切り替えが最優先事項です。このような場合、古いクラスターと新しいクラスターを並べて実行するマルチステッププロセスを使用できます。ここでは、新しいクラスターが引き継ぐ準備ができるまで、古いクラスターから新しいクラスターにデータをレプリケートします。詳細については、「データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する」を参照してください。