Amazon Aurora DB クラスターでダウンタイムが発生する原因を教えてください。

所要時間1分

Amazon Aurora DB クラスターでダウンタイムが発生する理由を把握したいです。

解決策

次の要因で、Aurora DB インスタンスでダウンタイムが発生する可能性があります。

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

メジャーバージョンおよびマイナーバージョンのアップグレードにより、Aurora DB クラスター全体のダウンタイムが発生します。本番環境の DB クラスターをアップグレードする前に、テスト DB クラスターでアップグレードプロセスをテストしてください。アップグレードを行う前に、プロセスの所要時間を確認したうえで、アプリケーションを検証してください。

Aurora Blue/Green デプロイを使用しても、クラスターのメジャーバージョンまたはマイナーバージョンをアップグレードできます。ブルー/グリーンデプロイメントを使用する際のダウンタイムは、通常 1 分未満です。

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

マイナーバージョンを自動アップグレードすると、Aurora DB クラスター全体でダウンタイムが発生します。Aurora は、クラスターのメンテナンス期間中にマイナーバージョンのアップグレードを適用します。Aurora にマイナーバージョンのアップグレードを自動的に適用させたくない場合は、DB インスタンスでそのオプションを無効化してください。

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

注: マイナーバージョンの自動アップグレードを有効にする際には、ダウンタイムは発生しません。ダウンタイムは、Aurora による自動アップグレードの適用時のみ発生します。

Aurora DB クラスターのフェイルオーバーイベント

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

DB クラスターの可用性を向上させるには、2 個以上の異なるアベイラビリティーゾーン (AZ) に 1 個以上の Aurora レプリカを作成してください。詳細については、「Aurora DB クラスターの耐障害性」を参照してください。

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

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

メンテナンス期間を変更する

メンテナンス期間を変更しても、ダウンタイムは自動的には発生しません。DB クラスターに保留中のアクションがある可能性があります。メンテナンス期間を変更すると、保留中のアクションはすぐに適用され、ダウンタイムが発生します。メンテナンス期間の変更に関する詳細については、「Amazon RDS のメンテナンス期間について把握すべきことを教えてください」を参照してください。

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

DB クラスターまたは DB インスタンスを再起動する際、ダウンタイムが発生します。クラスター内の各 DB インスタンスを再起動するのに必要な時間は、再起動時点のデータベースアクティビティによって異なります。ダウンタイムは、DB エンジンの復旧プロセスにも影響を受けます。

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

DB インスタンスクラスを変更する際、ダウンタイムは指定した DB インスタンスで発生しますが、クラスター全体では発生しません。

新しい DB クラスターのパラメータグループまたは DB パラメータグループの関連付け

新しい DB クラスターのパラメータグループを DB クラスターに関連付けたり、DB パラメータグループを DB インスタンスに関連付けたりする際に、ダウンタイムは自動的には発生しません。ダウンタイムは、パラメータグループの変更の適用には再起動を要する場合にのみ発生します。たとえば、DB クラスターのパラメータグループに変更を適用するには、プライマリ DB インスタンスを再起動する必要があります。DB パラメータグループで変更を適用するには、DB インスタンスを再起動する必要があります。

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

ダウンタイムを引き起こす一般的な設定変更の例を次に示します。設定の完全なリストおよび、変更によるダウンタイムの有無については、「Amazon Aurora の設定」を参照してください。

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

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

ただし、DB クラスターのパラメータグループまたは DB パラメータグループで動的パラメータ設定を変更した場合、その変更は DB クラスターに直ちに反映されます。動的パラメータの変更では、DB インスタンスを再起動する必要がないため、ダウンタイムは発生しません。

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

DB インスタンス識別子を変更するには、DB インスタンスを再起動する必要があります。この変更中にダウンタイムが発生します。

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

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

認証機関の変更

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

DB インスタンスのサーバー証明書に対する認証機関 (CA) を変更すると、再起動を伴わないローテーションをサポートしない DB エンジンでは、ダウンタイムが発生します。

使用する DB エンジンが再起動を伴わないローテーションをサポートしているかどうかを確認するには、AWS CLI コマンド describe-db-engine-versions を実行します。