Amazon Aurora DB クラスターまたは Amazon Aurora DB インスタンスの再起動 - Amazon Aurora
Aurora クラスター内の DB インスタンスの再起動読み取り可用性機能のある Aurora クラスターの再起動読み取り可用性機能のない Aurora クラスターの再起動Aurora クラスターとインスタンスの稼働時間のチェックAurora 再起動オペレーションの例

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

通常はメンテナンス上の理由から、DB クラスターまたはクラスター内の一部のインスタンスを再起動する必要がある場合があります。例えば、パラメータグループ内のパラメータを変更したり、別のパラメータグループをクラスターに関連付けるとします。このような場合、変更を有効にするには、クラスターを再起動する必要があります。同様に、クラスター内の 1 つ以上のリーダー DB インスタンスを再起動することもできます。クラスター全体のダウンタイムを最小限に抑えるために、個々のインスタンスの再起動オペレーションを調整できます。

クラスター内の各 DB インスタンスを再起動するために必要な時間は、再起動時のデータベースアクティビティによって異なります。また、特定の DB エンジンの復旧プロセスにも依拠します。実用的であれば、再起動プロセスを開始する前に、その特定のインスタンスのデータベースアクティビティを減らしてください。そうすることで、データベースの再起動に必要な時間を短縮できます。

クラスター内の各 DB インスタンスは、使用可能な状態にある場合にのみ再起動できます。DB インスタンスは、いくつかの理由で利用できない場合があります。これには、停止状態にあるクラスター、インスタンスに適用される変更、バージョンアップグレードなどのメンテナンスウィンドウアクションが含まれます。

DB インスタンスを再起動すると、データベースエンジンプロセスが再起動されます。DB インスタンスを再起動すると一時的に機能停止になります。その間、DB インスタンスのステータスは [rebooting] に設定されます。

注記

DB インスタンスが、その関連付けられた DB パラメータグループに対する最新の変更を使用していない場合、AWS Management Console は、DB パラメータグループのステータスを [再起動の保留中] と表示します。パラメータグループの [再起動の保留中] のステータスにより、次回のメンテナンスウィンドウで自動的に再起動されることはありません。パラメータの最新の変更を DB インスタンスに適用するには、DB インスタンスを手動で再起動します。パラメータグループの詳細については、「「パラメータグループを使用する」 」を参照してください。

Aurora クラスター内の DB インスタンスの再起動

この手順は、Aurora で再起動を実行するときに実行する最も重要なオペレーションです。メンテナンス手順の多くでは、特定の順序で 1 つ以上の Aurora DB インスタンスの再起動が関係します。

DB インスタンスを再起動するには

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

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

  3. [アクション] で、[再起動] を選択します。

    [Reboot DB Instance] ページが表示されます。

  4. [Reboot] を選択して DB インスタンスを再起動します。

    または、[Cancel] (キャンセル) を選択します。

AWS CLI を使用して DB インスタンスを再起動するには、reboot-db-instance コマンドを呼び出します。

Linux、macOS、Unix の場合:

aws rds reboot-db-instance \
    --db-instance-identifier mydbinstance

Windows の場合:

aws rds reboot-db-instance ^
    --db-instance-identifier mydbinstance

Amazon RDS API を使用して DB インスタンスを再起動するには、RebootDBInstance オペレーションを呼び出します。

読み取り可用性機能のある Aurora クラスターの再起動

読み取り可用性機能があると、プライマリまたはセカンダリクラスター内のリーダーインスタンスを再起動せずに Aurora クラスターのライターインスタンスを再起動できます。そうすることで、ライターインスタンスを再起動している間、読み込みオペレーション用にクラスターの高可用性を維持するのに役立ちます。リーダーインスタンスは後で都合の良いスケジュールで再起動できます。例えば、本番クラスターの場合、リーダーインスタンスを一度に 1 つずつ再起動し、プライマリインスタンスの再起動が完了した後にのみ開始できます。再起動する各 DB インスタンスについて、「Aurora クラスター内の DB インスタンスの再起動」 の手順に従います。

プライマリ DB クラスターの読み取り可用性機能は Aurora MySQL バージョン 2.10 以降で使用できます。セカンダリ DB クラスターの読み取り可用性は Aurora MySQL バージョン 3.06 以降で使用できます。

Aurora PostgreSQL では、この関数は次のバージョンでデフォルトで使用できます。

  • バージョン 15 の 15.2 以降

  • バージョン 14 の 14.7 以降

  • バージョン 13 の 13.10 以降

  • バージョン 12 の 12.14 以降

Aurora PostgreSQL の読み取り可用性機能の詳細については、「Aurora レプリカの読み取り可用性の向上」を参照してください。

この機能の前では、プライマリインスタンスを再起動すると、各リーダーインスタンスの再起動が同時に発生していました。Aurora クラスターで古いバージョンを実行している場合は、代わりに 読み取り可用性機能のない Aurora クラスターの再起動 の再起動の手順を使用します。

注記

読み取り可用性のある Aurora DB クラスターの再起動動作の変更は、3.06 以前のバージョンの Aurora MySQL の Aurora グローバルデータベースでは異なります。Aurora グローバルデータベース内のプライマリクラスターのライターインスタンスを再起動しても、プライマリクラスター内のリーダーインスタンスは引き続き使用できます。ただし、セカンダリクラスター内の DB インスタンスは同時に再起動します。

読み取り可用性機能の向上した限定バージョンは、Aurora PostgreSQL バージョン 12.16、13.12、14.9、15.4 以降の、Aurora グローバルデータベースでサポートされています。

クラスターパラメータグループを変更した後、頻繁にクラスターを再起動します。パラメータを変更するには、「「パラメータグループを使用する」 」 の手順に従います。Aurora クラスター内のライター DB インスタンスを再起動して、クラスターパラメータに変更を適用するとします。一部またはすべてのリーダー DB インスタンスは、古いパラメータ設定を引き続き使用することがあります。ただし、異なるパラメータ設定は、クラスターのデータ整合性には影響しません。データファイルの編成に影響するクラスターパラメータは、ライター DB インスタンスによってのみ使用されます。

例えば、Aurora MySQL クラスターで、リーダーインスタンスの前に、ライターインスタンスで binlog_format や innodb_purge_threads などのクラスターパラメータを更新できます。ライターインスタンスだけがバイナリログを書き込み、元に戻すレコードを消去しています。クエリの SQL ステートメントまたはクエリ出力の解釈方法を変更するパラメータについては、リーダーインスタンスを直ちに再起動するように注意する必要がある場合があります。これは、クエリ中の予期しないアプリケーションの動作を回避するために行います。例えば、lower_case_table_names パラメータを変更してライターインスタンスを再起動するとします。この場合、リーダーインスタンスは、すべてが再起動されるまで、新しく作成されたテーブルにアクセスできない場合があります。

すべての Aurora MySQL クラスタパラメータのリストについては、クラスターレベルのパラメータ を参照してください。

すべての Aurora PostgreSQL クラスターパラメータのリストについては、Aurora PostgreSQL クラスターレベルのパラメータ を参照してください。

ヒント

Aurora MySQL は、クラスターが高スループットでワークロードを処理している場合、ライターインスタンスとともに一部のリーダーインスタンスを再起動することがあります。

フェイルオーバー操作中に、再起動回数が減少することもあります。Aurora MySQL は、フェイルオーバー中にはライター DB インスタンスとフェイルオーバーターゲットのみを再起動します。クラスター内の他のリーダー DB インスタンスは、リーダーエンドポイントへの接続を通じてクエリの処理を続行するために引き続き使用できます。したがって、クラスター内に複数のリーダー DB インスタンスを持つことで、フェイルオーバー中の可用性を向上させることができます。

読み取り可用性機能のない Aurora クラスターの再起動

読み取り可用性機能がない場合、Aurora DB クラスター全体を再起動するには、そのクラスターのライター DB インスタンスを再起動します。これを行うには、「Aurora クラスター内の DB インスタンスの再起動」の手順に従います。

ライター DB インスタンスを再起動すると、クラスター内の各リーダー DB インスタンスの再起動も開始されます。これにより、クラスター全体のパラメータの変更がすべての DB インスタンスに同時に適用されます。ただし、すべての DB インスタンスの再起動により、クラスターのための短時間の停止が発生します。リーダー DB インスタンスは、ライター DB インスタンスの再起動が完了して利用可能になるまで利用できません。

この再起動の動作は、Aurora MySQL バージョン 2.9 以前で作成したすべての DB クラスターに適用されます。

Aurora PostgreSQL の場合、この動作は次のバージョンに適用されます。

  • 14.6 以前の 14 バージョン

  • 13.9 以前の 13 バージョン

  • 12.13 以前の 12 バージョン

  • すべての PostgreSQL 11 バージョン

RDS コンソールでは、ライター DB インスタンスは、[Databases] (データベース) ページの [Role] (ロール) 列に [Writer] (ライター) という値を有しています。RDS CLI では、describe-db-clusters コマンドの出力にセクション DBClusterMembers が含まれます。ライター DB インスタンスを表す DBClusterMembers エレメントには、true フィールドの IsClusterWriter の値があります。

重要

読み取り可用性機能がある場合、Aurora MySQL および Aurora PostgreSQL での再起動の動作は異なります。通常、ライターインスタンスを再起動する間、リーダー DB インスタンスは引き続き使用できます。その後、都合の良いタイミングでリーダーインスタンスを再起動できます。一部のリーダーインスタンスを常に使用できるようにする場合は、リーダーインスタンスを相互に重ならないスケジュールで再起動できます。詳細については、「読み取り可用性機能のある Aurora クラスターの再起動」を参照してください。

Aurora クラスターとインスタンスの稼働時間のチェック

Aurora クラスター内の各 DB インスタンスについて、最後の再起動からの時間の長さを確認してモニタリングできます。Amazon CloudWatch メトリクス EngineUptime は、DB インスタンスが最後に起動されてからの秒数をレポートします。このメトリクスをある時点で調べて、DB インスタンスの稼働時間を調べることができます。また、このメトリクスを経時的にモニタリングして、インスタンスが再起動されるタイミングを検出することもできます。

クラスターレベルで EngineUptime メトリクスを調べることもできます。Minimum および Maximum ディメンションは、クラスター内のすべての DB インスタンスの稼働時間の最小値および最大値をレポートします。クラスター内のリーダーインスタンスが再起動された最近の時期、または別の理由で再起動された最近の時期を確認するには、Minimum ディメンションを使用してクラスターレベルのメトリクスをモニタリングします。再起動せずにクラスター内のどのインスタンスが最長になったかを確認するには、Maximum ディメンションを使用してクラスターレベルのメトリクスをモニタリングします。例えば、設定の変更後に、クラスター内のすべての DB インスタンスが再起動されたことを確認したい場合があります。

ヒント

長期モニタリングでは、クラスターレベルではなく、個々のインスタンスの EngineUptime メトリクスをモニタリングすることをお勧めします。クラスターレベルの EngineUptime メトリクスは、新しい DB インスタンスがクラスターに追加されたときにゼロに設定されます。このようなクラスターの変更は、Auto Scaling で実行されるようなメンテナンスおよびスケーリングオペレーションの一環として生じる可能性があります。

次の CLI の例は、クラスター内のライターインスタンスとリーダーインスタンスの EngineUptime メトリクスを調べる方法を示しています。この例では、tpch100g という名前のクラスターを使用しています。このクラスターにはライター DB インスタンス instance-1234 があります。また、instance-7448 と instance-6305 の 2 つのリーダー DB インスタンスがあります。

まず、reboot-db-instance コマンドはリーダーインスタンスの 1 つを再起動します。wait コマンドは、インスタンスの再起動が完了するまで待機します。

$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
    "DBInstance": {
        "DBInstanceIdentifier": "instance-6305",
        "DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-6305

CloudWatch get-metric-statistics コマンドは、直近 5 分間の EngineUptime メトリクスを 1 分間隔で調べます。instance-6305 インスタンスの稼働時間はゼロにリセットされ、再びカウントを開始します。Linux のこの AWS CLI の例では、$() 変数置換を使用して CLI コマンドに適切なタイムスタンプを挿入します。また、Linux sort コマンドを使用して、メトリクスが収集された時間で出力を順序付けます。そのタイムスタンプ値は、出力の各行の 3 番目のフィールドです。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	231.0	2021-03-16T18:19:00+00:00	Seconds
DATAPOINTS	291.0	2021-03-16T18:20:00+00:00	Seconds
DATAPOINTS	351.0	2021-03-16T18:21:00+00:00	Seconds
DATAPOINTS	411.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	471.0	2021-03-16T18:23:00+00:00	Seconds

クラスター内のインスタンスの 1 つが再起動されたため、クラスターの最小稼働時間はゼロにリセットされます。クラスター内の少なくとも 1 つの DB インスタンスが利用可能なままであるため、クラスターの最長稼働時間はリセットされません。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Minimum \
  --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63099.0	2021-03-16T18:12:00+00:00	Seconds
DATAPOINTS	63159.0	2021-03-16T18:13:00+00:00	Seconds
DATAPOINTS	63219.0	2021-03-16T18:14:00+00:00	Seconds
DATAPOINTS	63279.0	2021-03-16T18:15:00+00:00	Seconds
DATAPOINTS	51.0	2021-03-16T18:16:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63389.0	2021-03-16T18:16:00+00:00	Seconds
DATAPOINTS	63449.0	2021-03-16T18:17:00+00:00	Seconds
DATAPOINTS	63509.0	2021-03-16T18:18:00+00:00	Seconds
DATAPOINTS	63569.0	2021-03-16T18:19:00+00:00	Seconds
DATAPOINTS	63629.0	2021-03-16T18:20:00+00:00	Seconds

その後、別の reboot-db-instance コマンドがクラスターのライターインスタンスを再起動します。別の wait コマンドは、ライターインスタンスの再起動が終了するまで一時停止します。

$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
  "DBInstanceIdentifier": "instance-1234",
  "DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-1234

これで、ライターインスタンスの EngineUptime メトリクスに、インスタンス instance-1234 が最近再起動されたことが示されます。リーダーインスタンス instance-6305 も、ライターインスタンスとともに自動的に再起動されました。このクラスターは Aurora MySQL 2.09 を実行しており、ライターインスタンスが再起動してもリーダーインスタンスの実行は維持されません。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63749.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	63809.0	2021-03-16T18:23:00+00:00	Seconds
DATAPOINTS	63869.0	2021-03-16T18:24:00+00:00	Seconds
DATAPOINTS	41.0	2021-03-16T18:25:00+00:00	Seconds
DATAPOINTS	101.0	2021-03-16T18:26:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	411.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	471.0	2021-03-16T18:23:00+00:00	Seconds
DATAPOINTS	531.0	2021-03-16T18:24:00+00:00	Seconds
DATAPOINTS	49.0	2021-03-16T18:26:00+00:00	Seconds

Aurora 再起動オペレーションの例

次の Aurora MySQL の例は、Aurora DB クラスター内のリーダーとライター DB インスタンスの再起動オペレーションのさまざまな組み合わせを示しています。再起動するたびに、SQL クエリはクラスター内のインスタンスの稼働時間を示します。

Aurora クラスターのライターインスタンスとリーダーインスタンスの検索

複数の DB インスタンスを持つ Aurora MySQL クラスターでは、どれがライターで、どれがリーダーであるかを知ることが重要です。ライターインスタンスとリーダーインスタンスは、フェイルオーバーオペレーションが発生したときにロールを切り替えることができます。したがって、ライターまたはリーダーのインスタンスを必要とするオペレーションを実行する前に、次のようなチェックを実行することをお勧めします。この場合、False の IsClusterWriter の値は、リーダーインスタンス、instance-6305、および instance-7448 を識別します。True の値は、ライターインスタンス instance-1234 を識別します。

$ aws rds describe-db-clusters --db-cluster-id tpch100g \
  --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
  --output text
Cluster:     tpch100g
Instance:    instance-6305    False
Instance:    instance-7448    False
Instance:    instance-1234    True

再起動の例を開始する前に、ライターインスタンスの稼働時間は約 1 週間です。この例の SQL クエリは、MySQL 固有の稼働時間をチェックする方法を示しています。この手法は、データベースアプリケーションで使用する場合があります。AWS CLI を使用し、両方の Aurora エンジン用に機能する別のテクニックについては、Aurora クラスターとインスタンスの稼働時間のチェック を参照してください。

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status
    -> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-08 17:49:06.000000 | 174h 42m|
+----------------------------+---------+

1 つのリーダーインスタンスの再起動

この例では、リーダーの DB インスタンスの 1 つを再起動します。おそらく、このインスタンスは、大きなクエリまたは多数の同時実行接続によってオーバーロードされた可能性があります。あるいは、ネットワークの問題が原因で、ライターインスタンスに遅れた可能性があります。再起動オペレーションを開始した後、例では、インスタンスが使用可能になるまで一時停止する wait コマンドを使用します。その時点まで、インスタンスの稼働時間は数分です。

$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
    "DBInstance": {
        "DBInstanceIdentifier": "instance-6305",
        "DBInstanceStatus": "rebooting",
...
    }
}
$ aws rds wait db-instance-available --db-instance-id instance-6305
$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status
    -> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:35:02.000000 | 00h 03m |
+----------------------------+---------+

リーダーインスタンスを再起動しても、ライターインスタンスの稼働時間には影響しませんでした。まだ約 1 週間の稼働時間があります。

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+----------+
| Last Startup               | Uptime   |
+----------------------------+----------+
| 2021-03-08 17:49:06.000000 | 174h 49m |
+----------------------------+----------+

ライターインスタンスの再起動

この例では、ライターインスタンスを再起動します。このクラスターは Aurora MySQL バージョン 2.09 を実行しています。Aurora MySQL バージョンが 2.10 より低いため、ライターインスタンスを再起動すると、クラスター内のリーダーインスタンスも再起動されます。

wait コマンドは再起動が完了するまで一時停止します。これで、そのインスタンスの稼働時間はゼロにリセットされます。ライター DB インスタンスとリーダー DB インスタンスでは、再起動オペレーションにかかる時間が大幅に異なる場合があります。ライターおよびリーダー DB インスタンスは、ロールに応じて異なる種類のクリーンアップオペレーションを実行します。

$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
    "DBInstance": {
        "DBInstanceIdentifier": "instance-1234",
        "DBInstanceStatus": "rebooting",
...
    }
}
$ aws rds wait db-instance-available --db-instance-id instance-1234
$ mysql -h instance-1234.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:40:27.000000 | 00h 00m |
+----------------------------+---------+

ライター DB インスタンスの再起動後、両方のリーダー DB インスタンスの稼働時間がリセットされます。ライターインスタンスを再起動すると、リーダーインスタンスも再起動しました。この動作は、Aurora PostgreSQL クラスターおよびバージョン 2.10 より前の Aurora MySQL クラスターに適用されます。

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:40:35.000000 | 00h 00m |
+----------------------------+---------+

$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:40:33.000000 | 00h 01m |
+----------------------------+---------+

ライターとリーダーの独立した再起動

次の例は、Aurora MySQL バージョン 2.10 を実行するクラスターを示しています。この Aurora MySQL バージョン以降では、すべてのリーダーインスタンスの再起動を行わずにライターインスタンスを再起動できます。これにより、ライターインスタンスを再起動しても、クエリを大量に消費するアプリケーションが停止することはありません。リーダーインスタンスは後で再起動できます。これらの再起動は、クエリトラフィックが少ない時に実行できます。リーダーインスタンスを一度に 1 つずつ再起動することもできます。これにより、アプリケーションのクエリアントラフィックのために、少なくとも 1 つのリーダーインスタンスが常に利用可能になります。

次の例では、Aurora MySQL バージョン cluster-2393 を実行している 5.7.mysql_aurora.2.10.0 という名前のクラスターを使用しています。このクラスターには、instance-9404 という名前のライターインスタンスと、instance-6772、instance-2470、instance-5138 という名前の 3 つのリーダーインスタンスがあります。

$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
  --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
  --output text
Cluster:        cluster-2393
Instance:       instance-5138        False
Instance:       instance-2470        False
Instance:       instance-6772        False
Instance:       instance-9404        True

uptime コマンドを使用して各データベースインスタンスの mysql の値をチェックすると、各データベースインスタンスの稼働時間がほぼ同じであることが表示されます。例えば、instance-5138 の稼働時間は次のとおりです。

mysql> SHOW GLOBAL STATUS LIKE 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime        | 3866  |
+---------------+-------+

CloudWatch を使用すると、実際にインスタンスにログインしなくても、対応する稼働時間の情報を取得できます。これにより、管理者はデータベースをモニタリングできますが、テーブルデータを表示または変更することはできません。この場合、5 分間の期間を指定し、毎分稼働時間の値をチェックします。稼働時間の値の増加は、その期間中にインスタンスが再起動されなかったことを示しています。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	4648.0	2021-03-17T23:42:00+00:00	Seconds
DATAPOINTS	4708.0	2021-03-17T23:43:00+00:00	Seconds
DATAPOINTS	4768.0	2021-03-17T23:44:00+00:00	Seconds
DATAPOINTS	4828.0	2021-03-17T23:45:00+00:00	Seconds
DATAPOINTS	4888.0	2021-03-17T23:46:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	4315.0	2021-03-17T23:42:00+00:00	Seconds
DATAPOINTS	4375.0	2021-03-17T23:43:00+00:00	Seconds
DATAPOINTS	4435.0	2021-03-17T23:44:00+00:00	Seconds
DATAPOINTS	4495.0	2021-03-17T23:45:00+00:00	Seconds
DATAPOINTS	4555.0	2021-03-17T23:46:00+00:00	Seconds

ここで、リーダーインスタンス instance-5138 のいずれかを再起動します。再起動後、インスタンスが再び利用可能になるまで待機します。5 分間の稼働時間をモニタリングすると、その間に稼働時間がゼロにリセットされたことがわかります。最新の稼働時間の値は、再起動が完了してから 5 秒後に測定されました。

$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
  "DBInstanceIdentifier": "instance-5138",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	4500.0	2021-03-17T23:46:00+00:00	Seconds
DATAPOINTS	4560.0	2021-03-17T23:47:00+00:00	Seconds
DATAPOINTS	4620.0	2021-03-17T23:48:00+00:00	Seconds
DATAPOINTS	4680.0	2021-03-17T23:49:00+00:00	Seconds
DATAPOINTS  5.0 2021-03-17T23:50:00+00:00 Seconds

次に、ライターインスタンス instance-9404 の再起動を実行します。ライターインスタンスとリーダーインスタンスの 1 つの稼働時間の値を比較します。これにより、ライターを再起動してもリーダーは再起動されないことがわかります。Aurora MySQL 2.10 より前のバージョンでは、すべてのリーダーの稼働時間の値はライターと同時にリセットされます。

$ aws rds reboot-db-instance --db-instance-identifier instance-9404
{
  "DBInstanceIdentifier": "instance-9404",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-9404

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	371.0	2021-03-17T23:57:00+00:00	Seconds
DATAPOINTS	431.0	2021-03-17T23:58:00+00:00	Seconds
DATAPOINTS	491.0	2021-03-17T23:59:00+00:00	Seconds
DATAPOINTS	551.0	2021-03-18T00:00:00+00:00	Seconds
DATAPOINTS  37.0  2021-03-18T00:01:00+00:00 Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	5215.0	2021-03-17T23:57:00+00:00	Seconds
DATAPOINTS	5275.0	2021-03-17T23:58:00+00:00	Seconds
DATAPOINTS	5335.0	2021-03-17T23:59:00+00:00	Seconds
DATAPOINTS	5395.0	2021-03-18T00:00:00+00:00	Seconds
DATAPOINTS	5455.0	2021-03-18T00:01:00+00:00	Seconds

すべてのリーダーインスタンスで、設定パラメータへの変更がライターインスタンスとすべて同じであることを確認するには、ライターの後にすべてのリーダーインスタンスを再起動します。次の例は、すべてのリーダーを再起動し、すべてのリーダーが使用可能になるまで待機してから続行します。

$ aws rds reboot-db-instance --db-instance-identifier instance-6772
{
  "DBInstanceIdentifier": "instance-6772",
  "DBInstanceStatus": "rebooting"
}

$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
  "DBInstanceIdentifier": "instance-2470",
  "DBInstanceStatus": "rebooting"
}

$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
  "DBInstanceIdentifier": "instance-5138",
  "DBInstanceStatus": "rebooting"
}

$ aws rds wait db-instance-available --db-instance-id instance-6772
$ aws rds wait db-instance-available --db-instance-id instance-2470
$ aws rds wait db-instance-available --db-instance-id instance-5138

これで、ライター DB インスタンスの稼働時間が最も長いことがわかります。このインスタンスの稼働時間の値は、モニタリング期間を通じて着実に増加しました。リーダー DB インスタンスはすべて、リーダーの後に再起動されました。各リーダーが再起動され、その稼働時間がゼロにリセットされたモニタリング期間内の時点を確認できます。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	457.0	2021-03-18T00:08:00+00:00	Seconds
DATAPOINTS	517.0	2021-03-18T00:09:00+00:00	Seconds
DATAPOINTS	577.0	2021-03-18T00:10:00+00:00	Seconds
DATAPOINTS	637.0	2021-03-18T00:11:00+00:00	Seconds
DATAPOINTS  697.0 2021-03-18T00:12:00+00:00 Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-2470 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	5819.0	2021-03-18T00:08:00+00:00	Seconds
DATAPOINTS  35.0  2021-03-18T00:09:00+00:00 Seconds
DATAPOINTS	95.0	2021-03-18T00:10:00+00:00	Seconds
DATAPOINTS	155.0	2021-03-18T00:11:00+00:00	Seconds
DATAPOINTS	215.0	2021-03-18T00:12:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	1085.0	2021-03-18T00:08:00+00:00	Seconds
DATAPOINTS	1145.0	2021-03-18T00:09:00+00:00	Seconds
DATAPOINTS	1205.0	2021-03-18T00:10:00+00:00	Seconds
DATAPOINTS  49.0  2021-03-18T00:11:00+00:00 Seconds
DATAPOINTS	109.0	2021-03-18T00:12:00+00:00	Seconds

Aurora MySQL バージョン 2.10 クラスターへのクラスターパラメータの変更の適用

次の例では、Aurora MySQL 2.10 クラスター内のすべての DB インスタンスにパラメータの変更を適用する方法を示します。この Aurora MySQL バージョンでは、ライターインスタンスとすべてのリーダーインスタンスを個別に再起動します。

この例では、説明のために MySQL 設定パラメータ lower_case_table_names を使用します。このパラメータ設定がライターとリーダーの DB インスタンス間で異なる場合、大文字、または大文字と小文字が混在した名前で宣言されたテーブルにクエリがアクセスできないことがあります。または、2 つのテーブル名で異なるのが大文字と小文字のみである場合、クエリが間違ったテーブルにアクセスする可能性があります。

この例では、各インスタンスの IsClusterWriter 属性を調べて、クラスター内のライターインスタンスとリーダーインスタンスを特定する方法を示します。クラスターには cluster-2393 という名前が付けられています。クラスターには、instance-9404 という名前のライターインスタンスがあります。クラスター内のリーダーインスタンスには、instance-5138 と instance-2470 という名前が付けられています。

$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output text
cluster-2393
instance-5138        False
instance-2470        False
instance-9404        True

lower_case_table_names パラメータの変更の影響を示すために、2 つの DB クラスターパラメータグループを設定します。lower-case-table-names-0 パラメータグループでは、このパラメータが 0 に設定されています。lower-case-table-names-1 パラメータグループでは、このパラメータグループが 1 に設定されています。

$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-0' \
  --db-parameter-group-family aurora-mysql5.7 \
  --db-cluster-parameter-group-name lower-case-table-names-0
{
    "DBClusterParameterGroup": {
        "DBClusterParameterGroupName": "lower-case-table-names-0",
        "DBParameterGroupFamily": "aurora-mysql5.7",
        "Description": "lower-case-table-names-0"
    }
}

$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-1' \
  --db-parameter-group-family aurora-mysql5.7 \
  --db-cluster-parameter-group-name lower-case-table-names-1
{
    "DBClusterParameterGroup": {
        "DBClusterParameterGroupName": "lower-case-table-names-1",
        "DBParameterGroupFamily": "aurora-mysql5.7",
        "Description": "lower-case-table-names-1"
    }
}

$ aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name lower-case-table-names-0 \
  --parameters ParameterName=lower_case_table_names,ParameterValue=0,ApplyMethod=pending-reboot
{
    "DBClusterParameterGroupName": "lower-case-table-names-0"
}

$ aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name lower-case-table-names-1 \
    --parameters ParameterName=lower_case_table_names,ParameterValue=1,ApplyMethod=pending-reboot
{
    "DBClusterParameterGroupName": "lower-case-table-names-1"
}

lower_case_table_names のデフォルト値は 0 です。このパラメータを設定すると、テーブル foo はテーブル FOO とは区別されます。この例では、パラメータが引き続きデフォルト設定になっていることを確認します。その後、名前の大文字と小文字だけが異なる 3 つのテーブルを作成します。

mysql> create database lctn;
Query OK, 1 row affected (0.07 sec)

mysql> use lctn;
Database changed
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        0 |
+--------------------------+

mysql> create table foo (s varchar(128));
mysql> insert into foo values ('Lowercase table name foo');

mysql> create table Foo (s varchar(128));
mysql> insert into Foo values ('Mixed-case table name Foo');

mysql> create table FOO (s varchar(128));
mysql> insert into FOO values ('Uppercase table name FOO');

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+---------------------------+
| s                         |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+

次に、DB パラメータグループをクラスターに関連付けて、lower_case_table_names パラメータを 1 に設定します。この変更は、各 DB インスタンスが再起動された後にのみ有効になります。

$ aws rds modify-db-cluster --db-cluster-identifier cluster-2393 \
  --db-cluster-parameter-group-name lower-case-table-names-1
{
  "DBClusterIdentifier": "cluster-2393",
  "DBClusterParameterGroup": "lower-case-table-names-1",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.0"
}

実行する最初の再起動は、ライター DB インスタンスのためのものです。その後、インスタンスが再び利用可能になるのを待ちます。その時点で、ライターエンドポイントに接続し、ライターインスタンスに変更されたパラメータ値があることを確認します。SHOW TABLES コマンドは、データベースに 3 つの異なるテーブルが含まれていることを確認します。ただし、foo、Foo、または FOO という名前のテーブルを参照するクエリはすべて、名前がすべて小文字のテーブル foo にアクセスします。

# Rebooting the writer instance
$ aws rds reboot-db-instance --db-instance-identifier instance-9404
$ aws rds wait db-instance-available --db-instance-id instance-9404

これで、クラスターエンドポイントを使用するクエリは、パラメータの変更の影響を示すようになりました。クエリ内のテーブル名が大文字、小文字、または大文字と小文字の混在のいずれであっても、SQL ステートメントは、名前がすべて小文字のテーブルにアクセスします。

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        1 |
+--------------------------+

mysql> use lctn;
mysql> show tables;
+----------------+
| Tables_in_lctn |
+----------------+
| FOO            |
| Foo            |
| foo            |
+----------------+

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

次の例は、前のクエリと同じクエリを示しています。この場合、クエリはリーダーエンドポイントを使用し、リーダー DB インスタンスの 1 つで実行されます。それらのインスタンスはまだ再起動されていません。したがって、lower_case_table_names パラメータのための元の設定が残っています。つまり、クエリは、foo、Foo、および FOO の各テーブルにアクセスできます。

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        0 |
+--------------------------+

mysql> use lctn;

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+---------------------------+
| s                         |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+

次に、リーダーインスタンスの 1 つを再起動し、それが再び利用可能になるまで待機します。

$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
  "DBInstanceIdentifier": "instance-2470",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-2470

instance-2470 のインスタンスエンドポイントに接続している間、クエリは新しいパラメータが有効であることを示します。

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        1 |
+--------------------------+

この時点で、クラスター内の 2 つのリーダーインスタンスが異なる lower_case_table_names 設定で実行されています。したがって、クラスターのリーダーエンドポイントへの接続は、予測不可能なこの設定の値を使用します。もう一方のリーダーインスタンスを直ちに再起動して、両方とも一貫した設定となるようにすることが重要です。

$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
  "DBInstanceIdentifier": "instance-5138",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138

次の例では、すべてのリーダーインスタンスが lower_case_table_names パラメータ用に同じ設定となっていることを確認します。コマンドは、各リーダーインスタンスの lower_case_table_names 設定値をチェックします。その後、リーダーエンドポイントを使用する同じコマンドで、リーダーエンドポイントへの各接続でリーダーインスタンスの 1 つが使用されることが示されますが、どれを使用するのかは予測できません。

# Check lower_case_table_names setting on each reader instance.

$ mysql -h instance-5138.a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138            |                        1 |
+--------------------------+--------------------------+

$ mysql -h instance-2470.a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-2470            |                        1 |
+--------------------------+--------------------------+

# Check lower_case_table_names setting on the reader endpoint of the cluster.

$ mysql -h cluster-2393.cluster-ro-a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138            |                        1 |
+--------------------------+--------------------------+

# Run query on writer instance

$ mysql -h cluster-2393.cluster-a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-9404            |                        1 |
+--------------------------+--------------------------+

パラメータの変更をあらゆる場所に適用することで、lower_case_table_names=1 の設定の効果を確認できます。テーブルが foo、Foo、FOO のいずれとして参照されるかによって、クエリは名前を foo に変換し、各場合で同じテーブルにアクセスします。

mysql> use lctn;

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+