Aurora Serverless v1 アーキテクチャ Auto Scaling タイムアウトアクション一時停止と再開最大接続数を確認するパラメータグループログ記録メンテナンスフェイルオーバースナップショット

Aurora Serverless v1 の働き

Aurora Serverless v1 がどのように機能しているのかがわかります。

トピック

Aurora Serverless v1 アーキテクチャ
Aurora Serverless v1 のオートスケーリング
容量の変更のタイムアウトアクション
Aurora Serverless v1 の一時停止と再開
Aurora Serverless v1 のデータベース接続の最大数を確認する
Aurora Serverless v1 のパラメータグループ
Aurora Serverless v1 のログ記録
Aurora Serverless v1 とメンテナンス
Aurora Serverless v1 とフェイルオーバー
Aurora Serverless v1 とスナップショット

Aurora Serverless v1 アーキテクチャ

次のイメージは、Aurora Serverless v1 アーキテクチャの概要を示しています。

データベースサーバーをプロビジョニングして管理する代わりに、Aurora 容量ユニット (ACU) を指定します。各 ACU では、約 2 GB (GB) のメモリ、対応する CPU、およびネットワーキングが組み合わせられています。データベースストレージは、自動的に 10 ギビバイト (GiB) から 128 tebibytes (TiB) にスケールします (スタンダード Aurora DB クラスターのストレージと同じです)。

最小と最大の ACU を指定できます。Aurora の最小容量ユニットは、DB クラスターをスケールダウンできる最小の ACU です。Aurora の最大容量ユニットは、DB クラスターをスケールアップできる最大の ACU です。設定に応じて、CPU 使用率、接続、および使用可能メモリの各しきい値に関するスケーリングルールが、Aurora Serverless v1 により自動的に作成されます。

Aurora Serverless v1 は、AWS リージョンのリソースのウォームプールを管理し、スケーリング時間を最小限に短縮します。Aurora Serverless v1 は、Aurora DB クラスターに新しいリソースを追加する際、ルーターフリートを使用してアクティブなクライアント接続を新しいリソースに切り替えます。いつの時点においても、Aurora DB クラスターで実際に使用している ACU 分のみ課金されます。

Aurora Serverless v1 のオートスケーリング

Aurora Serverless v1 DB クラスターに割り当てられる容量は、クライアントアプリケーションによって生成された負荷に対応して、シームレスに拡大および縮小されます。ここでは、負荷は CPU 使用率と接続数です。これらのいずれかによって容量が制約されると、Aurora Serverless v1 がスケールアップします。また、スケールアップすることで解決できるパフォーマンスの問題を検出すると、Aurora Serverless v1 もスケールアップします。

Aurora Serverless v1 で AWS Management Console クラスターのスケーリングイベントを表示できます。オートスケーリングの実行中に、Aurora Serverless v1 により、EngineUptime メトリクスがリセットされます。リセットメトリクス値の値は、シームレススケーリングに問題があったことを意味するものでも、Aurora Serverless v1 が接続を切断したことを意味するものでもありません。これは、新しい容量での稼働時間のスタート点に過ぎません。詳細については、「Amazon Aurora クラスターでのメトリクスのモニタリング」を参照してください。

Aurora Serverless v1 DB クラスターにアクティブな接続がない場合、容量ゼロ (0 ACU) にスケールダウンできます。詳細については、「Aurora Serverless v1 の一時停止と再開」を参照してください。

スケーリング操作を実行する必要がある場合は、Aurora Serverless v1 は初期にスケーリングポイントを特定しようとします。これは、クエリが処理されていない瞬間です。Aurora Serverless v1 は、次の理由により、スケーリングポイントを見つけることができない場合があります。

クエリの実行時間が長い
トランザクションが進行中である
テンポラリテーブルまたはテーブルがロックされている

スケーリングポイントを見つけるときに Aurora Serverless v1 DB クラスターの成功率を上げるには、長時間実行されるクエリや長時間実行されるトランザクションを回避することをお勧めします。スケーリングをブロックするオペレーションとそれらを回避する方法の詳細については、「Aurora Serverless v1 を使用するためのベストプラクティス」を参照してください。

デフォルトでは、Aurora Serverless v1 は、スケーリングポイントを 5 分 (300 秒) で見つけようとします。クラスターの作成時または変更時に、別のタイムアウト期間を指定できます。タイムアウト期間は、60 秒～10 分 (600 秒) の間で指定できます。Aurora Serverless v1 が、指定した期間以内にスケーリングポイントが見つからない場合、オートスケーリング操作がタイムアウトします。

デフォルトでは、オートスケーリングがタイムアウトする前にスケーリングポイントを見つけられない場合、Aurora Serverless v1 はクラスターを現在の容量で維持します。[Force the capacity change] (容量の変更を強制する) オプションを選択して Aurora Serverless v1 DB クラスターを作成または変更するときに、このデフォルトの動作を変更できます。詳細については、「容量の変更のタイムアウトアクション」を参照してください。

容量の変更のタイムアウトアクション

スケーリングポイントが見つからずにオートスケーリングがタイムアウトした場合、デフォルトでは Aurora は現在の容量を維持します。[Force the capacity change] (容量の変更を強制する) オプションを有効にすることで、Aurora で変更を強制することを選択できます。このオプションは、クラスターを作成するときに、[Create database] (データベースの作成) ページの [Autoscaling timeout and action] (オートスケーリングのタイムアウトとアクション) セクションで使用できます。

デフォルトでは、[Force the capacity change] (容量を強制的に変更する) オプションは選択解除されています。スケーリングポイントが見つからずにスケーリング操作がタイムアウトした場合に Aurora Serverless v1 DB クラスターの容量を変更しないようにするには、このオプションをオフのままにします。

このオプションを選択すると、Aurora Serverless v1 DB クラスターを使用して、スケーリングポイントがない場合でも、容量変更を強制します。このオプションを選択する前に、次の選択の結果に注意してください。

処理中のトランザクションはすべて中断され、次のエラーメッセージが表示されます。

Aurora MySQL バージョン 2 — ERROR 1105 (HY000): 最後のトランザクションがシームレススケーリングのため中止されました。もう一度試してください。

このトランザクションは、Aurora Serverless v1 DB クラスターが利用できるようになりしだい、再送信できます。
テンポラリテーブルとロックへの接続は削除されます。

アプリケーションが切断された接続または不完全なトランザクションから回復できる場合にのみ、[Force the capacity change] (容量を強制的に変更する) オプションを選択することをお勧めします。

Aurora Serverless v1 DB クラスターを作成するときに AWS Management Console で行った選択は、SecondsBeforeTimeout および TimeoutActionプロパティの ScalingConfigurationInfo オブジェクトに格納されます。クラスターを作成すると、TimeoutAction プロパティの値は次のいずれかの値に設定されます。

RollbackCapacityChange - この値は、[Roll back the capacity change] (容量の変更をロールバックする) オプションを選択したときに設定されます。これがデフォルトの動作です。
ForceApplyCapacityChange - この値は、[Force the capacity change] (容量の変更を強制する) オプションを選択したときに設定されます。

次に示すように、describe-db-clusters Aurora Serverless v1 コマンドを使用して、既存の AWS CLI DB クラスターでこのプロパティの値を取得できます。

Linux、macOS、Unix の場合:


aws rds describe-db-clusters --region region \
  --db-cluster-identifier your-cluster-name \
  --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

Windows の場合:


aws rds describe-db-clusters --region region ^
  --db-cluster-identifier your-cluster-name ^
  --query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"

例として、米国西部 (北カリフォルニア) リージョンにある、west-coast-sles という名前の Aurora Serverless v1 DB クラスターに対するクエリとその応答を次に示します。


$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles 
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

[
    {
        "ScalingConfigurationInfo": {
            "MinCapacity": 1,
            "MaxCapacity": 64,
            "AutoPause": false,
            "SecondsBeforeTimeout": 300,
            "SecondsUntilAutoPause": 300,
            "TimeoutAction": "RollbackCapacityChange"
        }
    }
]

応答が示すように、この Aurora Serverless v1 DB クラスターはデフォルト設定を使用しています。

詳細については、「Aurora Serverless v1 DB クラスターの作成」を参照してください。Aurora Serverless v1 を作成した後、タイムアウトアクションやその他の容量設定はいつでも変更できます。この方法については、「Aurora Serverless v1 DB クラスターの変更」を参照してください。

Aurora Serverless v1 の一時停止と再開

Aurora Serverless v1 DB クラスターでは、アクティビティなしの状態が一定時間継続した場合に、一時停止させるような設定が可能です。DB クラスターを一時停止するまでのアクティビティなしの時間を指定します。このオプションを選択すると、デフォルトの非アクティブ時間は 5 分ですが、この値は変更できます。これは任意の設定です。

DB クラスターを一時停止すると、コンピューティングまたはメモリのアクティビティが完全に停止し、ストレージに対してのみ課金されます。Aurora Serverless v1 DB クラスターの一時停止中にデータベース接続がリクエストされると、DB クラスターは自動的に再開して接続リクエストに対応します。

DB クラスターがアクティビティを再開すると、Aurora がクラスターを一時停止したときと同じ容量になります。ACU の数は、クラスターを一時停止する前に Aurora がスケールアップまたはスケールダウンした程度によって異なります。

注記

DB クラスターを一時停止してから 7 日間を超えると、DB クラスターはスナップショットからバックアップされる場合があります。この場合、接続要求がある場合、Aurora は DB クラスターをスナップショットから復元します。

Aurora Serverless v1 のデータベース接続の最大数を確認する

以下は、MySQL 5.7 との互換性がある Aurora Serverless v1 DB クラスターの例です。アクセスを設定している場合は、MySQL クライアントまたはクエリエディタを使用できます。詳細については、「クエリエディタでのクエリの実行」を参照してください。

許可されるデータベース接続の最大数を確認するため、

AWS CLI を使用する Aurora Serverless v1 DB クラスターの容量範囲を確認します。


aws rds describe-db-clusters \
    --db-cluster-identifier my-serverless-57-cluster \
    --query 'DBClusters[*].ScalingConfigurationInfo|[0]'

その結果、容量範囲が 1 ～ 4 ACU であることがわかりました。


{
    "MinCapacity": 1,
    "AutoPause": true,
    "MaxCapacity": 4,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

次の SQL クエリを実行して、接続の最大数を調べます。
```
select @@max_connections;
```
表示される結果は、クラスターの最小容量、つまり 1 ACU についてです。
```
@@max_connections
90
```
クラスターを 8 ～ 32 ACU にスケールします。

スケーリングの詳細については、「Aurora Serverless v1 DB クラスターの変更」を参照してください。

容量範囲を確認します。


{
    "MinCapacity": 8,
    "AutoPause": true,
    "MaxCapacity": 32,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

接続の最大数を確認します。
```
select @@max_connections;
```
表示される結果は、クラスターの最小容量、つまり 8 ACU についてです。
```
@@max_connections
1000
```
クラスターを可能な限り最大、つまり 256 ～ 256 ACU にスケールします。

容量範囲を確認します。


{
    "MinCapacity": 256,
    "AutoPause": true,
    "MaxCapacity": 256,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

接続の最大数を確認します。
```
select @@max_connections;
```
表示された結果は 256 ACU についてです。
```
@@max_connections
6000
```
注記
max_connections 値は ACU の数に合わせて直線的にスケールされません。

クラスターを 1 ～ 4 ACU にスケールダウンします。


{
    "MinCapacity": 1,
    "AutoPause": true,
    "MaxCapacity": 4,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

この場合、max_connections 値は 4 ACU です。


@@max_connections
270

クラスターを 2 つの ACU にスケールダウンさせます。
```
@@max_connections
180
```
一定時間アイドル状態になった後、クラスターを一時停止するように設定した場合は、0 ACU にスケールダウンします。ただし、max_connections が 1 ACU の値を下回ることはありません。
```
@@max_connections
90
```

Aurora Serverless v1 のパラメータグループ

Aurora Serverless v1 DB クラスターの作成時に、特定の Aurora DB エンジンと、それに関連する DB クラスターパラメータグループを選択します。プロビジョニングされた Aurora DB クラスターとは異なり、Aurora Serverless v1 DB クラスターには単一の読み取り/書き込み DB インスタンスがあり、DB クラスターパラメータグループで構成されているだけで、— 個別の DB パラメータグループはありません。オートスケーリング中、Aurora Serverless v1 は、容量の増減に対してクラスターが最適に機能するように、パラメータを変更できる必要があります。したがって、Aurora Serverless v1 DBクラスターでは、特定のDBエンジンタイプのパラメータに加える可能性のある変更の一部が適用されないことがあります。

例えば、Aurora PostgreSQL-ベースAurora Serverless v1の DB クラスターは、クエリプラン管理のためにプロビジョンド Aurora PostgreSQL DB クラスターで使用される可能性のある apg_plan_mgmt.capture_plan_baselines とその他のパラメータを使用できません。

CLI コマンドの describe-engine-default-cluster-parameters を使用し AWS リージョンに対しクエリすることで、さまざまな Aurora DB エンジンのデフォルトパラメータグループのデフォルト値のリストを取得できます。--db-parameter-group-family オプションに使用できる値は次のとおりです。

Aurora MySQL バージョン 2	`aurora-mysql5.7`
Aurora PostgreSQL バージョン 11	`aurora-postgresql11`
Aurora PostgreSQL バージョン 13	`aurora-postgresql13`

AWS アクセスキー ID と AWS シークレットアクセスキーを使用して AWS CLI を設定し、AWS CLI コマンドを使用する前に AWS リージョンを設定することをお勧めします。CLI 設定にリージョンを指定すると、コマンドの実行時に --region パラメータを入力する手間が省けます。AWS CLI の設定の詳細については、AWS Command Line Interface ユーザーガイドの「設定の基本」を参照してください。

次の例では、Aurora MySQL バージョン 2 のデフォルトの DB クラスターグループからパラメータのリストを取得します。

Linux、macOS、Unix の場合:


aws rds describe-engine-default-cluster-parameters \
  --db-parameter-group-family aurora-mysql5.7 --query \
  'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \
  --output text

Windows の場合:


aws rds describe-engine-default-cluster-parameters ^
   --db-parameter-group-family aurora-mysql5.7 --query ^
   "EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^
   --output text

Aurora Serverless v1 のパラメータ値の変更

Amazon Aurora のパラメータグループで説明したように、デフォルトのパラメータグループの値は、そのタイプ (DBクラスターパラメータグループ、DBパラメータグループ) に関係なく、直接変更することはできません。代わりに、Aurora DB エンジンのデフォルトの DB クラスターパラメータグループに基づいてカスタムパラメータグループを作成し、そのパラメータグループの設定を必要に応じて変更します。例えば、Aurora Serverless v1 DB クラスターの設定の一部を変更して、クエリをログに記録したり、DB エンジン固有のログを Amazon CloudWatch にアップロードしたりできます。

カスタム DB クラスターパラメータグループを作成するには

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[パラメータグループ] を選択します。
[パラメータグループの作成] をクリックして、パラメータグループの詳細ペインを開きます。
Aurora Serverless v1 DB クラスターに使用する DB エンジンに適切なデフォルト DB クラスターグループを選択します。必ず次のオプションを選択してください。
1. [パラメータグループファミリー] で、選択した DB エンジンに適したファミリを選択します。選択内容の名前には、aurora- プレフィックスが含まれていることを確認してください。
2. [Type] で、[DB Cluster Parameter Group] を選択します。
3. [グループ名] と [説明] に、ご自身や、Aurora Serverless v1 DB クラスターとそのパラメータを操作する必要がある他のユーザーにとって、わかりやすい名前を入力します。
4. [作成] を選択します。

カスタム DB クラスターパラメータグループが、お使いの AWS リージョンで使用できる、パラメータグループのリストに追加されます。これで、新しい Aurora Serverless v1 DB クラスターを作成する際に、このカスタムDB クラスターパラメータグループを使用できるようになります。カスタム DB クラスターパラメータグループが使用されように、既存の Aurora Serverless v1 DB クラスターを変更することもできます。ご使用の Aurora Serverless v1 DB クラスターがカスタム DB クラスターパラメータグループの使用をスタートしたら、AWS Management Console または AWS CLI を使用して動的パラメータの値を変更できます。

コンソールを使用して、次のスクリーンショットに示すように、カスタム DB クラスターパラメータグループの値をデフォルトの DB クラスターパラメータグループと比較した値を並べて表示することもできます。

Aurora MySQL 用の CloudWatch Logs、および Aurora PostgreSQL の Aurora Serverless v1 DB クラスターに公開されたログ

アクティブな DB クラスターのパラメータ値を変更すると、Aurora Serverless v1 は、パラメータの変更を適用するために、シームレスなスケーリングをスタートします。Aurora Serverless v1 DB クラスターは「一時停止」状態にあり、変更を行うことができるように再開してスケーリングをスタートします。パラメータグループ変更のスケーリング操作は常に容量の変更を強制するため、スケーリング期間中にスケーリングポイントが見つからない場合、パラメータを変更すると接続が切断される可能性があることに注意してください。

Aurora Serverless v1 のログ記録

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

Aurora MySQL について、以下の表は有効にできるログを示しています。有効にすると、Aurora Serverless v1 DB クラスターから Amazon CloudWatch に自動的にアップロードされます。

Aurora MySQL ログ	説明
`general_log`	一般ログを作成します。オンにするには、1 に設定します。デフォルトはオフ (0) です。
`log_queries_not_using_indexes`	インデックスを使用しないスロークエリログにクエリを記録します。デフォルトはオフ (0) です。このログを有効にするには、1 に設定します。
`long_query_time`	高速実行クエリがスロークエリログに記録されないようにします。0 から 3,1536,000 までの浮動小数点数に設定できます。デフォルトは 0 (アクティブではない) です。
`server_audit_events`	ログにキャプチャするイベントのリスト。サポートされている値は `CONNECT`、`QUERY`、`QUERY_DCL`、`QUERY_DDL`、`QUERY_DML`、`TABLE` です。
`server_audit_logging`	この値を 1 に設定すると、サーバー監査ログ記録がオンになります。これをオンにしている場合は、CloudWatch に送信する監査イベントを、`server_audit_events` パラメータにリストアップすることで指定できます。
`slow_query_log`	スロークエリログを作成します。スロークエリログをオンにするには、1 に設定します。デフォルトはオフ (0) です。

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

Aurora PostgreSQL について、以下の表は有効にできるログを示しています。有効にすると、通常のエラーログと一緒に Aurora Serverless v1 DB クラスターから Amazon CloudWatch に自動的にアップロードされます。

Aurora PostgreSQL ログ	説明
`log_connections`	デフォルトで有効になっており、変更できません。これは、すべての新しいクライアント接続の詳細をログに記録します。
`log_disconnections`	デフォルトで有効になっており、変更できません。クライアントの切断をすべてログに記録します。
`log_hostname`	デフォルトでオフになっており、変更できません。ホスト名はログに記録されません。
`log_lock_waits`	デフォルトは 0 (オフ) です。ロック待機をログに記録するには、1 に設定します。
`log_min_duration_statement`	ステートメントがログに記録されるまでに実行される最小時間 (ミリ秒単位)。
`log_min_messages`	ログに記録するメッセージレベルを設定します。サポートされている値は `debug5`、`debug4`、`debug3`、`debug2`、`debug1`、`info`、`notice`、`warning`、`error`、`log`、`fatal`、`panic` です。パフォーマンスデータを `postgres` ログに記録するには、値を `debug1` に設定します。
`log_temp_files`	指定されたキロバイト (KB) を超えるテンポラリファイルの使用を記録します。
`log_statement`	ログに記録される特定の SQL ステートメントを制御します。サポートされている値は `none`、`ddl`、`mod`、`all` です。デフォルトは `none` です。

Aurora Serverless v1 DB クラスターの Aurora MySQL または Aurora PostgreSQL のログをオンにすると、CloudWatch でログを表示できます。

Amazon CloudWatch を使用して Aurora Serverless v1 ログを表示する

Aurora Serverless v1 は DB クラスターのカスタムパラメータグループで有効になっているすべてのログを Amazon CloudWatch に自動的にアップロード (公開) します。ログの種類を選択または指定する必要はありません。ログのアップロードは、ログ設定パラメータを有効にするとすぐにスタートされます。後でログパラメータを無効にすると、それ以降のアップロードが停止します。ただし、既に CloudWatch に公開されているすべてのログは、削除するまで残ります。

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

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

Aurora Serverless v1 DB クラスターのログを表示するには

CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。
AWS リージョンを選択します。
[ロググループ] を選択します。
リストから Aurora Serverless v1 DB クラスターのログを選択します。エラーログの命名パターンは、次に従います。
```
/aws/rds/cluster/cluster-name/error
```

例えば、次のスクリーンショットでは、western-sles という名前の Aurora PostgreSQL Aurora Serverless v1 DB クラスターに対して公開されたログのリストを見つけることができます。また、Aurora MySQL Aurora Serverless v1 DB クラスター、west-coast-sles のリストもいくつか見つけることができます。目的のログを選択して、そのコンテンツの探索をスタートします。

Aurora Serverless v1 とメンテナンス

最新の機能、修正、セキュリティ更新の適用など、Aurora Serverless v1 DB クラスターのメンテナンスは自動的に実行されます。Aurora Serverless v1 にはメンテナンス期間があり、Aurora Serverless v1 DB クラスターの [メンテナンスとバックアップ] の AWS Management Console で確認できます。次の図に示すように、メンテナンスが実行される予定日時と、Aurora Serverless v1 DB クラスターで保留されているメンテナンスがあるかどうかが確認できます。

サンプルの Aurora Serverless v1 DB クラスターのメンテナンス期間の例、保留中のメンテナンスなし

メンテナンス期間は、Aurora Serverless v1 DB クラスターの作成時に設定でき、後で期間を変更できます。詳細については、「DB クラスターの適切なメンテナンスウィンドウの調整」を参照してください。

メンテナンス期間は、予定されたメジャーバージョンアップグレードに使用されます。マイナーバージョンのアップグレードとパッチは、スケーリング中に直ちに適用されます。スケーリングは、TimeoutAction の設定に従って行われます。

ForceApplyCapacityChange - 変更は直ちに適用されます。
RollbackCapacityChange - Aurora は最初のパッチ試行から 3 日後にクラスターを強制的に更新します。

適切なスケーリングポイント以外で強制される変更と同様に、この変更でもワークロードが中断されることがあります。

Aurora Serverless v1 は、可能な限り、中断せずに、メンテナンスを実行します。メンテナンスが実施される場合、Aurora Serverless v1 DB クラスターは必要な操作を処理するために容量をスケールアップします。スケーリングする前に、Aurora Serverless v1 はスケーリングポイントを探します。必要に応じて最大 3 日間行います。

Aurora Serverless v1 によりスケーリングポイントが見つけられない場合は、その 1 日の終わりにクラスターイベントが作成されます。このイベントは、保留中のメンテナンスについてと、メンテナンスを実行するためのスケーリングの必要性についてを通知します。通知には、Aurora Serverless v1 が DB クラスターを強制的にスケーリングを実行できる日付が含まれています。

詳細については、「容量の変更のタイムアウトアクション」を参照してください。

Aurora Serverless v1 とフェイルオーバー

Aurora Serverless v1 DB クラスターの DB インスタンスが使用不能になるか、そのクラスターがあるアベイラビリティーゾーン (AZ) で障害が発生した場合、Aurora は別の AZ に DB インスタンスを再作成します。ただし、Aurora Serverless v1 クラスターはマルチ AZ クラスターではありません。これは、単一の AZ 内の単一の DB インスタンスで構成されているためです。このフェイルオーバーメカニズムは、プロビジョニングされたインスタンスや Aurora Serverless v2 インスタンスを持つ Aurora クラスターよりも時間がかかります。Aurora Serverless v1 のフェイルオーバー時間は、対象の AWS リージョン内での、他の AZ の需要や利用可能な容量によって変動するため、定義されていません。

Aurora では、コンピューティング容量とストレージは分離されるため、クラスターのストレージボリュームは複数の AZ に分散されます。停止が DB インスタンスまたは関連する AZ に影響する場合でも、データは引き続き利用することができます。

Aurora Serverless v1 とスナップショット

Aurora Serverless v1 クラスターでは、クラスターボリュームは常に暗号化されます。暗号化キーは選択できますが、暗号化を無効にすることはできません。Aurora Serverless v1 クラスターのスナップショットをコピーまたは共有するには、独自の AWS KMS key を使用してスナップショットを暗号化します。詳細については、「DB クラスタースナップショットのコピー」を参照してください。暗号化と Amazon Aurora の詳細については、「Amazon Aurora DB クラスターの暗号化」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Aurora Serverless v1 を使用する

Aurora Serverless v1 DB クラスターの作成