Administración del rendimiento y el escalado para clústeres de base de datos Aurora
Puede utilizar las siguientes opciones para administrar el desempeño y el escalado de clústeres e instancias de bases de datos Aurora:
Temas
Escalado del almacenamiento
El almacenamiento de Aurora se escala automáticamente con los datos del volumen de clúster. A medida que los datos crecen, el volumen de almacenamiento del clúster se amplía hasta un máximo de 128 tebibytes (TiB) o 64 TiB. El tamaño máximo depende de la versión del motor de base de datos. Para obtener información sobre qué tipos de datos se incluyen en el volumen del clúster, consulte Almacenamiento de Amazon Aurora. Para obtener información detallada sobre el tamaño máximo de una versión específica, consulte Límites de tamaño de Amazon Aurora.
El tamaño del volumen de clúster se evalúa cada hora para determinar los costos de almacenamiento. Para obtener información sobre los precios, consulte la página de precios de Aurora
Aunque un volumen de clúster de Aurora puede aumentar en tamaño a muchos tebibytes, solo se le cobrará el espacio que utilice en el volumen. El mecanismo para determinar el espacio de almacenamiento facturado depende de la versión del clúster de Aurora.
-
Cuando se eliminan datos de Aurora del volumen del clúster, el espacio facturado general disminuye en una cantidad comparable. Este comportamiento dinámico de cambio de tamaño se produce cuando los espacios de tabla subyacentes se eliminan o se reorganizan para requerir menos espacio. De esta manera, podrá reducir los gastos de almacenamiento eliminando las tablas y bases de datos que ya no necesite. El cambio de tamaño dinámico se aplica a ciertas versiones de Aurora. Estas son las versiones de Aurora en las que el volumen del clúster cambia de tamaño dinámicamente a medida que se eliminan los datos:
Motor de base de datos Versiones con redimensionamiento dinámico Aurora MySQL -
Versión 3 (compatible con MySQL 8.0): todas las versiones admitidas
-
Versión 2 (compatible con MySQL 5.7): 2.11 y posteriores
Aurora PostgreSQL Todas las versiones compatibles Aurora Serverless v2 Todas las versiones compatibles Aurora Serverless v1 No disponible -
-
En versiones de Aurora anteriores a las de la lista anterior, el volumen del clúster puede reutilizar el espacio liberado al eliminar datos, pero el volumen en sí nunca disminuye de tamaño.
El cambio de tamaño dinámico se aplica a operaciones que eliminan o redimensionan físicamente los espacios de tablas dentro del volumen del clúster. Por lo tanto, se aplica a instrucciones SQL como DROP TABLE, DROP DATABASE, TRUNCATE TABLE y ALTER TABLE ... DROP PARTITION. No se aplica a la eliminación de filas utilizando la instrucción DELETE. Si elimina un gran número de filas de una tabla, puede ejecutar la instrucción OPTIMIZE TABLE de Aurora MySQL o utilizar después la extensión pg_repack de Aurora PostgreSQL para reorganizar la tabla y cambiar dinámicamente el volumen del clúster.
Para Aurora MySQL, se aplican los siguientes aspectos:
-
Tras actualizar el clúster de base de datos a una versión de motor de base de datos que admita el cambio de tamaño dinámico, y cuando la característica esté habilitada en esa Región de AWS específica, se podrá recuperar cualquier espacio que se libere posteriormente mediante determinadas instrucciones SQL, como
DROP TABLE.Si la característica está deshabilitada de forma explícita en una Región de AWS concreta, es posible que el espacio solo se pueda reutilizar (y no se pueda recuperar) incluso en versiones que admitan el cambio de tamaño dinámico.
La característica se habilitó para versiones específicas del motor de base de datos (1.23.0–1.23.4, 2.09.0–2.09.3 y 2.10.0) entre noviembre de 2020 y marzo de 2022, y está habilitada de forma predeterminada en todas las versiones posteriores.
-
Una tabla se almacena internamente en uno o más fragmentos contiguos de distintos tamaños. Mientras se ejecutan operaciones
TRUNCATE TABLE, el espacio correspondiente al primer fragmento se puede reutilizar y no se puede recuperar. Los demás fragmentos se pueden recuperar. Durante las operacionesDROP TABLE, se puede recuperar el espacio correspondiente a todo el espacio de la tabla. -
El parámetro
innodb_file_per_tableafecta a cómo se organiza el almacenamiento de tablas. Cuando las tablas forman parte del tablespace del sistema, la eliminación de la tabla no reduce el tamaño del tablespace del sistema. Por lo tanto, asegúrese establecerinnodb_file_per_tableen 1 para clústeres de base de datos de Aurora MySQL para aprovechar al máximo el cambio de tamaño dinámico. -
Para la versión 2.11 y versiones posteriores, el espacio de tablas temporal de InnoDB se elimina y se vuelve a crear al reiniciar. Esto libera al sistema el espacio ocupado por el espacio de tablas temporal y, a continuación, el volumen del clúster cambia de tamaño. Para aprovechar al máximo la característica de cambio de tamaño dinámico, le recomendamos que actualice su clúster de base de datos a la versión 2.11 o una versión posterior.
nota
La característica de cambio de tamaño dinámico no recupera espacio inmediatamente cuando se eliminan las tablas de los tablespaces, sino de forma gradual a un ritmo de aproximadamente 10 TB por día. El espacio en el espacio de tablas del sistema no se recupera porque el espacio de tablas del sistema nunca se elimina. El espacio libre no recuperado de un espacio de tablas se reutiliza cuando una operación necesita espacio en ese espacio de tablas. La característica de cambio de tamaño dinámico puede recuperar espacio de almacenamiento solo cuando el clúster tenga el estado disponible.
Puede comprobar cuánto espacio de almacenamiento está utilizando un clúster monitoreando la métrica VolumeBytesUsed en CloudWatch. Para obtener más información acerca de la facturación del almacenamiento, consulte Cómo se factura el almacenamiento de datos de Aurora.
-
En la AWS Management Console, puede ver esta cifra en un gráfico consultando la pestaña
Monitoringen la página de detalles del clúster. -
Con la AWS CLI, puede ejecutar un comando similar al siguiente ejemplo de Linux. Sustituya sus propios valores por las horas de inicio y finalización y el nombre del clúster.
aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '6 hours ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" \ --statistics Average Maximum Minimum \ --dimensions Name=DBClusterIdentifier,Value=my_cluster_identifierEl resultado de este comando debería ser similar al siguiente.
{ "Label": "VolumeBytesUsed", "Datapoints": [ { "Timestamp": "2020-08-04T21:25:00+00:00", "Average": 182871982080.0, "Minimum": 182871982080.0, "Maximum": 182871982080.0, "Unit": "Bytes" } ] }
Los siguientes ejemplos muestran cómo puede realizar un seguimiento del uso de almacenamiento de un clúster de Aurora a lo largo del tiempo mediante comandos de AWS CLI en un sistema Linux. Los parámetros --start-time y --end-time definen el intervalo de tiempo general como un día. El parámetro --period solicita las mediciones a intervalos de una hora. No tiene sentido elegir un valor de --period pequeño, porque las métricas se recopilan a intervalos, no de forma continua. Además, las operaciones de almacenamiento de Aurora a veces continúan durante algún tiempo en segundo plano después de que finalice la instrucción SQL pertinente.
El primer ejemplo devuelve la salida en el formato JSON predeterminado. Los puntos de datos se devuelven en orden arbitrario, no ordenados por marca de tiempo. Puede importar estos datos JSON en una herramienta de gráficos para ordenar y visualizar.
$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
--start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600
--namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id
{
"Label": "VolumeBytesUsed",
"Datapoints": [
{
"Timestamp": "2020-08-04T19:40:00+00:00",
"Maximum": 182872522752.0,
"Unit": "Bytes"
},
{
"Timestamp": "2020-08-05T00:40:00+00:00",
"Maximum": 198573719552.0,
"Unit": "Bytes"
},
{
"Timestamp": "2020-08-05T05:40:00+00:00",
"Maximum": 206827454464.0,
"Unit": "Bytes"
},
{
"Timestamp": "2020-08-04T17:40:00+00:00",
"Maximum": 182872522752.0,
"Unit": "Bytes"
},
... output omitted ...
Este ejemplo devuelve los mismos datos que el anterior. El parámetro --output representa los datos en formato de texto no cifrado compacto. El comando aws cloudwatch canaliza su salida al comando sort. El parámetro -k del comando sort ordena la salida por el tercer campo, que es la marca de hora en formato UTC (Tiempo universal coordinado).
$aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id\ --output text | sort -k 3VolumeBytesUsed DATAPOINTS 182872522752.0 2020-08-04T17:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T18:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T19:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T20:41:00+00:00 Bytes DATAPOINTS 187667791872.0 2020-08-04T21:41:00+00:00 Bytes DATAPOINTS 190981029888.0 2020-08-04T22:41:00+00:00 Bytes DATAPOINTS 195587244032.0 2020-08-04T23:41:00+00:00 Bytes DATAPOINTS 201048915968.0 2020-08-05T00:41:00+00:00 Bytes DATAPOINTS 205368492032.0 2020-08-05T01:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T02:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T03:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T04:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T05:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T06:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T07:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T08:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T09:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T10:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T11:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T12:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T13:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T14:41:00+00:00 Bytes DATAPOINTS 206833664000.0 2020-08-05T15:41:00+00:00 Bytes DATAPOINTS 206833664000.0 2020-08-05T16:41:00+00:00 Bytes
La salida ordenada muestra cuánto almacenamiento se utilizó al inicio y al final del período de monitoreo. También puede encontrar los puntos durante ese período cuando Aurora asigna más almacenamiento para el clúster. En el siguiente ejemplo se utilizan comandos Linux para volver a dar formato a los valores VolumeBytesUsed inicial y final como gigabytes (GB) y como gibibytes (GiB). Los gigabytes representan unidades medidas en potencias de 10 y se utilizan comúnmente en explicaciones sobre el almacenamiento de discos duros rotacionales. Gibibytes representan unidades medidas en potencias de 2. Las mediciones y los límites de almacenamiento de Aurora se indican normalmente en las unidades de potencia de 2, como gibibytes y tebibytes.
$GiB=$((1024*1024*1024))$GB=$((1000*1000*1000))$echo "Start: $((182872522752/$GiB)) GiB, End: $((206833664000/$GiB)) GiB"Start: 170 GiB, End: 192 GiB$echo "Start: $((182872522752/$GB)) GB, End: $((206833664000/$GB)) GB"Start: 182 GB, End: 206 GB
La métrica VolumeBytesUsed indica cuánto almacenamiento de información en el clúster está incurriendo en cargos. Por lo tanto, es mejor minimizar este número cuando resulte práctico. Sin embargo, esta métrica no incluye parte del almacenamiento que Aurora utiliza internamente en el clúster y que no cobra. Si el clúster se acerca al límite de almacenamiento y puede quedarse sin espacio, es más útil monitorear la métrica AuroraVolumeBytesLeftTotal e intentar maximizar ese número. En el ejemplo siguiente se ejecuta un cálculo similar al anterior, pero para AuroraVolumeBytesLeftTotal en lugar de VolumeBytesUsed.
$aws cloudwatch get-metric-statistics --metric-name "AuroraVolumeBytesLeftTotal" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_old_cluster_id\ --output text | sort -k 3AuroraVolumeBytesLeftTotal DATAPOINTS 140530528288768.0 2023-02-23T19:25:00+00:00 Count$TiB=$((1024*1024*1024*1024))$TB=$((1000*1000*1000*1000))$echo "$((69797067915264 / $TB)) TB remaining for this cluster"69 TB remaining for this cluster$echo "$((69797067915264 / $TiB)) TiB remaining for this cluster"63 TiB remaining for this cluster
Para un clúster que ejecute Aurora MySQL versión 2.09 o versiones posteriores, o Aurora PostgreSQL, el tamaño libre notificado por VolumeBytesUsed aumenta cuando se añaden datos y disminuye cuando se eliminan datos. El siguiente ejemplo muestra cómo. Este informe muestra el tamaño máximo y mínimo de almacenamiento de un clúster a intervalos de 15 minutos a medida que se crean y eliminan tablas con datos temporales. El informe muestra el valor máximo antes del valor mínimo. Por lo tanto, para comprender cómo cambió el uso del almacenamiento dentro del intervalo de 15 minutos, interprete los números de derecha a izquierda.
$aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \ --namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id--output text | sort -k 4VolumeBytesUsed DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T20:49:00+00:00 Bytes DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T21:19:00+00:00 Bytes DATAPOINTS 22022176768.0 14545305600.0 2020-08-05T21:49:00+00:00 Bytes DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:19:00+00:00 Bytes DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:49:00+00:00 Bytes DATAPOINTS 22022176768.0 15614263296.0 2020-08-05T23:19:00+00:00 Bytes DATAPOINTS 15614263296.0 15614263296.0 2020-08-05T23:49:00+00:00 Bytes DATAPOINTS 15614263296.0 15614263296.0 2020-08-06T00:19:00+00:00 Bytes
En el ejemplo siguiente, se muestra cómo con un clúster que ejecuta Aurora MySQL versión 2.09 o versiones posteriores, o Aurora PostgreSQL, el tamaño libre notificado por AuroraVolumeBytesLeftTotal refleja el límite de tamaño de 128 TiB.
$aws cloudwatch get-metric-statistics --region us-east-1 --metric-name "AuroraVolumeBytesLeftTotal" \ --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBClusterIdentifier,Value=pq-57 \ --output text | sort -k 3AuroraVolumeBytesLeftTotal DATAPOINTS 140515818864640.0 2020-08-05T20:56:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-05T21:26:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-05T21:56:00+00:00 Count DATAPOINTS 140514866757632.0 2020-08-05T22:26:00+00:00 Count DATAPOINTS 140511020580864.0 2020-08-05T22:56:00+00:00 Count DATAPOINTS 140503168843776.0 2020-08-05T23:26:00+00:00 Count DATAPOINTS 140503168843776.0 2020-08-05T23:56:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-06T00:26:00+00:00 Count$TiB=$((1024*1024*1024*1024))$TB=$((1000*1000*1000*1000))$echo "$((140515818864640 / $TB)) TB remaining for this cluster"140 TB remaining for this cluster$echo "$((140515818864640 / $TiB)) TiB remaining for this cluster"127 TiB remaining for this cluster
Escalado de instancia
Puede escalar el clúster de base de datos de Aurora como considere necesario modificando la clase de instancia de base de datos para cada instancia de base de datos del clúster de base de datos. Aurora admite varias clases de instancia de base de datos optimizadas para Aurora, dependiendo de la compatibilidad del motor de base de datos.
| Motor de base de datos | Escalado de instancia |
|---|---|
|
MySQL de Amazon Aurora |
Consulte Escalado de las instancias de base de datos Aurora MySQL |
|
PostgreSQL de Amazon Aurora |
Consulte Escalado de las instancias de base de datos Aurora PostgreSQL |
Escalado de lectura
Puede realizar el escalado de lectura de su clúster de base de datos de Aurora creando un máximo de 15 réplicas de Aurora en el clúster de base de datos. Cada réplica de Aurora devuelve los mismos datos desde el volumen de clúster con un retardo de réplica mínimo, normalmente mucho menos de 100 milisegundos una vez que la instancia principal ha escrito una actualización. A medida que el tráfico de lectura aumenta, puede crear réplicas de Aurora adicionales y conectarlas directamente para distribuir la carga de lectura del clúster de base de datos. Las réplicas de Aurora no tienen que ser de la misma clase de instancia de base de datos que la instancia principal.
Para obtener más información acerca de la adición de réplicas de Aurora a un clúster de base de datos, consulte Adición de réplicas de Aurora a un clúster de base de datos.
Administración de conexiones
El número máximo de conexiones permitidas a una instancia de base de datos Aurora viene determinado por el parámetro max_connections del grupo de parámetros de nivel de instancia para la instancia de base de datos. El valor predeterminado de dicho parámetro varía en función de la clase de instancia de base de datos utilizada para la instancia de base de datos y la compatibilidad del motor de base de datos.
| Motor de base de datos | Valor predeterminado de max_connections (máximo de conexiones) |
|---|---|
|
MySQL de Amazon Aurora |
Consulte Número máximo de conexiones a una instancia de base de datos Aurora MySQL |
|
PostgreSQL de Amazon Aurora |
Consulte Número máximo de conexiones a una instancia de base de datos Aurora PostgreSQL. |
sugerencia
Si sus aplicaciones abren y cierran conexiones con frecuencia, o mantienen abierto un gran número de conexiones de larga duración, le recomendamos que utilice Amazon RDS Proxy. El RDS Proxy es un proxy de base de datos totalmente administrado y de alta disponibilidad que utiliza agrupación de conexiones para compartir conexiones de base de datos de forma segura y eficiente. Para obtener más información acerca de RDS Proxy, consulteAmazon RDS Proxy para Aurora.
Administración de planes de ejecución de consultas
Si emplea una administración de planes de consultas para Aurora PostgreSQL obtiene control sobre qué planes ejecutará el optimizador. Para obtener más información, consulte Administración de planes de ejecución de consultas para Aurora PostgreSQL.
