Amazon Aurora DB クラスターのメンテナンス
Amazon RDS では、Amazon RDS リソースのメンテナンスを定期的に実行します。以下のトピックで、こうしたメンテナンスアクションとその適用方法について説明します。
目次
DB クラスターのメンテナンス更新の概要
メンテナンスでは、ほとんどの場合、DB クラスターの以下のリソースの更新が行われます。
-
基盤となるハードウェア
-
基盤となるオペレーティングシステム (OS)
-
データベースエンジンのバージョン
通常、オペレーティングシステムのアップデートはセキュリティ問題に関連しています。できるだけ早く行うことをお勧めします。オペレーティングシステムのアップデートの詳細については、「Aurora DB クラスターのオペレーティングシステムの更新」を参照してください。
メンテナンス更新中のオフラインリソース
一部のメンテナンス項目では、Amazon RDS が DB クラスターを少しの間オフラインにする必要があります。リソースをオフラインにする必要があるメンテナンス項目には、必要なオペレーティングシステムやデータベースのパッチが含まれます。セキュリティやインスタンスの信頼性に関連するパッチのみ、必須のパッチ適用として自動的にスケジューリングされます。そのようなパッチ適用はまれであり、通常は数か月に一度です。メンテナンスウィンドウのごくわずかしか必要としないことがほとんどです。
遅延 DB インスタンスと DB クラスターの変更
すぐに適用しないことを選択した遅延 DB クラスターおよびインスタンスの変更は、メンテナンス期間中に適用されます。例えば、メンテナンス期間中に DB インスタンスクラス、クラスターまたは DB パラメータグループの変更を選択できます。保留中の再起動設定を使用して指定した変更は、[ 保留中のメンテナンス ] リストに表示されません。DB クラスターの変更については、「Amazon Aurora DB クラスターの変更」を参照してください。
次のメンテナンスウィンドウに向けて保留中の変更を確認するには、describe-db-clustersPendingModifiedValues フィールドを確認します。
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 クラスターのメンテナンスアップデートが利用できる場合は、列の値が以下のようになります。
-
必須 - メンテナンスアクションはリソースに適用され、無期限に延期することはできません。
-
利用可能 - メンテナンスアクションは利用可能ですが、自動的にはリソースに適用されません。手動で適用できます。
-
次のウィンドウ - メンテナンスアクションは次回のメンテナンスウィンドウ中にリソースに適用されます。
-
進行中 - メンテナンスアクションはリソースに適用中です。
更新が利用可能な場合は、以下のいずれかの操作を行います。
-
メンテナンスの値が [次のウィンドウ] である場合は、[アクション] から [アップグレードを延期する] を選択してメンテナンスアクションを延期します。既にスタートしているメンテナンスアクションは延期できません。
-
メンテナンスアクションをすぐに適用する。
-
次回のメンテナンスウィンドウ中にメンテナンスアクションを適用します。
-
何のアクションも実行しません。
AWS Management Consoleを使用してアクションを実行するには
-
DB インスタンスまたはクラスターを選択して、その詳細を表示します。
-
[メンテナンスとバックアップ] を選択します。保留中のメンテナンスアクションが表示されます。
-
実行するアクションを選択し、適用するタイミングを選択します。
メンテナンスウィンドウは、保留中のオペレーションをスタートする時刻を決定しますが、オペレーションの総実行時間を制限しません。メンテナンスオペレーションは、メンテナンスウィンドウが終了するまでに完了するかどうかは保証されておらず、指定終了時間を超える場合もあります。詳細については、「Amazon RDS メンテナンスウィンドウ」を参照してください。
また、DB クラスターでメンテナンスによるアップデートが利用可能かどうかは、AWS CLI コマンドの describe-pending-maintenance-actions を使用して確認することもできます。
メンテナンスによるアップデートの適用については、「DB クラスターへの更新の適用」を参照してください。
Amazon Aurora のメンテナンスアクション
Aurora DB クラスターには、次のメンテナンスアクションが適用されます。
-
os-upgrade– ローリングアップグレードを使用して、DB クラスター内のすべての DB インスタンスのオペレーティングシステムを更新します。詳細については、「Aurora DB クラスターのオペレーティングシステムの更新」を参照してください。 -
system-update– Aurora PostgreSQL の DB エンジンにパッチを適用します。
Aurora DB インスタンスには、次のメンテナンスアクションが適用されます。
-
ca-certificate-rotation– DB インスタンスの Amazon RDS 認証局証明書を更新します。 -
hardware-maintenance– DB インスタンスの基盤となるハードウェアでメンテナンスを実行します。 -
system-update– DB インスタンスのオペレーティングシステムを更新します。
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 クラスターをアップグレードします。これを実行することで、性能が最新に強化され、バグが修正され、機能をより迅速に利用できるようになります。
