Amazon Aurora DB クラスターのダウンタイムに影響する要因にはどのようなものがありますか?

所要時間2分
0

Amazon Aurora DB クラスターがダウンタイムに陥っている理由を理解したいです。

簡単な説明

Amazon Aurora DB インスタンスは、さまざまな理由でダウンタイムに陥っている可能性があります。ダウンタイムに影響する主な要因は次のとおりです:

  • エンジンバージョンアップグレード
  • DB クラスターフェイルオーバー
  • メンテナンスタスク
  • DB クラスターまたはインスタンスの再起動
  • DB クラスターまたはインスタンスの特定の設定の変更

解決策

**注:**AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新の AWS CLI バージョンを使用していることを確認してください

エンジンバージョンアップグレード

エンジンバージョンのアップグレードには、メジャーバージョンとマイナーバージョンのアップグレードが含まれます。メジャーバージョンとマイナーバージョンのアップグレードの両方で、Aurora DB クラスター全体のダウンタイムが発生します。製品 DB クラスターをアップグレードする前に、テスト用 DB クラスターでアップグレードプロセスをテストすることが重要です。アップグレードを実行する前に、プロセスの所要時間を確認し、アプリケーションを検証してください。

Amazon Relational Database Service (Amazon RDS) のブルー/グリーンデプロイを使用して、クラスターのメジャーバージョンまたはマイナーバージョンをアップグレードすることもできます。ブルー/グリーンデプロイを使用する場合、アップグレードのダウンタイムは通常 1 分未満です。

マイナーバージョンの自動アップグレード

マイナーバージョンの自動アップグレードは、Aurora DB クラスター全体のダウンタイムを引き起こします。これらの自動マイナーバージョンアップグレードは、クラスターのメンテナンス期間中に適用されます。この機能が必要ない場合は、DB インスタンスの自動マイナーバージョンアップグレードをオフにしてください。

詳細については、Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレードを参照してください。

: マイナーバージョンの自動アップグレード機能自体を有効にしても、変更中のダウンタイムは発生しません。ダウンタイムは、Aurora が自動アップグレードを適用した場合にのみ発生します。

DB クラスターフェールオーバー

Aurora DB クラスターに 1 つ以上の Aurora レプリカがある場合、そのレプリカはフェイルオーバーイベント中にプライマリインスタンスに昇格されます。短いダウンタイムが発生し、読み取り操作と書き込み操作は例外で失敗します。通常、サービスは120秒未満、多くの場合60秒未満で復元されます。

DB クラスターの可用性を高めるには、2 つ以上の異なるアベイラビリティーゾーン (AZ) に 1 つ以上の Aurora レプリカを作成します。詳細については、Aurora DB クラスターのフォールトトレランスを参照してください。

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

オペレーティングシステム (OS) の更新やデータベースのパッチなどのメンテナンスタスクによっては、DB クラスターが短期間オフラインになります。詳細については、Amazon Aurora DB クラスターのメンテナンスを参照してください。

メンテナンスウィンドウ

メンテナンスウィンドウを変更しても、ダウンタイムは本質的には発生しません。ただし、DB クラスターには、ダウンタイムの原因となる保留中のアクションが 1 つ以上ある場合があります。メンテナンスウィンドウを変更すると、保留中のアクションがすぐに適用され、ダウンタイムが発生します。メンテナンスウィンドウの変更の詳細については、「Amazon RDS メンテナンスウィンドウについて知っておくべきことは何ですか?」を参照してください。

DB クラスターまたは DB インスタンスの再起動

DB クラスターまたは DB インスタンスを再起動するとダウンタイムが発生します。クラスター内の各 DB インスタンスを再起動するのに必要な時間は、再起動時のデータベースアクティビティによって異なります。ダウンタイムは、特定の DB エンジンの復旧プロセスによっても異なります。詳細については、Amazon Aurora DB クラスターまたは Amazon Aurora DB インスタンスを再起動するを参照してください。

DB インスタンスクラスの変更

インスタンスの DB インスタンスクラスを変更すると、ダウンタイムは指定された DB インスタンスで発生しますが、クラスター全体では発生しません。インスタンスクラスの詳細については、Aurora DB インスタンスクラスを参照してください。

新しい DB クラスターまたは DB パラメータグループをアタッチする

DB インスタンスにアタッチされている DB クラスターまたは DB パラメータグループを変更しても、ダウンタイムは自動的に発生しません。ただし、DB クラスターパラメータグループに変更を適用するには、クラスター内のプライマリ DB インスタンスを再起動する必要があります。DB パラメータグループの場合、変更を適用するにはインスタンスを再起動する必要があります。再起動自体がダウンタイムを引き起こします。詳細については、DB クラスターパラメータグループと DB クラスターの関連付け およびパラメータグループの操作を参照してください。

DB クラスターまたはインスタンスの特定の設定の変更

DB クラスターまたは DB パラメータグループのパラメータ設定の変更

データベースパラメータは静的かかまたは動的です。DB クラスターまたは DB パラメータグループの静的パラメータ設定を変更する場合、パラメータの変更は、関連する各 DB クラスターの DB インスタンスを手動で再起動した後に有効になります。再起動中にダウンタイムが発生します。

ただし、DB クラスターまたは DB パラメーターグループの動的パラメーター設定を変更すると、その変更は DB クラスターに直ちに適用されます。動的パラメータを変更してもインスタンスは再起動されないため、ダウンタイムは発生しません。

詳細については、パラメータグループの操作を参照してください。

DB インスタンス識別子の変更

DB インスタンスが再起動されるため、DB インスタンス識別子を変更するとダウンタイムが発生します。

データベースポートの変更

DB クラスターへのアクセスに使用するデータベースポートを変更すると、ダウンタイムが発生します。これは、DB クラスター内のすべての DB インスタンスがすぐに再起動するためです。

認証局の変更

DB インスタンスが使用するサーバー証明書の認証局 (CA) を変更したい場合があります。このユースケースでは、DB エンジンが再起動なしのローテーションをサポートしていないとダウンタイムが発生します。describe-db-engine-versions AWS CLI コマンドを使用して、DB エンジンが再起動なしのローテーションをサポートしているかどうかを確認します。

Aurora の設定がダウンタイムに影響するかどうかの詳細については、Amazon Aurora の設定を参照してください。

関連情報

最小限のダウンタイムで Amazon Aurora MySQL のメジャーバージョンアップグレードを実行する

AWS公式
AWS公式更新しました 1年前
コメントはありません