AWS AmazonRDS documentation change
Summary
Updated terminology from 'Aurora Serverless v2' to 'Aurora serverless' throughout the documentation. Minor wording adjustments in descriptions, examples, and section headers to reflect consistent naming.
Security assessment
The changes are purely terminological updates without introducing new security concepts, addressing vulnerabilities, or modifying security guidance. References to security-related parameters (e.g., max_connections) remain unchanged in their technical substance. No evidence of security incidents, patches, or weaknesses is present in the diff.
Diff
diff --git a/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.md b/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.md index 8547704ae..60ef5bf5f 100644 --- a//AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.md +++ b//AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.md @@ -7 +7 @@ -Choosing the capacity rangeWorking with parameter groups for Aurora Serverless v2Avoiding out-of-memory errorsImportant CloudWatch metricsMonitoring Aurora Serverless v2 performance with Performance InsightsTroubleshooting Aurora Serverless v2 capacity issues +Choosing the capacity rangeWorking with parameter groups for Aurora serverlessAvoiding out-of-memory errorsImportant CloudWatch metricsMonitoring Aurora serverless performance with Performance InsightsTroubleshooting Aurora serverless capacity issues @@ -9 +9 @@ Choosing the capacity rangeWorking with parameter groups for Aurora Serverless v -# Performance and scaling for Aurora Serverless v2 +# Performance and scaling for Aurora serverless @@ -11 +11 @@ Choosing the capacity rangeWorking with parameter groups for Aurora Serverless v -The following procedures and examples show how you can set the capacity range for Aurora Serverless v2 clusters and their associated DB instances. You can also use procedures following to monitor how busy your DB instances are. Then you can use your findings to determine if you need to adjust the capacity range upward or downward. +The following procedures and examples show how you can set the capacity range for Aurora serverless clusters and their associated DB instances. You can also use procedures following to monitor how busy your DB instances are. Then you can use your findings to determine if you need to adjust the capacity range upward or downward. @@ -13 +13 @@ The following procedures and examples show how you can set the capacity range fo -Before you use these procedures, make sure that you are familiar with how Aurora Serverless v2 scaling works. For details, see [Aurora Serverless v2 scaling](./aurora-serverless-v2.how-it-works.html#aurora-serverless-v2.how-it-works.scaling). +Before you use these procedures, make sure that you are familiar with how Aurora serverless scaling works. For details, see [Aurora serverless scaling](./aurora-serverless-v2.how-it-works.html#aurora-serverless-v2.how-it-works.scaling). @@ -17 +17 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Choosing the Aurora Serverless v2 capacity range for an Aurora cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-examples-setting-capacity-range-for-cluster) + * [Choosing the Aurora serverless capacity range for an Aurora cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-examples-setting-capacity-range-for-cluster) @@ -19 +19 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Choosing the minimum Aurora Serverless v2 capacity setting for a cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.min_capacity_considerations) + * [Choosing the minimum Aurora serverless capacity setting for a cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.min_capacity_considerations) @@ -21 +21 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Choosing the maximum Aurora Serverless v2 capacity setting for a cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.max_capacity_considerations) + * [Choosing the maximum Aurora serverless capacity setting for a cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.max_capacity_considerations) @@ -23 +23 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Example: Change the Aurora Serverless v2 capacity range of an Aurora MySQL cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams) + * [Example: Change the Aurora serverless capacity range of an Aurora MySQL cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams) @@ -25 +25 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Example: Change the Aurora Serverless v2 capacity range of an Aurora PostgreSQL cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg) + * [Example: Change the Aurora serverless capacity range of an Aurora PostgreSQL cluster](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg) @@ -27 +27 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Working with parameter groups for Aurora Serverless v2](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.parameter-groups) + * [Working with parameter groups for Aurora serverless](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.parameter-groups) @@ -31 +31 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Maximum connections for Aurora Serverless v2](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.max-connections) + * [Maximum connections for Aurora serverless](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.max-connections) @@ -33 +33 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Parameters that Aurora adjusts as Aurora Serverless v2 scales up and down](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.parameters-based-on-scaling) + * [Parameters that Aurora adjusts as Aurora serverless scales up and down](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.parameters-based-on-scaling) @@ -35 +35 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Parameters that Aurora computes based on Aurora Serverless v2 maximum capacity](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.parameters-based-on-max-capacity) + * [Parameters that Aurora computes based on Aurora serverless maximum capacity](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.parameters-based-on-max-capacity) @@ -39 +39 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Important Amazon CloudWatch metrics for Aurora Serverless v2](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.viewing.monitoring) + * [Important Amazon CloudWatch metrics for Aurora serverless](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.viewing.monitoring) @@ -41 +41 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [How Aurora Serverless v2 metrics apply to your AWS bill](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-billing) + * [How Aurora serverless metrics apply to your AWS bill](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-billing) @@ -43 +43 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Examples of CloudWatch commands for Aurora Serverless v2 metrics](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-cw-examples) + * [Examples of CloudWatch commands for Aurora serverless metrics](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2-cw-examples) @@ -45 +45 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Monitoring Aurora Serverless v2 performance with Performance Insights](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.viewing.performance-insights) + * [Monitoring Aurora serverless performance with Performance Insights](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.viewing.performance-insights) @@ -47 +47 @@ Before you use these procedures, make sure that you are familiar with how Aurora - * [Troubleshooting Aurora Serverless v2 capacity issues](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.troubleshooting) + * [Troubleshooting Aurora serverless capacity issues](./aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.troubleshooting) @@ -52 +52 @@ Before you use these procedures, make sure that you are familiar with how Aurora -## Choosing the Aurora Serverless v2 capacity range for an Aurora cluster +## Choosing the Aurora serverless capacity range for an Aurora cluster @@ -54 +54 @@ Before you use these procedures, make sure that you are familiar with how Aurora -With Aurora Serverless v2 DB instances, you set the capacity range that applies to all the DB instances in your DB cluster at the same time that you add the first Aurora Serverless v2 DB instance to the DB cluster. For the procedure to do so, see [Setting the Aurora Serverless v2 capacity range for a cluster](./aurora-serverless-v2-administration.html#aurora-serverless-v2-setting-acus). +With Aurora serverless DB instances, you set the capacity range that applies to all the DB instances in your DB cluster at the same time that you add the first Aurora serverless DB instance to the DB cluster. For the procedure to do so, see [Setting the Aurora serverless capacity range for a cluster](./aurora-serverless-v2-administration.html#aurora-serverless-v2-setting-acus). @@ -56 +56 @@ With Aurora Serverless v2 DB instances, you set the capacity range that applies -You can also change the capacity range for an existing cluster. The following sections discuss in more detail how to choose appropriate minimum and maximum values and what happens when you make a change to the capacity range. For example, changing the capacity range can modify the default values of some configuration parameters. Applying all the parameter changes can require rebooting each Aurora Serverless v2 DB instance. +You can also change the capacity range for an existing cluster. The following sections discuss in more detail how to choose appropriate minimum and maximum values and what happens when you make a change to the capacity range. For example, changing the capacity range can modify the default values of some configuration parameters. Applying all the parameter changes can require rebooting each Aurora serverless DB instance. @@ -60 +60 @@ You can also change the capacity range for an existing cluster. The following se - * Choosing the minimum Aurora Serverless v2 capacity setting for a cluster + * Choosing the minimum Aurora serverless capacity setting for a cluster @@ -62 +62 @@ You can also change the capacity range for an existing cluster. The following se - * Choosing the maximum Aurora Serverless v2 capacity setting for a cluster + * Choosing the maximum Aurora serverless capacity setting for a cluster @@ -64 +64 @@ You can also change the capacity range for an existing cluster. The following se - * Example: Change the Aurora Serverless v2 capacity range of an Aurora MySQL cluster + * Example: Change the Aurora serverless capacity range of an Aurora MySQL cluster @@ -66 +66 @@ You can also change the capacity range for an existing cluster. The following se - * Example: Change the Aurora Serverless v2 capacity range of an Aurora PostgreSQL cluster + * Example: Change the Aurora serverless capacity range of an Aurora PostgreSQL cluster @@ -71 +71 @@ You can also change the capacity range for an existing cluster. The following se -### Choosing the minimum Aurora Serverless v2 capacity setting for a cluster +### Choosing the minimum Aurora serverless capacity setting for a cluster @@ -73 +73 @@ You can also change the capacity range for an existing cluster. The following se -It's tempting to always choose 0.5 for the minimum Aurora Serverless v2 capacity setting. That value allows the DB instance to scale down to the smallest capacity when it's completely idle, while remaining active. You can also enable automatic pause behavior by specifying a minimum capacity of 0 ACUs, as explained in [Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2](./aurora-serverless-v2-auto-pause.html). However, depending on how you use that cluster and the other settings that you configure, a different minimum capacity might be the most effective. Consider the following factors when choosing the minimum capacity setting: +It's tempting to always choose 0.5 for the minimum Aurora serverless capacity setting. That value allows the DB instance to scale down to the smallest capacity when it's completely idle, while remaining active. You can also enable automatic pause behavior by specifying a minimum capacity of 0 ACUs, as explained in [Scaling to Zero ACUs with automatic pause and resume for Aurora serverless](./aurora-serverless-v2-auto-pause.html). However, depending on how you use that cluster and the other settings that you configure, a different minimum capacity might be the most effective. Consider the following factors when choosing the minimum capacity setting: @@ -75 +75 @@ It's tempting to always choose 0.5 for the minimum Aurora Serverless v2 capacity - * The scaling rate for an Aurora Serverless v2 DB instance depends on its current capacity. The higher the current capacity, the faster it can scale up. If you need the DB instance to quickly scale up to a very high capacity, consider setting the minimum capacity to a value where the scaling rate meets your requirement. + * The scaling rate for an Aurora serverless DB instance depends on its current capacity. The higher the current capacity, the faster it can scale up. If you need the DB instance to quickly scale up to a very high capacity, consider setting the minimum capacity to a value where the scaling rate meets your requirement. @@ -77 +77 @@ It's tempting to always choose 0.5 for the minimum Aurora Serverless v2 capacity - * If you typically modify the DB instance class of your DB instances in anticipation of especially high or low workload, you can use that experience to make a rough estimate of the equivalent Aurora Serverless v2 capacity range. To determine the memory size to use in times of low traffic, consult [Hardware specifications for DB instance classesfor Aurora](./Concepts.DBInstanceClass.Summary.html). + * If you typically modify the DB instance class of your DB instances in anticipation of especially high or low workload, you can use that experience to make a rough estimate of the equivalent Aurora serverless capacity range. To determine the memory size to use in times of low traffic, consult [Hardware specifications for DB instance classesfor Aurora](./Concepts.DBInstanceClass.Summary.html). @@ -79 +79 @@ It's tempting to always choose 0.5 for the minimum Aurora Serverless v2 capacity -For example, suppose that you use the db.r6g.xlarge DB instance class when your cluster has a low workload. That DB instance class has 32 GiB of memory. Thus, you can specify a minimum Aurora capacity unit (ACU) setting of 16 to set up an Aurora Serverless v2 DB instance that can scale down to approximately that same capacity. That's because each ACU corresponds to approximately 2 GiB of memory. You might specify a somewhat lower value to let the DB instance scale down further in case your db.r6g.xlarge DB instance was sometimes underutilized. +For example, suppose that you use the db.r6g.xlarge DB instance class when your cluster has a low workload. That DB instance class has 32 GiB of memory. Thus, you can specify a minimum Aurora capacity unit (ACU) setting of 16 to set up an Aurora serverless DB instance that can scale down to approximately that same capacity. That's because each ACU corresponds to approximately 2 GiB of memory. You might specify a somewhat lower value to let the DB instance scale down further in case your db.r6g.xlarge DB instance was sometimes underutilized. @@ -81 +81 @@ For example, suppose that you use the db.r6g.xlarge DB instance class when your - * If your application works most efficiently when the DB instances have a certain amount of data in the buffer cache, consider specifying a minimum ACU setting where the memory is large enough to hold the frequently accessed data. Otherwise, some data is evicted from the buffer cache when the Aurora Serverless v2 DB instances scale down to a lower memory size. Then when the DB instances scale back up, the information is read back into the buffer cache over time. If the amount of I/O to bring the data back into the buffer cache is substantial, it might be more effective to choose a higher minimum ACU value. + * If your application works most efficiently when the DB instances have a certain amount of data in the buffer cache, consider specifying a minimum ACU setting where the memory is large enough to hold the frequently accessed data. Otherwise, some data is evicted from the buffer cache when the Aurora serverless DB instances scale down to a lower memory size. Then when the DB instances scale back up, the information is read back into the buffer cache over time. If the amount of I/O to bring the data back into the buffer cache is substantial, it might be more effective to choose a higher minimum ACU value. @@ -83 +83 @@ For example, suppose that you use the db.r6g.xlarge DB instance class when your - * If your Aurora Serverless v2 DB instances run most of the time at a particular capacity, consider specifying a minimum capacity setting that's lower than that baseline, but not too much lower. Aurora Serverless v2 DB instances can most effectively estimate how much and how fast to scale up when the current capacity isn't drastically lower than the required capacity. + * If your Aurora serverless DB instances run most of the time at a particular capacity, consider specifying a minimum capacity setting that's lower than that baseline, but not too much lower. Aurora serverless DB instances can most effectively estimate how much and how fast to scale up when the current capacity isn't drastically lower than the required capacity. @@ -93 +93 @@ In particular, we recommend the following minimum capacity for use with the spec - * In Aurora, replication occurs at the storage layer, so reader capacity doesn't directly affect replication. However, for Aurora Serverless v2 reader DB instances that scale independently, make sure that the minimum capacity is sufficient to handle workloads during write-intensive periods to avoid query latency. If reader DB instances in promotion tiers 2–15 experience performance issues, consider increasing the cluster's minimum capacity. For details on choosing whether reader DB instances scale along with the writer or independently, see [Choosing the promotion tier for an Aurora Serverless v2 reader](./aurora-serverless-v2-administration.html#aurora-serverless-v2-choosing-promotion-tier). + * In Aurora, replication occurs at the storage layer, so reader capacity doesn't directly affect replication. However, for Aurora serverless reader DB instances that scale independently, make sure that the minimum capacity is sufficient to handle workloads during write-intensive periods to avoid query latency. If reader DB instances in promotion tiers 2–15 experience performance issues, consider increasing the cluster's minimum capacity. For details on choosing whether reader DB instances scale along with the writer or independently, see [Choosing the promotion tier for an Aurora serverless reader](./aurora-serverless-v2-administration.html#aurora-serverless-v2-choosing-promotion-tier). @@ -95 +95 @@ In particular, we recommend the following minimum capacity for use with the spec - * If you have a DB cluster with Aurora Serverless v2 reader DB instances, the readers don't scale along with the writer DB instance when the promotion tier of the readers isn't 0 or 1. In that case, setting a low minimum capacity can result in excessive replication lag. That's because the readers might not have enough capacity to apply changes from the writer when the database is busy. We recommend that you set the minimum capacity to a value that represents a comparable amount of memory and CPU to the writer DB instance. + * If you have a DB cluster with Aurora serverless reader DB instances, the readers don't scale along with the writer DB instance when the promotion tier of the readers isn't 0 or 1. In that case, setting a low minimum capacity can result in excessive replication lag. That's because the readers might not have enough capacity to apply changes from the writer when the database is busy. We recommend that you set the minimum capacity to a value that represents a comparable amount of memory and CPU to the writer DB instance. @@ -97 +97 @@ In particular, we recommend the following minimum capacity for use with the spec - * The value of the `max_connections` parameter for Aurora Serverless v2DB instances is based on the memory size derived from the maximum ACUs. However, when you specify a minimum capacity of 0 or 0.5 ACUs on PostgreSQL-compatible DB instances, the maximum value of `max_connections` is capped at 2,000. + * The value of the `max_connections` parameter for Aurora serverlessDB instances is based on the memory size derived from the maximum ACUs. However, when you specify a minimum capacity of 0 or 0.5 ACUs on PostgreSQL-compatible DB instances, the maximum value of `max_connections` is capped at 2,000. @@ -99 +99 @@ In particular, we recommend the following minimum capacity for use with the spec -If you intend to use the Aurora PostgreSQL cluster for a high-connection workload, consider using a minimum ACU setting of 1 or higher. For details about how Aurora Serverless v2 handles the `max_connections` configuration parameter, see Maximum connections for Aurora Serverless v2. +If you intend to use the Aurora PostgreSQL cluster for a high-connection workload, consider using a minimum ACU setting of 1 or higher. For details about how Aurora serverless handles the `max_connections` configuration parameter, see Maximum connections for Aurora serverless. @@ -101 +101 @@ If you intend to use the Aurora PostgreSQL cluster for a high-connection workloa - * The time it takes for an Aurora Serverless v2 DB instance to scale from its minimum capacity to its maximum capacity depends on the difference between its minimum and maximum ACU values. When the current capacity of the DB instance is large, Aurora Serverless v2 scales up in larger increments than when the DB instance starts from a small capacity. Thus, if you specify a relatively large maximum capacity and the DB instance spends most of its time near that capacity, consider increasing the minimum ACU setting. That way, an idle DB instance can scale back up to maximum capacity more quickly. + * The time it takes for an Aurora serverless DB instance to scale from its minimum capacity to its maximum capacity depends on the difference between its minimum and maximum ACU values. When the current capacity of the DB instance is large, Aurora serverless scales up in larger increments than when the DB instance starts from a small capacity. Thus, if you specify a relatively large maximum capacity and the DB instance spends most of its time near that capacity, consider increasing the minimum ACU setting. That way, an idle DB instance can scale back up to maximum capacity more quickly. @@ -106 +106 @@ If you intend to use the Aurora PostgreSQL cluster for a high-connection workloa -### Choosing the maximum Aurora Serverless v2 capacity setting for a cluster +### Choosing the maximum Aurora serverless capacity setting for a cluster @@ -108 +108 @@ If you intend to use the Aurora PostgreSQL cluster for a high-connection workloa -It's tempting to always choose some high value for the maximum Aurora Serverless v2 capacity setting. A large maximum capacity allows the DB instance to scale up the most when it's running an intensive workload. A low value avoids the possibility of unexpected charges. Depending on how you use that cluster and the other settings that you configure, the most effective value might be higher or lower than you originally thought. Consider the following factors when choosing the maximum capacity setting: +It's tempting to always choose some high value for the maximum Aurora serverless capacity setting. A large maximum capacity allows the DB instance to scale up the most when it's running an intensive workload. A low value avoids the possibility of unexpected charges. Depending on how you use that cluster and the other settings that you configure, the most effective value might be higher or lower than you originally thought. Consider the following factors when choosing the maximum capacity setting: @@ -114 +114 @@ It's tempting to always choose some high value for the maximum Aurora Serverless - * If you typically modify the DB instance class of your DB instances in anticipation of especially high or low workload, you can use that experience to estimate the equivalent Aurora Serverless v2 capacity range. To determine the memory size to use in times of high traffic, consult [Hardware specifications for DB instance classesfor Aurora](./Concepts.DBInstanceClass.Summary.html). + * If you typically modify the DB instance class of your DB instances in anticipation of especially high or low workload, you can use that experience to estimate the equivalent Aurora serverless capacity range. To determine the memory size to use in times of high traffic, consult [Hardware specifications for DB instance classesfor Aurora](./Concepts.DBInstanceClass.Summary.html). @@ -116 +116 @@ It's tempting to always choose some high value for the maximum Aurora Serverless -For example, suppose that you use the db.r6g.4xlarge DB instance class when your cluster has a high workload. That DB instance class has 128 GiB of memory. Thus, you can specify a maximum ACU setting of 64 to set up an Aurora Serverless v2 DB instance that can scale up to approximately that same capacity. That's because each ACU corresponds to approximately 2 GiB of memory. You might specify a somewhat higher value to let the DB instance scale up farther in case your db.r6g.4xlarge DB instance sometimes doesn't have enough capacity to handle the workload effectively. +For example, suppose that you use the db.r6g.4xlarge DB instance class when your cluster has a high workload. That DB instance class has 128 GiB of memory. Thus, you can specify a maximum ACU setting of 64 to set up an Aurora serverless DB instance that can scale up to approximately that same capacity. That's because each ACU corresponds to approximately 2 GiB of memory. You might specify a somewhat higher value to let the DB instance scale up farther in case your db.r6g.4xlarge DB instance sometimes doesn't have enough capacity to handle the workload effectively. @@ -118 +118 @@ For example, suppose that you use the db.r6g.4xlarge DB instance class when your - * If you have a budgetary cap on your database usage, choose a value that stays within that cap even if all your Aurora Serverless v2 DB instances run at maximum capacity all the time. Remember that when you have _n_ Aurora Serverless v2 DB instances in your cluster, the theoretical maximum Aurora Serverless v2 capacity that the cluster can consume at any moment is _n_ times the maximum ACU setting for the cluster. (The actual amount consumed might be less, for example if some readers scale independently from the writer.) + * If you have a budgetary cap on your database usage, choose a value that stays within that cap even if all your Aurora serverless DB instances run at maximum capacity all the time. Remember that when you have _n_ Aurora serverless DB instances in your cluster, the theoretical maximum Aurora serverless capacity that the cluster can consume at any moment is _n_ times the maximum ACU setting for the cluster. (The actual amount consumed might be less, for example if some readers scale independently from the writer.) @@ -120 +120 @@ For example, suppose that you use the db.r6g.4xlarge DB instance class when your - * If you make use of Aurora Serverless v2 reader DB instances to offload some of the read-only workload from the writer DB instance, you might be able to choose a lower maximum capacity setting. You do this to reflect that each reader DB instance doesn't need to scale as high as if the cluster contains only a single DB instance. + * If you make use of Aurora serverless reader DB instances to offload some of the read-only workload from the writer DB instance, you might be able to choose a lower maximum capacity setting. You do this to reflect that each reader DB instance doesn't need to scale as high as if the cluster contains only a single DB instance. @@ -126 +126 @@ For example, suppose that you use the db.r6g.4xlarge DB instance class when your - * If you turn on settings in your cluster that increase the memory usage for each DB instance, take that memory into account when deciding on the maximum ACU value. Such settings include those for Performance Insights, Aurora MySQL parallel queries, Aurora MySQL performance schema, and Aurora MySQL binary log replication. Make sure that the maximum ACU value allows the Aurora Serverless v2 DB instances to scale up enough to handle the workload when those feature are being used. For information about troubleshooting problems caused by the combination of a low maximum ACU setting and Aurora features that impose memory overhead, see Avoiding out-of-memory errors. + * If you turn on settings in your cluster that increase the memory usage for each DB instance, take that memory into account when deciding on the maximum ACU value. Such settings include those for Performance Insights, Aurora MySQL parallel queries, Aurora MySQL performance schema, and Aurora MySQL binary log replication. Make sure that the maximum ACU value allows the Aurora serverless DB instances to scale up enough to handle the workload when those feature are being used. For information about troubleshooting problems caused by the combination of a low maximum ACU setting and Aurora features that impose memory overhead, see Avoiding out-of-memory errors. @@ -131 +131 @@ For example, suppose that you use the db.r6g.4xlarge DB instance class when your -### Example: Change the Aurora Serverless v2 capacity range of an Aurora MySQL cluster +### Example: Change the Aurora serverless capacity range of an Aurora MySQL cluster @@ -133 +133 @@ For example, suppose that you use the db.r6g.4xlarge DB instance class when your -The following AWS CLI example shows how to update the ACU range for Aurora Serverless v2 DB instances in an existing Aurora MySQL cluster. Initially, the capacity range for the cluster is 8–32 ACUs. +The following AWS CLI example shows how to update the ACU range for Aurora serverless DB instances in an existing Aurora MySQL cluster. Initially, the capacity range for the cluster is 8–32 ACUs. @@ -291 +291 @@ We set the capacity range to 0.5–128 ACUs, and reboot the DB instance. Now the -### Example: Change the Aurora Serverless v2 capacity range of an Aurora PostgreSQL cluster +### Example: Change the Aurora serverless capacity range of an Aurora PostgreSQL cluster @@ -293 +293 @@ We set the capacity range to 0.5–128 ACUs, and reboot the DB instance. Now the -The following CLI examples show how to update the ACU range for Aurora Serverless v2 DB instances in an existing Aurora PostgreSQL cluster. +The following CLI examples show how to update the ACU range for Aurora serverless DB instances in an existing Aurora PostgreSQL cluster. @@ -310 +310 @@ The following figure shows the capacity changes in Amazon CloudWatch. - + @@ -439 +439 @@ At this point, the cluster is idle and the DB instance `serverless-v2-instance-1 -We reboot again, but the parameter values stay the same. This is because `max_connections` has a maximum value of 5000 for an Aurora Serverless v2 DB cluster running Aurora PostgreSQL. +We reboot again, but the parameter values stay the same. This is because `max_connections` has a maximum value of 5000 for an Aurora serverless DB cluster running Aurora PostgreSQL. @@ -469 +469 @@ Now we set the capacity range from 0.5 to 128 ACUs. The DB cluster scales down t -The `max_connections` value for Aurora Serverless v2 DB instances is based on the memory size derived from the maximum ACUs. However, when you specify a minimum capacity of 0 or 0.5 ACUs on PostgreSQL-compatible DB instances, the maximum value of `max_connections` is capped at 2,000. +The `max_connections` value for Aurora serverless DB instances is based on the memory size derived from the maximum ACUs. However, when you specify a minimum capacity of 0 or 0.5 ACUs on PostgreSQL-compatible DB instances, the maximum value of `max_connections` is capped at 2,000. @@ -486 +486 @@ Now we return the capacity to its initial range of 0.5–1 ACU and reboot the DB -## Working with parameter groups for Aurora Serverless v2 +## Working with parameter groups for Aurora serverless @@ -488 +488 @@ Now we return the capacity to its initial range of 0.5–1 ACU and reboot the DB -When you create your Aurora Serverless v2 DB cluster, you choose a specific Aurora DB engine and an associated DB cluster parameter group. If you aren't familiar with how Aurora uses parameter groups to apply configuration settings consistently across clusters, see [Parameter groups for Amazon Aurora](./USER_WorkingWithParamGroups.html). All of those procedures for creating, modifying, applying, and other actions for parameter groups apply to Aurora Serverless v2. +When you create your Aurora serverless DB cluster, you choose a specific Aurora DB engine and an associated DB cluster parameter group. If you aren't familiar with how Aurora uses parameter groups to apply configuration settings consistently across clusters, see [Parameter groups for Amazon Aurora](./USER_WorkingWithParamGroups.html). All of those procedures for creating, modifying, applying, and other actions for parameter groups apply to Aurora serverless. @@ -490 +490 @@ When you create your Aurora Serverless v2 DB cluster, you choose a specific Auro -The parameter group feature works generally the same between provisioned clusters and clusters containing Aurora Serverless v2 DB instances: +The parameter group feature works generally the same between provisioned clusters and clusters containing Aurora serverless DB instances: @@ -494 +494 @@ The parameter group feature works generally the same between provisioned cluster - * You can override some parameters for specific DB instances by specifying a custom DB parameter group for those DB instances. You might do so during debugging or performance tuning for specific DB instances. For example, suppose that you have a cluster containing some Aurora Serverless v2 DB instances and some provisioned DB instances. In this case, you might specify some different parameters for the provisioned DB instances by using a custom DB parameter group. + * You can override some parameters for specific DB instances by specifying a custom DB parameter group for those DB instances. You might do so during debugging or performance tuning for specific DB instances. For example, suppose that you have a cluster containing some Aurora serverless DB instances and some provisioned DB instances. In this case, you might specify some different parameters for the provisioned DB instances by using a custom DB parameter group. @@ -496 +496 @@ The parameter group feature works generally the same between provisioned cluster - * For Aurora Serverless v2, you can use all the parameters that have the value `provisioned` in the `SupportedEngineModes` attribute in the parameter group. + * For Aurora serverless, you can use all the parameters that have the value `provisioned` in the `SupportedEngineModes` attribute in the parameter group. @@ -505 +505 @@ The parameter group feature works generally the same between provisioned cluster - * Maximum connections for Aurora Serverless v2 + * Maximum connections for Aurora serverless @@ -507 +507 @@ The parameter group feature works generally the same between provisioned cluster - * Parameters that Aurora adjusts as Aurora Serverless v2 scales up and down + * Parameters that Aurora adjusts as Aurora serverless scales up and down @@ -509 +509 @@ The parameter group feature works generally the same between provisioned cluster - * Parameters that Aurora computes based on Aurora Serverless v2 maximum capacity + * Parameters that Aurora computes based on Aurora serverless maximum capacity @@ -516 +516 @@ The parameter group feature works generally the same between provisioned cluster -The crucial difference between provisioned DB instances and Aurora Serverless v2 DB instances is that Aurora overrides any custom parameter values for certain parameters that are related to DB instance capacity. The custom parameter values still apply to any provisioned DB instances in your cluster. For more details about how Aurora Serverless v2 DB instances interpret the parameters from Aurora parameter groups, see [Configuration parameters for Aurora clusters](./aurora-serverless-v2.how-it-works.html#aurora-serverless-v2.parameters). For the specific parameters that Aurora Serverless v2 overrides, see Parameters that Aurora adjusts as Aurora Serverless v2 scales up and down and Parameters that Aurora computes based on Aurora Serverless v2 maximum capacity. +The crucial difference between provisioned DB instances and Aurora serverless DB instances is that Aurora overrides any custom parameter values for certain parameters that are related to DB instance capacity. The custom parameter values still apply to any provisioned DB instances in your cluster. For more details about how Aurora serverless DB instances interpret the parameters from Aurora parameter groups, see [Configuration parameters for Aurora clusters](./aurora-serverless-v2.how-it-works.html#aurora-serverless-v2.parameters). For the specific parameters that Aurora serverless overrides, see Parameters that Aurora adjusts as Aurora serverless scales up and down and Parameters that Aurora computes based on Aurora serverless maximum capacity. @@ -518 +518 @@ The crucial difference between provisioned DB instances and Aurora Serverless v2 -You can get a list of default values for the default parameter groups for the various Aurora DB engines by using the [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) CLI command and querying the AWS Region. The following are values that you can use for the `--db-parameter-group-family` and `-db-parameter-group-name` options for engine versions that are compatible with Aurora Serverless v2. +You can get a list of default values for the default parameter groups for the various Aurora DB engines by using the [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) CLI command and querying the AWS Region. The following are values that you can use for the `--db-parameter-group-family` and `-db-parameter-group-name` options for engine versions that are compatible with Aurora serverless. @@ -529 +529 @@ Aurora PostgreSQL version 17.x | `aurora-postgresql17` | `default.aurora-postg -The following example gets a list of parameters from the default DB cluster group for Aurora MySQL version 3 and Aurora PostgreSQL 13. Those are the Aurora MySQL and Aurora PostgreSQL versions that you use with Aurora Serverless v2. +The following example gets a list of parameters from the default DB cluster group for Aurora MySQL version 3 and Aurora PostgreSQL 13. Those are the Aurora MySQL and Aurora PostgreSQL versions that you use with Aurora serverless. @@ -563 +563 @@ For Windows: -### Maximum connections for Aurora Serverless v2 +### Maximum connections for Aurora serverless @@ -565 +565 @@ For Windows: -For both Aurora MySQL and Aurora PostgreSQL, Aurora Serverless v2 DB instances hold the `max_connections` parameter constant so that connections aren't dropped when the DB instance scales down. The default value for this parameter is derived from a formula based on the memory size of the DB instance. For details about the formula and the default values for provisioned DB instance classes, see [Maximum connections to an Aurora MySQL DB instance](./AuroraMySQL.Managing.Performance.html#AuroraMySQL.Managing.MaxConnections) and [Maximum connections to an Aurora PostgreSQL DB instance](./AuroraPostgreSQL.Managing.html#AuroraPostgreSQL.Managing.MaxConnections). +For both Aurora MySQL and Aurora PostgreSQL, Aurora serverless DB instances hold the `max_connections` parameter constant so that connections aren't dropped when the DB instance scales down. The default value for this parameter is derived from a formula based on the memory size of the DB instance. For details about the formula and the default values for provisioned DB instance classes, see [Maximum connections to an Aurora MySQL DB instance](./AuroraMySQL.Managing.Performance.html#AuroraMySQL.Managing.MaxConnections) and [Maximum connections to an Aurora PostgreSQL DB instance](./AuroraPostgreSQL.Managing.html#AuroraPostgreSQL.Managing.MaxConnections). @@ -567 +567 @@ For both Aurora MySQL and Aurora PostgreSQL, Aurora Serverless v2 DB instances h -When Aurora Serverless v2 evaluates the formula, it uses the memory size based on the maximum Aurora capacity units (ACUs) for the DB instance, not the current ACU value. If you change the default value, we recommend using a variation of the formula instead of specifying a constant value. That way, Aurora Serverless v2 can use an appropriate setting based on the maximum capacity. +When Aurora serverless evaluates the formula, it uses the memory size based on the maximum Aurora capacity units (ACUs) for the DB instance, not the current ACU value. If you change the default value, we recommend using a variation of the formula instead of specifying a constant value. That way, Aurora serverless can use an appropriate setting based on the maximum capacity. @@ -569 +569 @@ When Aurora Serverless v2 evaluates the formula, it uses the memory size based o