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

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

Amazon RDS では、Amazon RDS リソースのメンテナンスを定期的に実行します。通常、メンテナンスには DB クラスターの基盤となるオペレーティングシステム (OS) やデータベースエンジンのバージョンのアップデートが伴います。通常、オペレーティングシステムのアップデートはセキュリティの問題に関連しているため、できるだけ早急に適用する必要があります。

一部のメンテナンス項目では、Amazon RDS が DB クラスターを少しの間オフラインにする必要があります。リソースをオフラインにする必要があるメンテナンス項目には、必要なオペレーティングシステムやデータベースのパッチが含まれます。セキュリティやインスタンスの信頼性に関連するパッチのみ、必須のパッチ適用として自動的にスケジューリングされます。このようなパッチは頻繁に発生するものではありません (通常数ヵ月ごとに一度です)。またお客様のメンテナンスウィンドウのごく一部以外を使用する必要があることは稀なはずです。

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

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

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


            使用できるオフラインパッチ

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

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

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

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

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

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

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

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

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

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

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

注記

OS の特定のアップデートは、[必須] としてマークされます。必須のアップデートを延期すると、アップデートを適用する時間を示す通知を Amazon RDS から受け取ります。その他のアップデートは [利用可能] とマークされ、これらのアップデートは無期限に延期できます。

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


            保留中のメンテナンス項目

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

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

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

DB クラスターのアップデートを適用する

Amazon RDS を使用すると、メンテナンスオペレーションを適用するタイミングを選択できます。RDS コンソール、AWS Command Line Interface (AWS CLI)、または RDS API を使用して、Amazon RDS にアップデートを適用するタイミングを指定できます。

DB クラスターのアップデートを管理するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択します。

  3. アップデートが必要な DB クラスターを選択します。

  4. [アクション] で、以下のいずれかのオプションを選択します。

    • 今すぐアップグレード

    • 次のウィンドウでアップグレード

      注記

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

      メンテナンスアクションをキャンセルするには、DB インスタンスを変更し、[マイナーバージョン自動アップグレード] を無効にします。

保留中のアップデートを DB クラスターに適用するには、AWS CLI コマンドの apply-pending-maintenance-action を使用します。

Linux、macOS、Unix の場合:

aws rds apply-pending-maintenance-action \ --resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db \ --apply-action system-update \ --opt-in-type immediate

Windows の場合:

aws rds apply-pending-maintenance-action ^ --resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db ^ --apply-action system-update ^ --opt-in-type immediate
注記

メンテナンスアクションを延期するには、undo-opt-in として --opt-in-type を指定します。メンテナンスアクションが既にスタートされている場合は、undo-opt-in として --opt-in-type を指定できません。

メンテナンスアクションをキャンセルするには、modify-db-instance AWS CLI コマンドを実行し、--no-auto-minor-version-upgrade を指定します。

少なくとも 1 つの保留中のアップデートがあるリソースのリストを取得するには、describe-pending-maintenance-actions AWS CLI コマンドを使用します。

Linux、macOS、Unix の場合:

aws rds describe-pending-maintenance-actions \ --resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db

Windows の場合:

aws rds describe-pending-maintenance-actions ^ --resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db

AWS CLI コマンド describe-pending-maintenance-actions--filters パラメータを指定して、DB クラスターのリソースのリストを取得することもできます。--filters コマンドの形式は、Name=filter-name,Value=resource-id,... です。

以下は、フィルターの Name パラメータの許容値です。

  • db-instance-id - DB インスタンス識別子または Amazon リソースネーム (ARN) のリストが許容されます。返されるリストには、これらの ID または ARN で識別された DB インスタンスの保留中のメンテナンスアクションのみが含まれます。

  • db-cluster-id - DB クラスター識別子または Amazon Aurora 用の ARN のリストが許容されます。返されるリストには、これらの ID または ARN で識別された DB クラスターの保留中のメンテナンスアクションのみが含まれます。

次の例では、sample-cluster1 DB クラスターと sample-cluster2 DB クラスターの保留中のメンテナンスアクションが返されます。

Linux、macOS、Unix の場合:

aws rds describe-pending-maintenance-actions \ --filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2

Windows の場合:

aws rds describe-pending-maintenance-actions ^ --filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2

アップデートを DB クラスターに適用するには、Amazon RDS API の ApplyPendingMaintenanceAction オペレーションを呼び出します。

少なくとも 1 つの保留中のアップデートがあるリソースのリストを返すには、Amazon RDS API の DescribePendingMaintenanceActions オペレーションを呼び出します。

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

すべての DB クラスターには週次のメンテナンスウィンドウがあり、その期間内にシステムの変更が適用されます。メンテナンスウィンドウは、変更やソフトウェアのパッチなどが実行されるタイミングをコントロールする機会と考えます。メンテナンスイベントを特定の週に予定した場合、そのイベントはユーザーが指定した 30 分のメンテナンスウィンドウ中にスタートされます。ほとんどのメンテナンスイベントは 30 分のメンテナンスウィンドウ中に完了しますが、大規模なメンテナンスイベントは 30 分以上かかる場合があります。

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

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

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

リージョン名 リージョン 時間ブロック
米国東部 (オハイオ) us-east-2 03:00~11:00 UTC
米国東部 (バージニア北部) us-east-1 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-southeast-3 08:00~16: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
中国 (北京) 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-west-3 23:00~07:00 UTC
ヨーロッパ (ミラノ) eu-south-1 13:00~21:00 UTC
欧州 (ストックホルム) eu-north-1 23:00~07: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

DB クラスターの適切なメンテナンスウィンドウの調整

Aurora DB クラスターのメンテナンスウィンドウは、使用率の最も低い時間帯に設定する必要があるため、状況に応じて時間の変更が必要になる場合があります。適用するアップデートのために機能停止が必要な場合は、このメンテナンスウィンドウ中、DB クラスターは使用できなくなります。機能停止は、アップデートのための最小所要時間とします。

DB クラスターの適切なメンテナンスウィンドウを調整するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択します。

  3. メンテナンスウィンドウを変更する DB クラスターを選択します。

  4. 変更を選択します。

  5. [メンテナンス] セクションで、メンテナンスウィンドウをアップデートします。

  6. [続行] を選択します。

    確認ページで、変更内容を確認します。

  7. 変更をメンテナンスウィンドウにすぐに適用するには、[変更のスケジューリング] セクションで [今すぐ] を選択します。

  8. [クラスターの変更] を選択して、変更を保存します。

    または、[戻る] を選択して変更を編集するか、[キャンセル] を選択して変更をキャンセルします。

DB クラスターに設定するメンテナンスウィンドウを調整するには、以下のパラメータを指定して AWS CLI の modify-db-cluster コマンドを使用します

  • --db-cluster-identifier

  • --preferred-maintenance-window

次のコード例では、メンテナンスウィンドウを火曜日の午前 4:00 から 4:30 UTC に設定します。

Linux、macOS、Unix の場合:

aws rds modify-db-cluster \ --db-cluster-identifier my-cluster \ --preferred-maintenance-window Tue:04:00-Tue:04:30

Windows の場合:

aws rds modify-db-cluster ^ --db-cluster-identifier my-cluster ^ --preferred-maintenance-window Tue:04:00-Tue:04:30

DB クラスターに設定するメンテナンスウィンドウを調整するには、以下のパラメータで Amazon RDS の ModifyDBCluster API オペレーションを使用します。

  • DBClusterIdentifier

  • PreferredMaintenanceWindow

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

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

注記

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

この設定をオン/オフにする手順については、「Amazon Aurora の設定」を参照してください。特に、クラスター内のすべての DB インスタンスに同じ設定を適用してください。この設定がオフになっている DB インスタンスがクラスター内にある場合、クラスターは自動アップグレードされません。

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

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

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 クラスターをアップグレードします。これを実行することで、性能が最新に強化され、バグが修正され、機能をより迅速に利用できるようになります。