Amazon Aurora DB クラスターのメンテナンス

Amazon RDS では、Amazon RDS リソースのメンテナンスを定期的に実行します。

トピック

• DB クラスターのメンテナンス更新の概要
• 保留中のメンテナンス更新の表示
• DB クラスターのアップデートを適用する
• Amazon RDS メンテナンスウィンドウ
• DB クラスターの適切なメンテナンスウィンドウの調整
• Aurora DB クラスターのマイナーバージョン自動アップグレード
• Aurora MySQL メンテナンスのアップデート頻度を選択する
• Amazon Aurora でのオペレーティングシステムの更新

DB クラスターのメンテナンス更新の概要

メンテナンスでは、ほとんどの場合、DB クラスターの以下のリソースの更新が行われます。

• 基盤となるハードウェア

• 基盤となるオペレーティングシステム (OS)

• データベースエンジンのバージョン

通常、オペレーティングシステムのアップデートはセキュリティ問題に関連しています。できるだけ早く行うことをお勧めします。オペレーティングシステムのアップデートの詳細については、「DB クラスターのアップデートを適用する」を参照してください。

メンテナンス更新中のオフラインリソース

一部のメンテナンス項目では、Amazon RDS が DB クラスターを少しの間オフラインにする必要があります。リソースをオフラインにする必要があるメンテナンス項目には、必要なオペレーティングシステムやデータベースのパッチが含まれます。セキュリティやインスタンスの信頼性に関連するパッチのみ、必須のパッチ適用として自動的にスケジューリングされます。そのようなパッチ適用はまれであり、通常は数か月に一度です。メンテナンスウィンドウのごくわずかしか必要としないことがほとんどです。

遅延 DB インスタンスと DB クラスターの変更

すぐに適用しないことを選択した遅延 DB クラスターおよびインスタンスの変更は、メンテナンス期間中に適用されます。例えば、メンテナンス期間中に DB インスタンスクラス、クラスターまたは DB パラメータグループの変更を選択できます。保留中の再起動設定を使用して指定した変更は、[ 保留中のメンテナンス ] リストに表示されません。DB クラスターの変更については、「Amazon Aurora DB クラスターの変更」を参照してください。

次のメンテナンスウィンドウに向けて保留中の変更を確認するには、describe-db-clusters AWS CLI コマンドを使用して PendingModifiedValues フィールドを確認します。

DescribePendingMaintenanceActions API の結果整合性

Amazon RDS DescribePendingMaintenanceActions API は結果整合性モデルに従います。つまり、DescribePendingMaintenanceActions コマンドの結果が、それ以降のすべての RDS コマンドにすぐには表示されない場合があります。以前の API コマンドを使用した直後に DescribePendingMaintenanceActions を使用する場合は、この点に注意してください。

結果整合性は、メンテナンス更新の管理方法に影響を与える可能性があります。例えば、ApplyPendingMaintenanceActions コマンドを実行して DB クラスターのデータベースエンジンバージョンを更新すると、最終的に DescribePendingMaintenanceActions に表示されます。このシナリオでは、DescribePendingMaintenanceActions はメンテナンスアクションが適用済みであっても適用されていないと示す場合があります。

結果整合性を管理するには、以下を実行します。

• コマンドを実行して変更する前に、DB クラスターの状態を確認します。エクスポネンシャルバックオフアルゴリズムを使用して適切な DescribePendingMaintenanceActions コマンドを実行し、前のコマンドがシステム内を伝播するのに十分な時間を確保できるようにします。これを行うには、DescribePendingMaintenanceActions コマンドを繰り返し実行し、数秒の待機時間から始めて、最大 5 分間の待機時間まで徐々に増やします。

• DescribePendingMaintenanceActions コマンドが正確なレスポンスを返した場合でも、後続のコマンド間の待機時間を追加します。数秒の待機時間から始めて、エクスポネンシャルバックオフアルゴリズムを適用し、最大約 5 分間の待機時間まで徐々に増やします。

保留中のメンテナンス更新の表示

DB クラスターでメンテナンスによるアップデートが利用可能かどうかは、RDS コンソール、AWS CLI、または Amazon RDS API を使用して確認します。アップデートが利用できる場合は、次に示すように、Amazon RDS コンソールで DB クラスターの [メンテナンス] 列に表示されます。

DB クラスターのメンテナンスアップデートが利用できない場合は、列の値が [なし] になります。

DB クラスターのメンテナンスアップデートが利用できる場合は、列の値が以下のようになります。

• 必須 - メンテナンスアクションはリソースに適用され、無期限に延期することはできません。

• 利用可能 - メンテナンスアクションは利用可能ですが、自動的にはリソースに適用されません。手動で適用できます。

• 次のウィンドウ - メンテナンスアクションは次回のメンテナンスウィンドウ中にリソースに適用されます。

• 進行中 - メンテナンスアクションはリソースに適用中です。

アップデートを利用できる場合は、いずれかのアクションを実行できます。

• メンテナンス値が [次のウィンドウ] である場合は、[アクション] から [後でアップグレード] を選択してメンテナンス項目を延期します。既にスタートしているメンテナンスアクションは延期できません。

• メンテナンス項目をすぐに適用します。

• メンテナンス項目を次のメンテナンスウィンドウ中にスタートするようにスケジュールを設定します。

• 何のアクションも実行しません。

アクションを実行するには、DB クラスターを選択してその詳細を表示し、次に [メンテナンス & バックアップ] を選択します。保留中のメンテナンス項目が表示されます。

メンテナンスウィンドウは、保留中のオペレーションをスタートする時刻を決定しますが、オペレーションの総実行時間を制限しません。メンテナンスオペレーションは、メンテナンスウィンドウが終了するまでに完了するかどうかは保証されておらず、指定終了時間を超える場合もあります。詳細については、「Amazon RDS メンテナンスウィンドウ」を参照してください。

Amazon Aurora エンジンに対するアップデートと、それらのアップグレードおよびパッチ適用の手順については、「Amazon Aurora MySQL のデータベースエンジンの更新」および「Amazon Aurora PostgreSQL の更新」を参照してください。

また、DB クラスターでメンテナンスによるアップデートが利用可能かどうかは、AWS CLI コマンドの describe-pending-maintenance-actions を使用して確認できます。

メンテナンスによるアップデートの適用については、「DB クラスターのアップデートを適用する」を参照してください。

Amazon RDS メンテナンスウィンドウ

メンテナンスウィンドウは、システムの変更が適用される週単位の時間間隔です。各 DB クラスターには、週ごとのメンテナンスウィンドウがあります。メンテナンスウィンドウは、変更やソフトウェアのパッチなどが実行されるタイミングをコントロールする機会です。メンテナンスウィンドウの調整については、「DB クラスターの適切なメンテナンスウィンドウの調整」を参照してください。

メンテナンスの適用中は、RDS で DB クラスターのリソースの一部が使用されます。わずかながらパフォーマンスに影響が出る場合があります。DB インスタンスでは、まれに、メンテナンスによるアップデートを完了するためにマルチ AZ フェイルオーバーが必要になる場合があります。

メンテナンスイベントを特定の週に予定した場合、そのイベントはユーザーが指定した 30 分のメンテナンスウィンドウ中にスタートされます。ほとんどのメンテナンスイベントは 30 分のメンテナンスウィンドウ中に完了しますが、大規模なメンテナンスイベントは 30 分以上かかる場合があります。DB クラスターが停止すると、メンテナンスウィンドウは一時停止されます。

30 分のメンテナンスウィンドウは、リージョンごとに決められた 8 時間の中でランダムに選択されます。DB クラスターの作成時にメンテナンスウィンドウを指定しないと、RDS でランダムに選択された曜日に 30 分のメンテナンスウィンドウが割り当てられます。

以下では、各リージョンでデフォルトのメンテナンスウィンドウを割り当てる時間帯を確認できます。

リージョン名	リージョン	時間ブロック
米国東部 (バージニア北部)	us-east-1	03:00～11:00 UTC
米国東部 (オハイオ)	us-east-2	03:00～11:00 UTC
米国西部 (北カリフォルニア)	us-west-1	06:00～14:00 UTC
米国西部 (オレゴン)	us-west-2	06:00～14:00 UTC
アフリカ (ケープタウン)	af-south-1	03:00～11:00 UTC
アジアパシフィック (香港)	ap-east-1	06:00～14:00 UTC
アジアパシフィック (ハイデラバード)	ap-south-2	06:30～14:30 UTC
アジアパシフィック (ジャカルタ)	ap-southeast-3	08:00～16:00 UTC
アジアパシフィック (マレーシア)	ap-southeast-5	09:00～17:00 UTC
アジアパシフィック (メルボルン)	ap-southeast-4	11:00～19:00 UTC
アジアパシフィック (ムンバイ)	ap-south-1	06:00～14:00 UTC
アジアパシフィック (大阪)	ap-northeast-3	22:00～06:00 UTC
アジアパシフィック (ソウル)	ap-northeast-2	13:00～21:00 UTC
アジアパシフィック (シンガポール)	ap-southeast-1	14:00～22:00 UTC
アジアパシフィック (シドニー)	ap-southeast-2	12:00～20:00 UTC
アジアパシフィック (東京)	ap-northeast-1	13:00～21:00 UTC
カナダ (中部)	ca-central-1	03:00～11:00 UTC
カナダ西部 (カルガリー)	ca-west-1	18:00～02:00 UTC
中国 (北京)	cn-north-1	06:00～14:00 UTC
中国 (寧夏)	cn-northwest-1	06:00～14:00 UTC
欧州 (フランクフルト)	eu-central-1	13:00～21:00 UTC
欧州 (アイルランド)	eu-west-1	22:00～06:00 UTC
欧州 (ロンドン)	eu-west-2	22:00～06:00 UTC
ヨーロッパ (ミラノ)	eu-south-1	13:00～21:00 UTC
欧州 (パリ)	eu-west-3	23:00～07:00 UTC
欧州 (スペイン)	eu-south-2	13:00～21:00 UTC
欧州 (ストックホルム)	eu-north-1	23:00～07:00 UTC
欧州 (チューリッヒ)	eu-central-2	13:00～21:00 UTC
イスラエル (テルアビブ)	il-central-1	03:00～11:00 UTC
中東 (バーレーン)	me-south-1	06:00～14:00 UTC
中東 (アラブ首長国連邦)	me-central-1	05:00～13:00 UTC
南米 (サンパウロ)	sa-east-1	13:00～21:00 UTC
AWS GovCloud (米国東部)	us-gov-east-1	01:00～09:00 UTC
AWS GovCloud (米国西部)	us-gov-west-1	06:00～14:00 UTC

Aurora DB クラスターのマイナーバージョン自動アップグレード

[自動マイナーバージョンアップグレード] 設定では、Aurora で DB クラスターにアップグレードを自動的に適用するかどうかを指定します。これらのアップグレードには、追加機能とバグ修正などのパッチを含む新しいマイナーバージョンが含まれます。

この設定は、デフォルトでオンになっています。新しい DB クラスターごとに、この設定に適切な値を選択します。この値は、その重要性、予想される有効期間、各アップグレード後に行う検証テストの量に基づいています。

[自動マイナーバージョンアップグレード] 設定をオンまたはオフにする手順については、以下を参照してください。

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

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

重要

新規および既存の DB クラスターでは、この設定はクラスター内の DB インスタンスに個別に適用するのではなく、DB クラスターに適用することを強くお勧めします。この設定がオフになっている DB インスタンスがクラスター内にある場合、DB クラスターは自動アップグレードされません。

次の表は、[自動マイナーバージョンアップグレード] 設定をクラスターレベルとインスタンスレベルで適用した場合にどのように機能するかを示しています。

アクション	クラスター設定	インスタンス設定	クラスターは自動的にアップグレードされたか。
DB クラスターで True に設定する。	True	新規および既存のすべてのインスタンスで True	あり
DB クラスターで False に設定する。	False	新規および既存のすべてのインスタンスで False	なし
DB クラスターでは以前は True に設定されていた。 少なくとも 1 つの DB インスタンスで False に設定する。	False への変更	1 つ以上のインスタンスでは False	なし
DB クラスターでは以前は False に設定されていた。 すべてのインスタンスではなく、少なくとも 1 つの DB インスタンスで True に設定する。	False	1 つ以上のインスタンスで True (すべてのインスタンスではない)	なし
DB クラスターでは以前は False に設定されていた。 すべての DB インスタンスで True に設定する。	True への変更	すべてのインスタンスで True	あり

マイナーバージョンの自動アップグレードは、カテゴリが maintenance で ID が RDS-EVENT-0156 の Amazon RDS DB クラスターイベントを通じて事前に通知されます。詳細については、「Aurora の Amazon RDS イベントカテゴリとイベントメッセージ」を参照してください。

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

Aurora PostgreSQL のエンジンに関するアップデートの詳細については、「Amazon Aurora PostgreSQL の更新」を参照してください。

Aurora MySQL の [マイナーバージョン自動アップグレード] 設定の詳細については、「Aurora MySQL マイナーバージョン間の自動アップグレードの有効化」を参照してください。Aurora MySQL のエンジンのアップデートに関する一般的な情報については、「Amazon Aurora MySQL のデータベースエンジンの更新」を参照してください。

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

コンソール、CLI、API を使用した DB クラスターの変更 の一般的な手順に従います。

コンソール

[DB クラスターの変更] ページの [メンテナンス] セクションで、[マイナーバージョン自動アップグレードの有効化] チェックボックスを選択します。

AWS CLI

modify-db-cluster AWS CLI コマンドを呼び出します。--db-cluster-identifier オプションで DB クラスターの名前を指定し、--auto-minor-version-upgrade オプションで true を指定します。必要に応じて、この設定を DB クラスターですぐに有効にするための --apply-immediately オプションを指定します。

RDS API

ModifyDBCluster API オペレーションを呼び出して、DBClusterIdentifier パラメータの DB クラスター名、AutoMinorVersionUpgrade パラメータの true を指定します。必要に応じて、ApplyImmediately パラメータを true に設定し、この設定を DB クラスターですぐに有効にします。

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

DB クラスター内の DB インスタンスの変更 の一般的な手順に従います。

コンソール

[DB インスタンスの変更] ページの [メンテナンス] セクションで、[マイナーバージョン自動アップグレードの有効化] チェックボックスを選択します。

AWS CLI

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

RDS API

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

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

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

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

[
  {
      "DBInstanceIdentifier": "db-writer-instance",
      "DBClusterIdentifier": "my-db-cluster-57",
      "AutoMinorVersionUpgrade": true
  },
  {
      "DBInstanceIdentifier": "db-reader-instance1",
      "DBClusterIdentifier": "my-db-cluster-57",
      "AutoMinorVersionUpgrade": false
  },
  {
      "DBInstanceIdentifier": "db-writer-instance2",
      "DBClusterIdentifier": "my-db-cluster-80",
      "AutoMinorVersionUpgrade": true
  },
... output omitted ...

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

Aurora MySQL メンテナンスのアップデート頻度を選択する

各 DB クラスターごとに、Aurora MySQL のアップグレードを頻繁に行うか、またはほとんど行わないかを制御できます。最善の選択肢は、Aurora MySQL の使用状況と、Aurora 上で実行しているアプリケーションの優先順位によります。アップグレード頻度の低い Aurora MySQL 長期安定版 (LTS) リリースについては、Aurora MySQL 長期サポート (LTS) リリースを参照してください。

以下の条件の一部またはすべてが適用される場合、Aurora MySQL のクラスターのアップグレードを頻繁にしなくてもよい場合があります。

• アプリケーションのテストサイクルは、Aurora MySQL データベースエンジンのアップデートごとに時間がかかります。

• DB クラスターや同じ Aurora MySQL のバージョンで実行するアプリケーションがありますが、すべての DB クラスターと関連するアプリケーションは同時にアップグレードすることが可能です。

• Aurora MySQL と RDS for MySQL の両方を使用しています。MySQL と同じレベルで互換性のある Aurora MySQL クラスターおよび RDS MySQL DB インスタンスを保持します。

• Aurora MySQL アプリケーションが本番環境にあるか、業務上必要なものです。重要なパッチのまれな発生以外のアップグレードのために、ダウンタイムに対応する余裕はありません。

• Aurora MySQL アプリケーションは、Aurora MySQL 以降のバージョンで対応する性能の問題または機能のギャップに限られません。

上記の要因が自分の状況に当てはまる場合、Aurora MySQL DB クラスターの強制アップグレード回数を制限することが可能です。DB クラスターを作成およびアップグレードする際に、これを実行するには、「長期サポート (LTS)」という特定の Aurora MySQL のバージョンを選択してください。この場合、アップグレードのサイクル、テストサイクルそしてその DB クラスターに対するアップグレードが要因の停止時間を最小限に抑えます。

以下の条件の一部またはすべてに該当する場合、Aurora MySQL のクラスターを頻繁にアップグレードすることを選択できます。

• アプリケーションのテストサイクルは、簡単かつ手短なものでかまいません。

• アプリケーションは、まだ開発段階です。

• データベース環境では、Aurora MySQL の様々なバージョンや、Aurora MySQL および RDS for MySQL のバージョンを使用します。各 Aurora MySQL クラスターには各自のアップグレードサイクルがあります。

• Aurora MySQL の利用率を増幅する前に、特定の性能や機能の改善を待ちます。

上記の要因が自分の状況に当てはまる場合、Aurora を有効にし、より頻繁に重要なアップグレードを実施することが可能です。そのためには、Aurora MySQL DB クラスターを、LTS バージョンより新しい Aurora MySQL のバージョンに Aurora MySQL DB クラスターをアップグレードします。これを実行することで、性能が最新に強化され、バグが修正され、機能をより迅速に利用できるようになります。