Dimensionnement du stockage Mise à l'échelle d'instances Dimensionnement en lecture Gestion des connexions Gestion des plans d'exécution de requêtes

Gestion des performances et dimensionnement des clusters de bases de données Aurora

Vous pouvez utiliser les options suivantes pour gérer les performances et le dimensionnement des instances de bases de données et des clusters de bases de données Aurora :

Rubriques

Dimensionnement du stockage
Mise à l'échelle d'instances
Dimensionnement en lecture
Gestion des connexions
Gestion des plans d'exécution de requêtes

Dimensionnement du stockage

Le stockage Aurora procède à un dimensionnement automatique avec les données de votre volume de cluster. À mesure que vos données augmentent, le volume de stockage de votre cluster augmente jusqu'à un maximum de 128 téraoctets (Tio) ou 64 Tio. La taille maximale dépend de la version du moteur de base de données. Pour connaître le type des données incluses dans le volume de cluster, veuillez consulter Stockage Amazon Aurora. Pour plus d'informations sur la taille maximale d'une version spécifique, veuillez consulter Limites de taille Amazon Aurora.

La taille de votre volume de cluster est évaluée toutes les heures afin de déterminer vos coûts de stockage. Pour obtenir des informations sur la tarification, consultez la page de tarification Aurora.

Même si la taille d'un volume de cluster Aurora peut augmenter jusqu'à plusieurs tébioctets, vous n'êtes facturé que pour l'espace que vous utilisez dans le volume. Le mécanisme de détermination de l'espace de stockage facturé dépend de la version de votre cluster Aurora.

Lorsque des données Aurora sont supprimées du volume de cluster, l'espace facturé global diminue d'un montant comparable. Ce comportement de redimensionnement dynamique se produit lorsque des espaces de table sous-jacents sont supprimés ou réorganisés pour nécessiter moins d'espace. Ainsi, vous pouvez réduire les frais de stockage en supprimant les tables et les bases de données dont vous n'avez plus besoin. Le redimensionnement dynamique s'applique à certaines versions d'Aurora. Les versions suivantes sont les versions Aurora pour lesquelles le volume de cluster est redimensionné dynamiquement lorsque vous supprimez des données :

Moteur de base de données	Versions avec redimensionnement dynamique
Aurora My SQL	Version 3 (compatible avec My SQL 8.0) : toutes les versions prises en charge Version 2 (compatible avec My SQL 5.7) : 2.11 et versions ultérieures
Poster Aurora SQL	Toutes les versions prises en charge
Aurora Serverless v2	Toutes les versions prises en charge
Aurora Serverless v1	Toutes les versions prises en charge

Dans les versions d'Aurora inférieures à celles de la liste précédente, le volume du cluster peut réutiliser l'espace libéré lorsque vous supprimez des données, mais la taille du volume lui-même ne diminue jamais.
Cette fonctionnalité est déployée par étapes dans les AWS régions où Aurora est disponible. Selon la région où se trouve votre cluster, il se peut que cette fonction ne soit pas encore disponible.

Le redimensionnement dynamique s'applique aux opérations qui suppriment ou redimensionnent physiquement des espaces de table dans le volume de cluster. Elle s'applique donc aux SQL déclarations telles que DROP TABLEDROP DATABASE,TRUNCATE TABLE, etALTER TABLE ... DROP PARTITION. Il ne s'applique pas à la suppression de lignes à l'aide de l'instruction DELETE. Si vous supprimez un grand nombre de lignes d'une table, vous pouvez exécuter l'SQLOPTIMIZE TABLEinstruction Aurora My ou utiliser ensuite l'SQLpg_repackextension Aurora Postgre pour réorganiser la table et redimensionner dynamiquement le volume du cluster.

Pour Aurora MySQL, les considérations suivantes s'appliquent :

Une fois que vous avez mis à niveau votre cluster de base de données vers une version du moteur de base de données qui prend en charge le redimensionnement dynamique Région AWS, et lorsque la fonctionnalité est activée dans cette version spécifique, tout espace libéré ultérieurement par certaines SQL instructions, telles queDROP TABLE, est récupérable.

Si la fonctionnalité est explicitement désactivée dans un domaine en particulier Région AWS, l'espace peut uniquement être réutilisable, et non récupérable, même sur les versions qui prennent en charge le redimensionnement dynamique.

La fonctionnalité a été activée pour des versions spécifiques du moteur de base de données (1.23.0—1.23.4, 2.09.0—2.09.3 et 2.10.0) entre novembre 2020 et mars 2022, et est activée par défaut sur toutes les versions suivantes.
Une table est stockée en interne dans un ou plusieurs fragments contigus de différentes tailles. Pendant TRUNCATE TABLE les opérations en cours, l'espace correspondant au premier fragment est réutilisable et non récupérable. Les autres fragments sont récupérables. Pendant DROP TABLE les opérations, l'espace correspondant à l'ensemble du tablespace est récupérable.
Le innodb_file_per_table paramètre affecte la manière dont le stockage des tables est organisé. Lorsque les tables font partie de l'espace de tables système, la suppression de la table ne réduit pas la taille de l'espace de tables système. Assurez-vous donc de définir la valeur 1 innodb_file_per_table pour les clusters Aurora My SQL DB afin de tirer pleinement parti du redimensionnement dynamique.
Dans les versions 2.11 et supérieures, le tablespace temporaire InnoDB est supprimé et recréé au redémarrage. Cela libère l'espace occupé par l'espace de table temporaire vers le système, puis le volume du cluster est redimensionné. Pour tirer pleinement parti de la fonctionnalité de redimensionnement dynamique, nous vous recommandons de mettre à niveau votre cluster de base de données vers la version 2.11 ou supérieure.

Note

La fonctionnalité de redimensionnement dynamique ne permet pas de récupérer de l'espace immédiatement lorsque les tables des tablespaces sont supprimées, mais progressivement à un rythme d'environ 10 To par jour. L'espace disque logique du système n'est pas récupéré, car celui-ci n'est jamais supprimé. L'espace libre non récupéré dans un espace de table est réutilisé lorsqu'une opération a besoin d'espace dans cet espace de table. La fonctionnalité de redimensionnement dynamique peut récupérer de l'espace de stockage uniquement lorsque le cluster est dans un état disponible.

Vous pouvez vérifier la quantité d'espace de stockage utilisée par un cluster en surveillant la VolumeBytesUsed métrique utilisée CloudWatch. Pour plus d'informations sur la facturation du stockage, consultez Facturation du stockage des données Aurora.

Dans le AWS Management Console, vous pouvez voir cette figure dans un graphique en consultant l'Monitoringonglet de la page de détails du cluster.

Avec le AWS CLI, vous pouvez exécuter une commande similaire à l'exemple Linux suivant. Indiquez vos propres valeurs pour les heures de début et de fin, ainsi que pour le nom du cluster.


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_identifier

Le résultat de cette commande est semblable à ce qui suit.


{
    "Label": "VolumeBytesUsed",
    "Datapoints": [
        {
            "Timestamp": "2020-08-04T21:25:00+00:00",
            "Average": 182871982080.0,
            "Minimum": 182871982080.0,
            "Maximum": 182871982080.0,
            "Unit": "Bytes"
        }
    ]
}

Les exemples suivants montrent comment suivre l'utilisation du stockage d'un cluster Aurora au fil du temps à l'aide de AWS CLI commandes sur un système Linux. Les paramètres --start-time et --end-time définissent l'intervalle de temps global comme un jour. Le paramètre --period demande les métriques par intervalles d'une heure. Choisir une valeur --period faible n'a aucun sens, car les métriques sont collectées à intervalles réguliers, non en continu. En outre, les opérations de stockage Aurora se poursuivent parfois pendant un certain temps en arrière-plan après la fin de l'SQLinstruction correspondante.

Le premier exemple renvoie la sortie dans le JSON format par défaut. Les points de données sont renvoyés dans un ordre arbitraire, et non triés par horodatage. Vous pouvez importer ces JSON données dans un outil graphique pour effectuer le tri et la visualisation.


$ 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 ...

Cet exemple renvoie les mêmes données que le précédent. Le paramètre --output représente les données au format texte brut compact. La commande aws cloudwatch dirige sa sortie vers la commande sort. Le -k paramètre de la sort commande trie la sortie selon le troisième champ, qui est l'horodatage au format Universal Coordinated Time (UTC).


$ 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 3
VolumeBytesUsed
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 sortie triée indique la quantité de stockage utilisée au début et à la fin de la période de surveillance. Vous pouvez également trouver les points pendant cette période lorsqu'Aurora alloue plus de stockage pour le cluster. L'exemple suivant utilise des commandes Linux pour reformater les valeurs VolumeBytesUsed de début et de fin en gigaoctets (Go) et en gibioctets (GiO). Les gigaoctets représentent des unités mesurées en puissances de 10 et sont couramment utilisées dans les discussions sur le stockage pour des disques durs rotatifs. Les gibioctets représentent des unités mesurées en puissances de 2. Les mesures et limites de stockage Aurora sont généralement indiquées sous la forme d'unités de puissance de 2, telles que les gibioctets et les téraoctets.


$ 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étrique VolumeBytesUsed vous indique la quantité de stockage dans le cluster qui génère des frais. Il est donc préférable de réduire ce nombre lorsque c'est possible. Toutefois, cette métrique n'inclut pas le stockage utilisé en interne par Aurora dans le cluster et qui n'est pas facturé. Si votre cluster approche la limite de stockage et risque de manquer d'espace, il est conseillé de surveiller la métrique AuroraVolumeBytesLeftTotal et d'essayer d'augmenter ce nombre. L'exemple suivant exécute un calcul similaire au précédent, mais pour AuroraVolumeBytesLeftTotal au lieu 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 3
AuroraVolumeBytesLeftTotal
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

Pour un cluster exécutant Aurora My SQL version 2.09 ou ultérieure, ou Aurora PostgreSQL, la taille libre indiquée par Aurora My VolumeBytesUsed augmente lorsque des données sont ajoutées et diminue lorsque des données sont supprimées. L'exemple suivant montre comment procéder. Ce rapport indique la taille de stockage maximale et minimale d'un cluster par intervalles de 15 minutes lorsque des tables contenant des données temporaires sont créées et supprimées. Le rapport indique la valeur maximale avant la valeur minimale. Ainsi, pour comprendre comment l'utilisation du stockage a changée au cours de l'intervalle de 15 minutes, interprétez les chiffres de droite à gauche.


$ 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 4
VolumeBytesUsed
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

L'exemple suivant montre comment, dans le cas d'un cluster exécutant Aurora My SQL version 2.09 ou ultérieure, ou Aurora PostgreSQL, la taille libre indiquée par AuroraVolumeBytesLeftTotal reflète la limite de taille de 128 To.


$ 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 3
AuroraVolumeBytesLeftTotal
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

Mise à l'échelle d'instances

Vous pouvez mettre à l'échelle votre cluster de base de données Aurora en modifiant la classe d'instance de base de données pour chaque instance dans le cluster. Aurora prend en charge plusieurs classes d'instance de base de données optimisées pour Aurora, en fonction de la compatibilité du moteur de base de données.

Moteur de base de données	Mise à l'échelle d'instances
Amazon Aurora My SQL	Consultez Dimensionnement des instances de base de SQL données Aurora My.
Pochette Amazon Aurora SQL	Voir Dimensionnement des instances de SQL base de données Aurora Postgre

Dimensionnement en lecture

Vous pouvez réaliser le dimensionnement en lecture de votre cluster de base de données Aurora en créant jusqu'à 15 réplicas Aurora dans un cluster de base de données. Chaque réplica Aurora retourne les mêmes données du volume de cluster avec un retard de réplica minimal, généralement très inférieur à 100 ms, après que l'instance principale a écrit une mise à jour. Tandis que votre trafic en lecture augmente, vous pouvez créer des réplicas Aurora additionnels et vous y connecter directement pour répartir la charge de lecture de votre cluster de base de données. Les réplicas Aurora n'ont pas à être de la même classe d'instance de base de données que l'instance principale.

Pour plus d'informations sur l'ajout de réplicas Aurora à un cluster de bases de données, consultez Ajout de réplicas Aurora à un cluster de bases de données.

Gestion des connexions

Le nombre maximal de connexions autorisées à une instance de base de données Aurora est déterminé par le paramètre max_connections du groupe de paramètres de niveau instance de l'instance de base de données. La valeur par défaut de ce paramètre varie en fonction de la classe d'instance utilisée pour l'instance de base de données et de la compatibilité du moteur de bases de données.

Moteur de base de données	Valeur par défaut de max_connections
Amazon Aurora My SQL	Consultez Nombre maximal de connexions à une instance de base de SQL données Aurora My.
Pochette Amazon Aurora SQL	Consultez Nombre maximal de connexions à une instance de SQL base de données Aurora Postgre.

Astuce

Si vos applications ouvrent et ferment fréquemment des connexions, ou si elles maintiennent ouvertes un grand nombre de connexions de longue durée, nous vous recommandons d'utiliser Amazon RDS Proxy. RDSLe proxy est un proxy de base de données hautement disponible et entièrement géré qui utilise le regroupement de connexions pour partager les connexions de base de données de manière sécurisée et efficace. Pour en savoir plus sur le RDS proxy, consultezUtilisation d'Amazon RDS Proxy pour Aurora.

Gestion des plans d'exécution de requêtes

Si vous utilisez la gestion des plans de requêtes pour Aurora PostgreSQL, vous pouvez contrôler les plans exécutés par l'optimiseur. Pour de plus amples informations, veuillez consulter Gestion des plans d'exécution des requêtes pour Aurora Postgre SQL.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Supprimer une politique de dimensionnement automatique

Clonage d'un volume pour un cluster de bases de données Aurora