[全部乗せ] Amazon Aurora の設定変更で注意が必要なものをまとめてみた

2022.10.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

アノテーション、テクニカルサポートチームの村上です。

Aurora 利用時に、どんな設定変更を実施するとクラスターやインスタンスにダウンタイムが発生するかご存知でしょうか?
本ブログでは、ダウンタイムが発生する設定変更と、必ずしもダウンタイムが発生するわけでは無いが注意が必要となる設定変更についてまとめてみました。

ダウンタイムが発生する設定変更

下表の設定変更を実施すると、Aurora クラスター全体または設定変更を実施した DB インスタンスでダウンタイムが発生します。

エンジンバージョンの変更と DB インスタンスクラスの変更に伴うダウンタイムについては、Aurora を長く運用していれば経験されているかと思いますが、他の設定変更についても一度ご確認いただければと思います。

設定と説明 方法 スコープ ダウンタイムに関する注意
エンジンバージョン
使用する DB エンジンのバージョン。
AWS Management Console の使用、コンソール、CLI、API を使用した DB クラスターの変更。
AWS CLI を使用して、modify-db-cluster を実行し、--engine-version オプションを設定します。
RDS API を使用して、ModifyDBCluster を呼び出し、EngineVersion パラメータを設定します。
DB クラスター全体 この変更中に、機能停止が発生します。
DB インスタンスクラス
使用する DB インスタンスクラス。
AWS Management Console の使用、DB クラスター内の DB インスタンスの変更。
AWS CLI を使用して、modify-db-instance を実行し、--db-instance-class オプションを設定します。
RDS API を使用して、ModifyDBInstance を呼び出し、DBInstanceClass パラメータを設定します。
指定された DB インスタンスのみ この変更中に、機能停止が発生します。
DB インスタンス識別子
DBインスタンス識別子。この値は小文字で保存されます。
AWS Management Console の使用、DB クラスター内の DB インスタンスの変更。
AWS CLI を使用して、modify-db-instance を実行し、--new-db-instance-identifier オプションを設定します。
RDS API を使用して、ModifyDBInstance を呼び出し、NewDBInstanceIdentifier パラメータを設定します。
指定された DB インスタンスのみ この変更中に、機能停止が発生します。DB インスタンスは再起動されます。
データベースポート
DB クラスターへのアクセスに使用するポート。
AWS Management Console の使用、コンソール、CLI、API を使用した DB クラスターの変更。
AWS CLI を使用して、modify-db-cluster を実行し、--port オプションを設定します。
RDS API を使用して、ModifyDBCluster を呼び出し、Port パラメータを設定します。
DB クラスター全体 この変更中に、機能停止が発生します。DB クラスター内のすべての DB インスタンスは、すぐに再起動されます
認証局
DB インスタンスによって使用されるサーバー証明書の認定機関 (CA)。
AWS Management Console の使用、DB クラスター内の DB インスタンスの変更。
AWS CLI を使用して、modify-db-instance を実行し、--ca-certificate-identifier オプションを設定します。
RDS API を使用して、ModifyDBInstance を呼び出し、CACertificateIdentifier パラメータを設定します。
指定された DB インスタンスのみ この変更中に、機能停止が発生します。DB インスタンスは再起動されます。
(2023/08/28 修正)
機能停止は、DB エンジンが再起動なしのローテーションをサポートしていない場合にのみ発生します。describe-db-engine-versions AWS CLI コマンドを使用すると、DB エンジンが再起動なしのローテーションをサポートしているかどうかを判断できます。

DB インスタンス識別子とインスタンスクラスの変更について

DB インスタンス識別子の変更については、設定変更を実施した DB インスタンスでダウンタイムが発生します。

なお、ライターインスタンスの DB インスタンスクラスを変更した際はフェールオーバーが発生しますが、ライターインスタンスの DB 識別子変更にあたってはフェールオーバーは発生しません。
上記内容については、下記のブログで検証をしてみました。

ポート番号の変更について

Aurora クラスターのポート番号設定を変更すると、Aurora クラスター全体にダウンタイムが発生します。
接続元アプリの仕様変更等でポート番号を変更する際は、ご注意ください。
こちらも、下記のブログで検証をしてみました。

そして最後に、認証機関の変更に関しては現状対応が必要な DB インスタンスで運用されている方はいらっしゃらないと思いますが、下記 AWS ドキュメントに詳細があります。

SSL/TLS 証明書のローテーション

2020 年 3 月 5 日現在、Amazon RDS CA-2015 証明書の有効期限は切れています。RDS DB インスタンスに接続するための証明書の検証で Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を使用する場合は、Amazon RDS CA-2019 証明書が必要です。この証明書は、新しい DB インスタンスに対してデフォルトで有効になります。

注意が必要となる設定変更

下表の設定変更に関しては、即座に Aurora クラスターや DB インスタンスにダウンタイムが発生することはありませんが、設定変更の反映に再起動が必要であったり、条件によってはダウンタイムが発生する場合もあります。

設定と説明 方法 スコープ ダウンタイムに関する注意
DB クラスターのパラメータグループ
DB クラスターに関連付ける DB クラスターのパラメータグループ。
AWS Management Console の使用、コンソール、CLI、API を使用した DB クラスターの変更。
AWS CLI を使用して、modify-db-cluster を実行し、--db-cluster-parameter-group-name オプションを設定します。
RDS API を使用して、ModifyDBCluster を呼び出し、DBClusterParameterGroupName パラメータを設定します。
DB クラスター全体 この変更時に機能停止は発生しません。パラメータグループを変更すると、一部のパラメータの変更は、再起動なしで DB クラスター内の DB インスタンスに即時に適用されます。他のパラメータの変更は、DB クラスター内の DB インスタンスが再起動された後でのみ適用されます。
DB パラメータグループ
DB インスタンスに関連付ける DB パラメータグループ。
AWS Management Console の使用、DB クラスター内の DB インスタンスの変更。
AWS CLI を使用して、modify-db-instance を実行し、--db-parameter-group-name オプションを設定します。
RDS API を使用して、ModifyDBInstance を呼び出し、DBParameterGroupName パラメータを設定します。
指定された DB インスタンスのみ この変更時に機能停止は発生しません。
新しい DB パラメータグループを DB インスタンスに関連付ける場合、変更された静的パラメータと動的パラメータは、DB インスタンスが再起動された後にのみ適用されます。ただし、新しく関連付けられた DB パラメータグループの動的パラメータを変更すると、これらの変更は再起動せずに直ちに適用されます。
メンテナンスウィンドウ
システムメンテナンスを実行する時間帯。該当する場合は、システムメンテナンスにはアップグレードが含まれます。メンテナンス時間は、協定世界時 (UTC) の開始時間で、時間単位での実行期間です。
そのウィンドウを現在の時刻に設定した場合、保留中の変更が確実に適用されるように、現在の時刻からウィンドウの終わりまで 30 分以上必要です。
DB クラスターおよび DB クラスターの各 DB インスタンスのそれぞれに対してメンテナンス時間を設定できます。変更のスコープが DB クラスター全体である場合、変更は DB クラスターのメンテナンス時間中に実行されます。変更のスコープが DB インスタンスである場合、変更は DB インスタンスのメンテナンス時間中に実行されます。
DB クラスターのメンテナンスウィンドウとバックアップウィンドウは、重複させることはできません。
AWS Management Console を使用して、DB クラスターのメンテナンス時間を変更するには、コンソール、CLI、API を使用した DB クラスターの変更。
AWS Management Console を使用して、DB インスタンスのメンテナンス時間を変更するには、DB クラスター内の DB インスタンスの変更。
AWS CLI を使用して DB クラスターのメンテナンス時間を変更するには、modify-db-cluster を実行して、--preferred-maintenance-window オプションを設定します。
AWS CLI を使用して DB インスタンスのメンテナンス時間を変更するには、modify-db-instance を実行して、--preferred-maintenance-window オプションを設定します。
RDS API を使用して DB クラスターのメンテナンス時間を変更するには、ModifyDBCluster を呼び出して、PreferredMaintenanceWindow パラメータを設定します。
RDS API を使用して DB インスタンスのメンテナンス時間を変更するには、ModifyDBInstance を呼び出して、PreferredMaintenanceWindow パラメータを設定します。
DB クラスター全体または単一の DB インスタンス 機能停止を引き起こす保留中のアクションが 1 つ以上あり、現在の時刻を含むようにメンテナンス時間を変更した場合、それらの保留中のアクションはすぐに適用され、機能停止は発生します。

設定変更を実施したパラメータの有効化タイミングについて

まず、少しややこしいですが、Aurora のパラメータグループには、クラスターに紐づける DB クラスターパラメータグループと、DB インスタンスに紐づける DB パラメータグループの二種類があります。

変更したパラメータが "動的パラメータ" の場合は即座に設定に反映されますが、"静的パラメータ" の場合は再起動の後に有効となります。

パラメータグループを使用する

DB クラスターパラメータは静的または動的に使用することができます。静的パラメータを変更して DB クラスターのパラメータグループを保存する場合、パラメータの変更は、関連付けられている各 DB クラスター内の DB インスタンスを手動で再起動した後に有効になります。動的パラメータを変更すると、デフォルトでは、パラメータの変更はただちに DB クラスターに適用され、再起動は不要です。

DB インスタンスパラメータは静的または動的に使用することができます。静的パラメータを変更して DB パラメータグループを保存すると、パラメータの変更は関連付けられている DB インスタンスを手動で再起動した後に有効になります。動的パラメータを変更すると、デフォルトでは、パラメータの変更はただちに DB インスタンスに適用され、再起動は不要です。

パラメータグループの優先度

なお、DB クラスターパラメータグループと DB パラメータグループにおいて、同一のパラメータに対して異なる値を設定した場合は、インスタンスに紐づく DB パラメータグループの値が優先されます。

※パラメータを変更するのではなく、新しい DB パラメータグループ自体を DB インスタンスへ関連付けた場合、変更された静的パラメータと動的パラメータは、DB インスタンスが再起動された後にのみ適用されます。

マイナーバージョン自動アップグレードの設定変更(有効化・無効化)

マイナーバージョン自動アップグレードの有効化・無効化に関しては、設定変更時にダウンタイムは発生しません。

※メンテナンスウィンドウにおいて、マイナーバージョン自動アップグレードが実行された際は、ZDP(zero-downtime patching) が適用される Aurora MySQL のインスタンスクラスとエンジンバージョンを除いてダウンタイムが発生します

Amazon Aurora の更新

Amazon Aurora は定期的に更新をリリースします。更新はシステムメンテナンスの時間中に Amazon Aurora DB クラスターに適用されます。更新が適用されるタイミングは、DB クラスターのリージョンやメンテナンスウィンドウの設定、および更新のタイプによって異なります。更新にはデータベースの再起動が必要になるため、通常、20〜30 秒のダウンタイムが発生します。このダウンタイム後に、DB クラスターの使用を再開できます。

ZDP(zero-downtime patching) が適用されるインスタンスクラスとエンジンバージョンについては、下記ブログをご覧ください。

まとめ

よくお問い合わせをいただく、マイナーバージョン自動アップグレードの有効化・無効化に伴うダウンタイムの有無から、ポート番号の変更という少し珍しいものまで、本ブログで取り上げてみました。

本番環境での設定変更実施にあたっては、事前に検証環境で挙動をお確かめいただいてからご実施いただくことをお勧めします。

この記事がどなたかのお役に立てば幸いです。

参考資料