Gestion des performances et dimensionnement des clusters de bases de données Aurora - Amazon Aurora
Dimensionnement du stockageMise à l'échelle d'instancesDimensionnement en lectureGestion des connexionsGestion des plans d'exécution de requêtes

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 :

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 et fiabilité d'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 :

    Aurora MySQL

    • Version 3 (compatible avec MySQL 8.0) : toutes versions prises en charge

    • Version 2 (compatible avec MySQL 5.7) : 2.11 et versions supérieures
    Aurora PostgreSQL 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. Ainsi, il s'applique aux instructions SQL telles que DROP TABLE, DROP DATABASE, TRUNCATE TABLE et ALTER 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'instruction Aurora MySQL OPTIMIZE TABLE ou l'extension Aurora PostgreSQL pg_repack par la suite afin de réorganiser la table et redimensionner dynamiquement le volume de 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 instructions SQL, 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. Par conséquent, assurez-vous de définir innodb_file_per_table sur 1 pour que les clusters de bases de données Aurora MySQL tirent 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'instruction SQL pertinente.

Le premier exemple renvoie la sortie au format JSON 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 données JSON dans un outil de mise en forme graphique pour effectuer des opérations de tri et de 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 paramètre -k de la commande sort trie la sortie sur le troisième champ, qui est l'horodatage au format UTC (Universal Coordinated Time).

$ 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 MySQL version 2.09 ou ultérieure, ou Aurora PostgreSQL, la taille libre indiquée par VolumeBytesUsed augmente quand des données sont ajoutées et diminue quand 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 avec un cluster exécutant Aurora MySQL version 2.09 ou ultérieure, ou Aurora PostgreSQL, la taille libre indiquée par AuroraVolumeBytesLeftTotal reflète la limite de taille de 128 Tio.

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

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 MySQL

Voir Nombre maximal de connexions à une instance de base de données Aurora MySQL

Amazon Aurora PostgreSQL

Consultez Nombre maximal de connexions à une instance de base de données Aurora PostgreSQL
Astuce

Si vos applications ouvrent et ferment fréquemment des connexions, ou si elles ont ouvert un grand nombre de connexions de longue durée, nous vous recommandons d'utiliser Proxy Amazon RDS. RDS Proxy est un proxy de base de données entièrement géré et hautement disponible 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 RDS Proxy, consultez Utilisation d'Amazon RDS Proxy pour Aurora.

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

Si vous utilisez la gestion des plans d'exécution de requêtes pour Aurora PostgreSQL, vous prenez le contrôle des plans exécutés par l'optimiseur. Pour plus d'informations, consultez Gestion des plans d'exécution de requêtes pour Aurora PostgreSQL.