Aurora Serverless v2 DB クラスターの管理

Aurora Serverless v2 では、クラスターはプロビジョン済みクラスターと交換可能です。Aurora Serverless v2 プロパティは、DB クラスター内の 1 つまたは複数の DB インスタンスに適用されます。したがって、クラスターの作成、クラスターの変更、スナップショットの作成と復元などの手順は、他の種類の Aurora クラスターと基本的に同じです。Aurora クラスターと DB インスタンスを管理するための一般的な手順については、「Amazon Aurora DB クラスターの管理」を参照してください。

次のトピックでは、Aurora Serverless v2 DB インスタンスを含むクラスターの管理に関する考慮事項について説明します。

Aurora Serverless v2 クラスターの容量設定

Aurora Serverless v2 DB インスタンスを含むクラスターの設定パラメータやその他の設定、または DB インスタンス自体を変更するには、プロビジョン済みクラスターの場合と同様の一般的な手順に従います。詳細については、「Amazon Aurora DB クラスターの変更」を参照してください。

Aurora Serverless v2 に固有の最も重要な設定は容量範囲です。Aurora クラスターの Aurora 容量単位 (ACU) の最小値と最大値を設定した後は、クラスター内の Aurora Serverless v2 DB インスタンスを積極的に調整する必要はありません。それは Aurora が行います。この設定は、クラスターレベルで管理されます。クラスター内の各 Aurora Serverless v2 DB インスタンスには、同一の最小 ACU と最大 ACU が適用されます。

以下の特定の値を設定できます。

新しい DB エンジンバージョンでは、最大容量 256 ACU、最小容量 0 ACU、またはその両方を使用できます。さまざまな DB エンジンバージョンの容量範囲については、「Aurora Serverless v2 の容量」を参照してください。

最小容量を 0 ACU に設定することで有効になる自動一時停止と再開機能については、「Aurora Serverless v2 の自動一時停止と再開によるゼロ ACU へのスケーリング」を参照してください。

Aurora Serverless v2 DB クラスターが最大 256 ACU までスケールアップできることを確認するための方法については、「256 ACU へのスケーリングを許可する Aurora Serverless v2 DB クラスターのアップグレード」を参照してください。

Aurora Serverless v2 では、容量範囲を変更せずに現在の容量を直接設定することはできません。容量は、指定範囲内のワークロードに基づいて動的に調整されるためです。ただし、次の方法で間接的に容量に影響を与えることができます。

容量範囲の影響と、容量範囲をモニタリング、微調整する方法については、「Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス」および「Aurora Serverless v2 でのパフォーマンスとスケーリング」を参照してください。目標は、ワークロードの急増時にはクラスターの容量を最大化し、クラスターがビジー状態でない場合は、コストを最小限に抑えるために容量を最小化することです。

モニタリングに基づき、クラスターの ACU の範囲を今よりも大きく、小さく、広く、狭くする必要があると判断したとします。AWS Management Console、AWS CLI、Amazon RDS により、Aurora クラスターの容量を ACU の特定の範囲に設定できます。この容量範囲は、クラスター内のすべての Aurora Serverless v2 DB インスタンスに適用されます。

例えば、クラスターの容量範囲が 1 ～ 16 ACU で、2 つの Aurora Serverless v2 DB インスタンスが含まれているとします。このとき、クラスター全体で 2 ACU (アイドル時) から 32 ACU (フル使用時) の間のどこかで消費されます。容量範囲を 8 から 40.5 ACU に変更すると、クラスター全体でアイドル時には 16 ACU を消費し、フル使用時には最大 81 ACU を消費します。

Aurora は Aurora Serverless v2 DB インスタンスの特定のパラメータを、容量範囲内の最大 ACU 値によって決定される値に自動的に設定します。このようなパラメータのリストについては、「Aurora Serverless v2 の最大接続数」を参照してください。このタイプの計算によって決定される静的パラメータの場合は、DB インスタンスを再起動すると、値が再評価されます。したがって、容量範囲を変更した後に DB インスタンスを再起動すれば、このようなパラメータの値を更新できます。このようなパラメータの変更を反映するために、DB インスタンスの再起動が必要かどうかを確認するには、DB インスタンスの ParameterApplyStatus 属性をチェックしてください。pending-reboot の値は、再起動によって一部のパラメータ値に変更が適用されることを示しています。

256 ACU へのスケーリングを許可する Aurora Serverless v2 DB クラスターのアップグレード

場合によっては、Aurora Serverless v2 DB クラスターを 128 ACU を超える容量にスケールしようとすると、エラーメッセージが表示されることがあります。エラーメッセージは、新しいスケーリング範囲と互換性のないインスタンスを示します。

128 を超える ACU をスケールできないのは、次の 2 つの理由のいずれかである可能性があります。

Aurora Serverless v2 の容量範囲の確認

Aurora Serverless v2 クラスターの容量範囲を確認する手順では、最初に容量範囲を設定する必要があります。まだ完了していない場合は、「Aurora Serverless v2 クラスターの容量設定」の手順に従ってください。

クラスターレベルで設定した容量範囲は、クラスター内のすべての Aurora Serverless v2 DB インスタンスに適用されます。以下のイメージは、複数の Aurora Serverless v2 DB インスタンスによるクラスターを示しています。それぞれ、同じ容量範囲を持っています。

クラスター内の Aurora Serverless v2 DB インスタンスの詳細ページを表示することもできます。DB インスタンスの容量範囲は、[Configuration] (設定) タブに表示されます。

また、クラスターの現在の容量範囲は、クラスターの [Modify] (変更) ページで確認できます。この時点で、容量範囲を変更できます。容量範囲の設定または変更が可能なすべての方法については、「Aurora Serverless v2 クラスターの容量設定」を参照してください。

Aurora クラスターの現在の容量範囲を確認する

クラスターの ServerlessV2ScalingConfiguration 属性を調べることで、クラスター内の Aurora Serverless v2 DB インスタンスに設定されている容量範囲を確認できます。以下の AWS CLI の例では、最小容量が 0.5 Aurora 容量単位 (ACU)、最大容量 16 ACU のクラスターを示しています。

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-64-acu-cluster \
  --query 'DBClusters[*].[ServerlessV2ScalingConfiguration]'
[
    [
        {
            "MinCapacity": 0.5,
            "MaxCapacity": 16.0
        }
    ]
]

Aurora Serverless v2 リーダーの追加

Aurora Serverless v2 リーダー DB インスタンスをクラスターに追加するには、「DB クラスターに Aurora レプリカを追加する」と同じ手順に従います。新しい DB インスタンスに Serverless v2 インスタンスクラスを選択する

クラスター内のリーダー DB インスタンスが最初の Aurora Serverless v2 DB インスタンスの場合は、容量範囲も選択します。この設定は、このリーダー DB インスタンスと、クラスターに追加する他の Aurora Serverless v2 DB インスタンスに適用されます。各 Aurora Serverless v2 DB インスタンスは、最小から最大の ACU 値の間でスケーリングできます。

クラスターに他の Aurora Serverless v2 インスタンスが既に存在する場合は、[リーダーの追加] ダイアログにクラスターの現在の容量範囲が表示されます。その場合、容量を変更することはできません。次の図は、現在のクラスター容量のレポートを示しています。

クラスターに既にいずれかの Aurora Serverless v2 DB インスタンスを追加している場合、別の Aurora Serverless v2 リーダー DB インスタンスには、現在の容量範囲が表示されます。以下のイメージは、これらの読み取り専用のコントロールを示しています。

クラスターの容量範囲を変更する場合は、「Aurora Serverless v2 クラスターの容量設定」の手順に従ってください。

複数のリーダー DB インスタンスを含むクラスターの場合は、各 Aurora Serverless v2 リーダー DB インスタンスのフェイルオーバーの優先度によって、その DB インスタンスのスケールアップとスケールダウンに重要な役割を果たします。最初にクラスターを作成するときに、優先度を指定することはできません。2 番目以降のリーダー DB インスタンスをクラスターに追加する場合は、この特性に注意してください。詳細については、「Aurora Serverless v2 リーダーの昇格階層の選択」を参照してください。

クラスターの現在の容量範囲を確認できるその他の方法については、「Aurora Serverless v2 の容量範囲の確認」を参照してください。

プロビジョン済みライターまたはリーダーを Aurora Serverless v2 に変換する

プロビジョン済み DB インスタンスを変換することで Aurora Serverless v2 を使用できます。これを行うには、「DB クラスター内の DB インスタンスの変更」の手順に従います。このクラスターは、「Aurora Serverless v2 の要件と制限」の要件を満たす必要があります。例えば Aurora Serverless v2 DB インスタンスでは、クラスターが特定の最小エンジンバージョンを実行している必要があります。

実行中のプロビジョン済みクラスターを変換して、Aurora Serverless v2 を利用するとします。その場合、切り替え処理の最初のステップとして、DB インスタンスを Aurora Serverless v2 に変換することで、ダウンタウンを最小限に抑えることができます。完全な手順については、「プロビジョニングされたクラスターから Aurora Serverless v2 への切り替え」を参照してください。

クラスター内で変換する DB インスタンスが最初の Aurora Serverless v2 DB インスタンスである場合、変更オペレーションの一部として、クラスターの容量範囲を選択します。この容量範囲は、クラスターに追加する各 Aurora Serverless v2 DB インスタンスに適用されます。以下のイメージは、最小および最大の Aurora 容量単位 (ACU) を指定するページを示しています。

容量範囲の重要性についての詳細は、「Aurora Serverless v2 の容量」を参照してください。

クラスターに既に 1 つまたは複数の Aurora Serverless v2 DB インスタンスが含まれている場合、変更オペレーションの際に既存の容量範囲が表示されます。以下のイメージは、その情報パネルの例を示しています。

Aurora Serverless v2 DB インスタンスを追加した後でクラスターの容量範囲を変更する場合は、「Aurora Serverless v2 クラスターの容量設定」の手順に従ってください。

Aurora Serverless v2 ライターまたはリーダーをプロビジョン済みに変換する

Aurora Serverless v2 DB インスタンスをプロビジョン済み DB インスタンスに変換できます。これを行うには、「DB クラスター内の DB インスタンスの変更」の手順に従います。[Serverless] (サーバーレス) 以外の DB インスタンスクラスを選択します。

Aurora Serverless v2 DB インスタンスが Aurora Serverless v2 DB インスタンスの最大 ACU (Aurora 容量単位) より大きな容量が必要な場合、プロビジョン済みに変換する場合があります。例えば、最大の db.r5 および db.r6g DB インスタンスクラスは、Aurora Serverless v2 DB インスタンスがスケーラブルな容量よりも大きなメモリ容量を持っています。

クラスターのライター DB インスタンスを Aurora Serverless v2 から プロビジョン済みに変換するには、逆順で「プロビジョニングされたクラスターから Aurora Serverless v2 への切り替え」の手順に従います。クラスター内のリーダー DB インスタンスの 1 つを Aurora Serverless v2 からプロビジョン済みに切り替えます。次に、フェイルオーバーを実行して、プロビジョン済み DB インスタンスをライターにします。

すべての Aurora Serverless v2 DB インスタンスをクラスターから削除した場合でも、以前にクラスターに指定した容量範囲はそのまま維持されます。容量範囲を変更する場合は、「Aurora Serverless v2 クラスターの容量設定」の説明に従って、クラスターを変更できます。

Aurora Serverless v2 DB インスタンスの一時停止

Aurora Serverless v2 DB インスタンスを自動的に一時停止および再開するように Aurora クラスターを設定できます。詳細については、「Aurora Serverless v2 の自動一時停止と再開によるゼロ ACU へのスケーリング」を参照してください。

Aurora Serverless v2 リーダーの昇格階層の選択

複数の Aurora Serverless v2 DB インスタンスを含むクラスター、またはプロビジョン済み Aurora Serverless v2 DB インスタンスが混在するクラスターでは、各 Aurora Serverless v2 DB インスタンスの昇格階層の設定に注意してください。この設定は、プロビジョン済み Aurora Serverless v2 DB インスタンスと比較して、DB インスタンスに対してより多くの動作をコントロールします。

AWS Management Console の [Create database] (データベースの作成)、[Modify instance] (インスタンスの変更)、[Add reader] (リーダーの追加) ページの [Additional configuration] (追加設定) で、[Failover priority] (フェイルオーバーの優先度) の選択肢を使用して、この設定を指定します。既存の DB インスタンスのこのプロパティについては、[Databases] (データベース) ページのオプションの [Priority tier] (優先階層) 列に表示されます。このプロパティは、DB クラスターまたは DB インスタンスの詳細ページにも表示されます。

プロビジョン済み DB インスタンスの場合、階層 0 ～ 15 の選択によって、フェイルオーバーオペレーション中に Aurora がどのリーダー DB インスタンスをライターに昇格させるかを選択する順序のみを決定します。Aurora Serverless v2 リーダー DB インスタンスの場合、ライター DB インスタンスの容量に合わせてスケールアップするか、インスタンスそのもののワークロードに応じて独自にスケールアップするかどうかは、階層番号で決まります。階層 0 または 1 の Aurora Serverless v2 リーダー DB インスタンスは、最低でもライター DB インスタンスと同じ容量に維持されます。これにより、フェイルオーバー発生時にライター DB インスタンスから引き継ぐ準備が整います。ライター DB インスタンスがプロビジョン済み DB インスタンスの場合、Aurora では同等の Aurora Serverless v2 容量を推定します。この推定値を Aurora Serverless v2リーダー DB インスタンスの最小容量として使用します。

階層 2 ～ 15 の Aurora Serverless v2 リーダー DB インスタンスは、最小容量に対する同じ制約はありません。アイドル状態の場合、クラスターの容量範囲で指定された Aurora 容量単位 (ACU) の最小値までスケールダウンできます。

以下の Linux AWS CLI の例は、クラスター内のすべての DB インスタンスの昇格階層を調べる方法を示しています。最後のフィールドには、ライター DB インスタンスの場合は True、すべてのリーダー DB インスタンスの場合は False の値が含まれています。

$ aws rds describe-db-clusters --db-cluster-identifier promotion-tier-demo \
  --query 'DBClusters[*].DBClusterMembers[*].[PromotionTier,DBInstanceIdentifier,IsClusterWriter]' \
  --output text

1   instance-192  True
1   tier-01-4840  False
10  tier-10-7425  False
15  tier-15-6694  False

以下の Linux AWS CLI の例は、クラスター内の特定の DB インスタンスの昇格階層を変更する方法を示しています。このコマンドでは、まず新しい昇格階層で DB インスタンスを変更します。その後、DB インスタンスが再び利用可能になるのを待って、DB インスタンスの新しい昇格階層を確認します。

$ aws rds modify-db-instance --db-instance-identifier instance-192 --promotion-tier 0
$ aws rds wait db-instance-available --db-instance-identifier instance-192
$ aws rds describe-db-instances --db-instance-identifier instance-192 \
  --query '*[].[PromotionTier]' --output text
0

さまざまなユースケースで昇格階層を指定する方法の詳細については、「Aurora Serverless v2 でのスケーリング」を参照してください。

Aurora Serverless v2 での TLS/SSL の使用

Aurora Serverless v2 では、クライアントと Aurora Serverless v2 DB インスタンス間の通信に対し、Transport Layer Security/Secure Sockets Layer (TLS/SSL) プロトコルを使用して暗号化することができます。サポートされる TLS/SSL バージョンは、1.0、1.1、および 1.2 です。Aurora での TLS/SSL の使用に関する一般的な情報については、「Aurora MySQL DB クラスターへの接続」を参照してください。

MySQL クライアントを使用しての Aurora MySQL データベースへの接続の詳細については、「MySQL データベースエンジンを実行している DB インスタンスへの接続」を参照してください。

Aurora Serverless v2 では、MySQL クライアント (mysql) および PostgreSQL クライアント (psql) で使用できるすべての TLS/SSL モードがサポートされます。これらには、以下の表に示すものも含まれます。

Aurora Serverless v2 は、ワイルドカード証明書を使用します。TLS/SSL を使用するときに "verify CA" または "verify CA and CA hostname" オプションを指定した場合は、まず Amazon ルート CA 1 信頼ストアを Amazon Trust Services からダウンロードしてください。ダウンロードした、この PEM 形式のファイルは、クライアントコマンドにより識別できます。これを PostgreSQL クライアントを使用して行うには、以下のように実行します。

Linux、macOS、Unix の場合:

psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'

Postgres クライアントを使用した Aurora PostgreSQL データベースの動作の詳細については、「PostgreSQL データベースエンジンを実行する DB インスタンスへの接続」を参照してください。

Aurora DB クラスターへの接続全般の詳細については、「Amazon Aurora DB クラスターへの接続」を参照してください。

Aurora Serverless v2 DB クラスターへの接続用にサポートされている暗号スイート

設定可能な暗号スイートを使用すると、データベース接続のセキュリティをより詳細に制御できます。データベースへのクライアント TLS/SSL 接続を保護するために許可する暗号スイートのリストを指定できます。設定可能な暗号スイートを使用すると、データベースサーバーが受け入れる接続暗号化を制御できます。これにより、安全でない暗号や使用されなくなった暗号の使用を防ぐことができます。

Aurora MySQL に基づく Aurora Serverless v2 DB クラスターは、Aurora MySQL プロビジョン済み DB クラスターと同じ暗号スイートをサポートします。これらの暗号スイートについては、「Aurora PostgreSQL DB クラスターへの接続用暗号スイートを設定する」を参照してください。

Aurora PostgreSQL に基づく DB クラスターは、Aurora PostgreSQL プロビジョンド DB クラスターと同じ暗号スイートをサポートします。これらの暗号スイートについては、「Aurora PostgreSQL DB クラスターへの接続用暗号スイートを設定する」を参照してください。

Aurora Serverless v2 ライターとライターの表示

プロビジョン済み DB インスタンスと同じ方法で、Aurora Serverless v2 DB インスタンスの詳細を表示できます。これを行うには、「Amazon Aurora DB クラスターの表示」の一般的な手順に従います。クラスターには、すべてまたは一部の Aurora Serverless v2 DB インスタンス、プロビジョン済み DB インスタンスが含まれる場合があります。

1 つまたは複数の Aurora Serverless v2 DB インスタンスを作成した場合、どの DB インスタンスがサーバーレスタイプで、どの DB インスタンスがインスタンスタイプであるかを確認できます。また、Aurora Serverless v2 DB インスタンスが使用可能な最小および最大の Aurora 容量単位 (ACU) を表示できます。各 ACU は、処理 (CPU) 容量とメモリ (RAM) 容量の組み合わせです。この容量範囲は、クラスター内の各 Aurora Serverless v2 DB インスタンスに適用されます。クラスターまたはクラスター内の任意の Aurora Serverless v2 DB インスタンスの容量範囲を確認する手順については、「Aurora Serverless v2 の容量範囲の確認」を参照してください。

AWS Management Console で、[Databases] (データベース) ページの [Size] (サイズ) 列に Aurora Serverless v2 DB インスタンスが表示されます。プロビジョン済み DB インスタンスには、r6g.xlarge などの DB インスタンスクラスの名前が表示されます。Aurora Serverless DB インスタンスでは、DB インスタンスクラスの場合は [Serverless] (サーバーレス)が、DB インスタンスの最小容量と最大容量と合わせて表示されます。例えば、Serverless v2 (4 ～ 64 ACU) または Serverless v2 (1 ～ 40 ACU) のように表示されます。

コンソールの各 Aurora Serverless v2 DB インスタンスの [Configuration] (設定) タブにも同じ情報が表示されます。例えば、以下のような [Instance type] (インスタンスタイプ) セクションが表示される場合があります。ここで、[Instance type] (インスタンスタイプ) の値を Serverless v2 とすると、最小容量の値は 2 ACU (4 GiB) で、最大容量の値は 64 ACU (128 GiB) です。

各 Aurora Serverless v2 DB インスタンスの容量は時系列でモニタリングできます。これにより、各 DB インスタンスが消費する ACU の最小、最大、平均を確認できます。また、DB インスタンスの最小容量または最大容量にどれだけ近づいたかを確認できます。これを AWS Management Console で見るには、DB インスタンスの [Monitoring] (モニタリング) タブで、Amazon CloudWatch メトリクスのグラフを確認します。注目すべきメトリクスと、それを解釈する方法の詳細については、「Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス」を参照してください。

Aurora Serverless v2 のログ記録

データベースのログをオンにするには、カスタムパラメータグループのコンフィギュレーションパラメータを使用して、有効にするログを指定します。

Aurora MySQL では、以下のログを有効にすることができます。

詳細については、「Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用」を参照してください。

Aurora PostgreSQL では、Aurora Serverless v2 DB インスタンスで以下のログを有効にできます。

Amazon CloudWatch でのログ記録

Aurora Serverless v2 のログ記録 の手順で、オンにするデータベースログを選択した後、Amazon CloudWatch にアップロード (公開) するログを選択できます。

Amazon CloudWatch を使用すると、ログデータの分析や、アラームの作成、メトリクスの表示を行うことができます。デフォルトでは、Aurora Serverless v2 のエラーログが有効になっており、CloudWatch に自動的にアップロードされます。また、その他の Aurora Serverless v2 DB インスタンスのログを CloudWatch アップロードできます。

次に、CloudWatch にアップロードするログを AWS Management Console の[Log exports] (ログのエクスポート) 設定または AWS CLI の --enable-cloudwatch-logs-exports オプションで選択します。

CloudWatch にアップロードする Aurora Serverless v2 ログを選択できます。詳細については、「Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用」を参照してください。

Aurora DB クラスターのタイプと同様に、デフォルトの DB クラスターパラメータグループを変更することはできません。代わりに、DB クラスターとエンジンタイプのデフォルトパラメータをベースに、独自の DB クラスターパラメータグループが作成できます。Aurora Serverless v2 DB クラスターを作成する前に、カスタムの DB クラスターパラメータグループを作成しておくことをお勧めします。これにより、コンソールでデータベースを作成するときに、パラメータグループを選択できるようになります。

Amazon CloudWatch の Aurora Serverless v2 ログの表示

「Amazon CloudWatch でのログ記録」の手順を使用してオンにするデータベースログを選択すると、ログの内容を表示できます。

CloudWatch、Aurora MySQL、Aurora PostgreSQL ログ使用の詳細については、「Amazon CloudWatch でログイベントをモニタリングする」および「Amazon CloudWatch Logs への Aurora PostgreSQL ログの発行」を参照してください。

Amazon CloudWatch でキャパシティーを監視する

Aurora Serverless v2では、CloudWatch を使用して、クラスター内のすべての Aurora Serverless v2 DB インスタンスの容量と使用率をモニタリングできます。インスタンスレベルのメトリクスを表示して、Aurora Serverless v2 DB インスタンスがスケールアップやスケールダウンした場合の容量を確認できます。また、容量に関連したメトリクスを他のメトリクスを比較することで、ワークロードの変化がリソース消費にどのように影響しているかを見ることもできます。例えば、ServerlessDatabaseCapacity と DatabaseUsedMemory、DatabaseConnections、DMLThroughput を比較すると、DB クラスターのオペレーション中の応答を評価できます。Aurora Serverless v2 に適用される容量に関連したメトリクスの詳細については、「Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス」を参照してください。

CloudWatch ダッシュボードをセットアップし、容量に関連したメトリクスを使用して Aurora Serverless v2 DB クラスターの容量をモニタリングすることをお勧めします。詳細については、「CloudWatch を使用したダッシュボードのビルド」を参照してください。

Amazon Aurora での Amazon CloudWatch の使用の詳細については、「Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行」を参照してください。

Aurora Serverless v2 の一時停止と再開アクティビティのモニタリング

Aurora は、自動一時停止が有効になっている Aurora Serverless v2 DB インスタンスに対して別のログファイルを作成します。Aurora は、インスタンスが一時停止されていない 10 分間隔ごとにログに書き込みます。Aurora は、これらのログを最大 7 つまで保持し、毎日ローテーションします。現在のログファイルには instance.log という名前が付けられ、古いログには instance.YYYY-MM-DD.N.log のパターンで名前が付けられます。

このログは、自動一時停止が有効になっている Aurora Serverless v2 DB インスタンスではデフォルトで有効になっています。このログの内容は、AWS Management Consoleで、あるいは AWS CLI または RDSP API を使用して表示できます。現在、このログを CloudWatch にアップロードすることはできません。

DB インスタンスイベント にリストされているイベントは、次のような一時停止と再開のアクティビティの概要を示します。

instance.log は、Aurora Serverless v2 インスタンスが一時停止できる/できない理由について、より詳細な情報を提供します。

ログには、さまざまな理由でインスタンスが再開されたことが示される場合があります。

Aurora は、自動一時停止間隔が経過したときにインスタンスの一時停止を妨げる条件を認識していない場合、定期的にログに情報メッセージを書き込みます。1 つの DB インスタンスだけを持つクラスターの場合、ログには次のメッセージが含まれます。

[INFO] No auto-pause blockers registered since time

複数の DB インスタンスを持つクラスターの場合、メッセージは若干異なります。これは、いずれかのリーダーインスタンスでアクティビティがあるため、ライターが一時停止できない可能性があるためです。ライターで自動一時停止間隔が経過する前にリーダーのアクティビティが終了すると、ライターは予定時間に一時停止できます。

[INFO] No auto-pause blockers registered since time.
Database might be required to maintain compute capacity for high availability.

一時停止オペレーションが開始し、インスタンスの一時停止が終了する前に新しいデータベース接続リクエストを受信した場合、ログには次のメッセージが含まれます。

[INFO] Unable to pause database due to a new database activity

Aurora がインスタンスの一時停止を確実に妨げる条件を認識すると、ログにはそうした条件すべてを一覧表示するこのメッセージが含まれます。

[INFO] Auto-pause blockers registered since time: list_of_conditions

そのため、Aurora は、自動一時停止機能と組み合わせて、レプリケーション、ゼロ ETL 統合、Aurora Global Database などを有効にすることを妨げません。このような機能を使用すると自動一時停止を有効にできない可能性がある場合は、ログで通知されます。

以下は、Aurora Serverless v2 インスタンスが自動一時停止タイムアウト間隔を経過しても一時停止できない理由を示しています。