Performances et évolutivité pour Aurora Serverless v2

Les procédures et exemples suivants montrent comment définir la plage de capacité pour Aurora Serverless v2 les clusters et leurs instances de base de données associées. Vous pouvez également utiliser les procédures suivantes pour surveiller le niveau d'occupation de vos instances de base de données. Vous pouvez ensuite utiliser vos résultats pour déterminer si vous devez augmenter ou réduire la plage de capacité.

Avant d'utiliser ces procédures, assurez-vous de savoir comment Aurora Serverless v2 le dimensionnement fonctionne. Le mécanisme de mise à l'échelle est différent de celui de Aurora Serverless v1. Pour plus de détails, voirAurora Serverless v2 mise à l'échelle.

Table des matières

• Choisir le Aurora Serverless v2 plage de capacité pour un cluster Aurora

  • Choisir le minimum Aurora Serverless v2 paramètre de capacité pour un cluster

  • Choisir le maximum Aurora Serverless v2 paramètre de capacité pour un cluster

  • Exemple : modifiez le Aurora Serverless v2 plage de capacité d'un cluster Aurora MySQL

  • Exemple : modifiez le Aurora Serverless v2 plage de capacité d'un cluster Aurora PostgreSQL

• Utilisation de groupes de paramètres pour Aurora Serverless v2

  • Valeurs des paramètres par défaut

  • Nombre maximum de connexions pour Aurora Serverless v2

  • Paramètres qu'Aurora ajuste Aurora Serverless v2 évolue vers le haut et vers le bas

  • Paramètres sur la base desquels Aurora calcule Aurora Serverless v2 capacité maximale

• Éviter les out-of-memory erreurs

• Statistiques Amazon CloudWatch importantes pour Aurora Serverless v2

  • Comment ? Aurora Serverless v2 les statistiques s'appliquent à votre AWS facture

  • Exemples de CloudWatch commandes pour Aurora Serverless v2 metrics

• Surveillance Aurora Serverless v2 performance avec Performance Insights

• Résolution des problèmes Aurora Serverless v2 problèmes de capacité

Choisir le Aurora Serverless v2 plage de capacité pour un cluster Aurora

Avec Aurora Serverless v2 Instances de base de données, vous définissez la plage de capacité qui s'applique à toutes les instances de base de données de votre cluster de base de données en même temps que vous ajoutez la première Aurora Serverless v2 Instance de base de données vers le cluster de base de données. Pour savoir comment procéder, consultez Réglage du Aurora Serverless v2 plage de capacité pour un cluster.

Vous pouvez également modifier la plage de capacité d'un cluster existant. Les sections suivantes expliquent plus en détail comment choisir les valeurs minimales et maximales appropriées et ce qui se passe lorsque vous modifiez la plage de capacité. Par exemple, la modification de la plage de capacité peut modifier les valeurs par défaut de certains paramètres de configuration. L'application de tous les changements de paramètres peut nécessiter le redémarrage de chacun Aurora Serverless v2 instance de base de données.

Rubriques

• Choisir le minimum Aurora Serverless v2 paramètre de capacité pour un cluster

• Choisir le maximum Aurora Serverless v2 paramètre de capacité pour un cluster

• Exemple : modifiez le Aurora Serverless v2 plage de capacité d'un cluster Aurora MySQL

• Exemple : modifiez le Aurora Serverless v2 plage de capacité d'un cluster Aurora PostgreSQL

Choisir le minimum Aurora Serverless v2 paramètre de capacité pour un cluster

Il est tentant de toujours choisir 0,5 comme minimum Aurora Serverless v2 réglage de capacité. Cette valeur permet à l'instance de base de données de réduire sa capacité au minimum lorsqu'elle est complètement inactive, tout en restant active. Vous pouvez également activer le comportement de pause automatique en spécifiant une capacité minimale de 0 ACUs, comme expliqué dansMise à l'échelle jusqu'à zéro ACUs avec pause et reprise automatiques pour Aurora Serverless v2. Toutefois, en fonction de la manière dont vous utilisez ce cluster et des autres paramètres que vous configurez, une capacité minimale différente peut s'avérer la plus efficace. Tenez compte des facteurs suivants lors du choix de la valeur minimale de capacité :

• Le taux de mise à l'échelle d'un Aurora Serverless v2 L'instance de base de données dépend de sa capacité actuelle. Plus sa capacité actuelle est élevée, plus son augmentation d'échelle est rapide. Si vous avez besoin d'augmenter rapidement l'échelle de l'instance de base de données jusqu'à une capacité très élevée, envisagez de définir la capacité minimale sur une valeur où le taux de mise à l’échelle satisfait à vos exigences.

• Si vous modifiez généralement la classe d'instance de base de données de vos instances de base de données en prévision d'une charge de travail particulièrement élevée ou faible, vous pouvez utiliser cette expérience pour faire une estimation approximative de l'équivalent Aurora Serverless v2 plage de capacité. Pour déterminer la taille de mémoire à utiliser en période de faible trafic, consultez Spécifications matérielles pour les classes d'instance de base de données pour Aurora.

  Par exemple, supposons que vous utilisiez la classe d'instance de base de données db.r6g.xlarge lorsque la charge de travail de votre cluster est faible. Cette classe d'instance de base de données dispose de 32 Gio de mémoire. Ainsi, vous pouvez spécifier un paramètre d'unité de capacité Aurora (ACU) minimum de 16 pour configurer un Aurora Serverless v2 Instance de base de données qui peut être réduite à peu près à la même capacité. En effet, chaque ACU correspond à environ 2 Gio de mémoire. Vous pouvez spécifier une valeur légèrement inférieure pour prolonger la réduction d'échelle de l'instance de base de données au cas où votre instance de base de données db.r6g.xlarge soit parfois sous-exploitée.

• Si votre application fonctionne le plus efficacement lorsque les instances de base de données contiennent une certaine quantité de données dans le cache de mémoire tampon, envisagez de spécifier un nombre d'ACU minimal pour lequel la mémoire est suffisamment volumineuse pour contenir les données fréquemment consultées. Dans le cas contraire, certaines données sont expulsées du cache tampon lorsque Aurora Serverless v2 Les instances de base de données sont réduites à une taille de mémoire inférieure. Ensuite, lorsque les instances de base de données font à nouveau l'objet d'une augmentation d'échelle, les informations sont relues dans le cache de mémoire tampon au fil du temps. Si la quantité d'E/S nécessaire pour remettre les données dans le cache de mémoire tampon est importante, il peut être plus efficace de choisir un nombre minimal d'ACU plus élevé.

• Si vos recettes Aurora Serverless v2 Les instances de base de données s'exécutent la plupart du temps à une capacité particulière. Pensez à spécifier un paramètre de capacité minimale inférieur à cette base de référence, mais pas trop bas. Aurora Serverless v2 peuvent estimer le plus efficacement dans quelle mesure et avec quelle rapidité procéder à l'augmentation d'échelle lorsque la capacité actuelle n'est pas nettement inférieure à la capacité requise.

• Si votre charge de travail approvisionnée présente des exigences en mémoire trop élevées pour les petites classes d'instance de base de données telles que T3 ou T4g, choisissez un nombre minimal d'ACU qui fournit une quantité de mémoire comparable à une instance de base de données R5 ou R6g.

  Nous recommandons particulièrement d'utiliser la capacité minimale suivante avec les fonctionnalités spécifiées (ces recommandations peuvent être modifiées) :

  • Informations sur les Performances — 2 ACUs

  • Bases de données globales Aurora — 8 ACUs (s'applique uniquement à la base Région AWS)

• Dans Aurora, la réplication s'effectue au niveau de la couche de stockage, de sorte que la capacité du lecteur n'affecte pas directement la réplication. Cependant, pour Aurora Serverless v2 les instances de base de données de lecture qui évoluent indépendamment garantissent que la capacité minimale est suffisante pour gérer les charges de travail pendant les périodes d'écriture intensive afin d'éviter la latence des requêtes. Si les instances de base de données de lecteur des niveaux de promotion 2 à 15 rencontrent des problèmes de performances, envisagez d'augmenter la capacité minimale du cluster. Pour savoir comment choisir si les instances de base de données de lecteur sont mises à l'échelle en même temps que l'enregistreur ou indépendamment, consultez Choix du niveau de promotion pour un Aurora Serverless v2 lecteur.

• Si vous avez un cluster de base de données avec Aurora Serverless v2 instances de base de données de lecteur, les lecteurs ne s'adaptent pas à l'instance de base de données d'écriture lorsque le niveau de promotion des lecteurs n'est pas de 0 ou 1. Dans ce cas, la définition d'une valeur minimale de capacité faible peut entraîner un retard de réplication excessif. En effet, la capacité des lecteurs peut ne pas être suffisante pour appliquer les modifications depuis l'enregistreur lorsque la base de données est occupée. Nous vous recommandons de définir la capacité minimale sur une valeur représentant une quantité de mémoire et de processeur comparable à celle de l'instance de base de données Writer.

• La valeur du max_connections paramètre pour Aurora Serverless v2Les instances de base de données sont basées sur la taille de mémoire dérivée du maximum ACUs. Toutefois, lorsque vous spécifiez une capacité minimale de 0 ou 0,5 ACUs sur des instances de base de données compatibles avec PostgreSQL, la valeur maximale de max_connections est plafonnée à 2 000.

  Si vous avez l'intention d'utiliser le cluster Aurora PostgreSQL pour une charge de travail à connexion élevée, envisagez d'utiliser un nombre minimal d'ACU de 1 ou plus. Pour plus de détails sur la façon dont Aurora Serverless v2 gère le paramètre max_connections de configuration, voirNombre maximum de connexions pour Aurora Serverless v2.

• Le temps qu'il faut pour une Aurora Serverless v2 La mise à l'échelle d'une instance de base de données entre sa capacité minimale et sa capacité maximale dépend de la différence entre ses valeurs ACU minimale et maximale. Lorsque la capacité actuelle de l'instance de base de données est importante, Aurora Serverless v2 augmente par incréments plus importants que lorsque l'instance de base de données démarre à partir d'une faible capacité. Par conséquent, si vous spécifiez une capacité maximale relativement élevée et que l'instance de base de données se rapproche la plupart du temps de cette capacité, envisagez d'augmenter le nombre minimal d'ACU. De cette façon, une instance de base de données inactive peut rétablir sa capacité maximale plus rapidement.

Choisir le maximum Aurora Serverless v2 paramètre de capacité pour un cluster

Il est tentant de toujours choisir une valeur élevée pour le maximum Aurora Serverless v2 réglage de capacité. Une capacité maximale élevée permet à l'instance de base de données de faire l'objet d'une augmentation d'échelle maximale lorsqu'elle exécute une charge de travail exigeant beaucoup de ressources. Une valeur faible évite la possibilité de frais inattendus. Selon votre utilisation de ce cluster et des autres paramètres que vous configurez, la valeur la plus efficace peut être supérieure ou inférieure à celle à laquelle vous pensiez initialement. Tenez compte des facteurs suivants lors du choix de la valeur maximale de capacité :

• La capacité maximale doit être au moins aussi élevée que la capacité minimale. Vous pouvez définir la capacité minimale et la capacité maximale pour qu'elles soient identiques. Cependant, dans ce cas, la capacité ne fait jamais l'objet d'une augmentation ou d'une réduction d'échelle. Par conséquent, l'utilisation de valeurs identiques pour les capacités minimale et maximale n'est pas appropriée en dehors des situations de test.

• La capacité maximale doit être supérieure à 0,5 ACUs. Vous pouvez définir la capacité minimale et la capacité maximale pour qu'elles soient identiques dans la plupart des cas. Toutefois, vous ne pouvez pas spécifier 0,5 à la fois pour les capacités minimale et maximale. Utilisez une valeur supérieure ou égale à 1 pour la capacité maximale.

• Si vous modifiez généralement la classe d'instance de base de données de vos instances de base de données en prévision d'une charge de travail particulièrement élevée ou faible, vous pouvez utiliser cette expérience pour estimer l'équivalent Aurora Serverless v2 plage de capacité. Pour déterminer la taille de mémoire à utiliser en période de trafic élevé, consultez Spécifications matérielles pour les classes d'instance de base de données pour Aurora.

  Par exemple, supposons que vous utilisiez la classe d'instance de base de données db.r6g.4xlarge lorsque la charge de travail de votre cluster est élevée. Cette classe d'instance de base de données dispose de 128 Gio de mémoire. Ainsi, vous pouvez spécifier un paramètre ACU maximal de 64 pour configurer un Aurora Serverless v2 Instance de base de données pouvant atteindre approximativement la même capacité. En effet, chaque ACU correspond à environ 2 Gio de mémoire. Vous pouvez spécifier une valeur légèrement supérieure pour prolonger l'augmentation d'échelle de l'instance de base de données au cas où votre instance de base de données db.r6g.4xlarge manque parfois de capacité pour gérer efficacement la charge de travail.

• Si vous avez un plafond budgétaire pour l'utilisation de votre base de données, choisissez une valeur qui reste dans les limites de ce plafond, même si tous vos Aurora Serverless v2 Les instances de base de données fonctionnent en permanence à leur capacité maximale. N'oubliez pas que lorsque vous avez n Aurora Serverless v2 Instances de base de données de votre cluster, maximum théorique Aurora Serverless v2 la capacité que le cluster peut consommer à tout moment est n fois le paramètre ACU maximal pour le cluster. (La quantité réelle consommée peut être inférieure, par exemple si certains lecteurs sont mis à l'échelle indépendamment de l'enregistreur.)

• Si vous utilisez Aurora Serverless v2 instances de base de données de lecteur Pour décharger une partie de la charge de travail en lecture seule de l'instance de base de données d'écriture, vous pouvez peut-être choisir un paramètre de capacité maximale inférieur. Cela permet de refléter que chaque instance de base de données de lecteur n'a pas besoin de faire l'objet d'une mise à l’échelle aussi importante que si le cluster ne contenait qu'une seule instance de base de données.

• Supposons que vous souhaitiez vous protéger contre une utilisation excessive due à une mauvaise configuration des paramètres de base de données ou à l'inefficacité des requêtes de votre application. Dans ce cas, vous pouvez éviter une surutilisation accidentelle en choisissant une valeur maximale de capacité inférieure à la valeur absolue la plus élevée que vous pourriez définir.

• Si les pics dus à l'activité réelle de l'utilisateur sont rares mais existent, vous pouvez les prendre en compte lorsque vous choisissez la valeur maximale de capacité. Si la priorité est que l'application continue de s'exécuter à des performances et une capacité de mise à l’échelle optimales, vous pouvez spécifier une valeur maximale de capacité supérieure à celle que vous constatez dans le cas d'une utilisation normale. S'il est admis que l'application s'exécute à un débit réduit pendant les pics d'activité très élevés, vous pouvez choisir une valeur maximale de capacité légèrement inférieure. Assurez-vous de choisir une valeur dont les ressources de mémoire et de processeur sont suffisantes pour maintenir l'application en cours d'exécution.

• Si vous activez les paramètres de votre cluster qui augmentent l'utilisation de la mémoire pour chaque instance de base de données, tenez compte de cette mémoire lorsque vous choisissez le nombre maximal d'ACU. Ces paramètres incluent les paramètres de Performance Insights, les requêtes parallèles Aurora MySQL, le schéma de performances Aurora MySQL et la réplication des journaux binaires Aurora MySQL. Assurez-vous que la valeur ACU maximale permet Aurora Serverless v2 Les instances de base de données doivent être suffisamment évolutives pour gérer la charge de travail lorsque ces fonctionnalités sont utilisées. Pour plus d'informations sur le dépannage des problèmes provoqués par la combinaison d'un nombre maximal d'ACU faible et de fonctionnalités Aurora qui imposent une surcharge de mémoire, consultez Éviter les out-of-memory erreurs.

Exemple : modifiez le Aurora Serverless v2 plage de capacité d'un cluster Aurora MySQL

L' AWS CLI exemple suivant montre comment mettre à jour la plage ACU pour Aurora Serverless v2 Instances de base de données dans un cluster Aurora MySQL existant. Au départ, la plage de capacités du cluster est comprise entre 8 ACUs et 32.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}

L'instance de base de données est inactive et réduite à 8 ACUs. Les paramètres de capacité suivants s'appliquent à l'instance de base de données à ce stade. Pour représenter la taille du groupe de mémoires tampons en unités facilement lisibles, nous la divisons par 2 puissance 30, ce qui donne une mesure en gibioctets (Gio). En effet, les mesures liées à la mémoire pour Aurora utilisent des unités basées sur des puissances de 2 et non des puissances de 10.

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                9294577664 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|   8.65625 |
+-----------+
1 row in set (0.00 sec)

Ensuite, nous modifions la plage de capacité du cluster. Une fois la commande modify-db-cluster terminée, la plage d'ACU du cluster est comprise entre 12,5 et 80.

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}

La modification de la plage de capacité a modifié les valeurs par défaut de certains paramètres de configuration. Aurora peut appliquer immédiatement certaines de ces nouvelles valeurs par défaut. Cependant, certaines modifications de paramètre ne prennent effet qu'après un redémarrage. Le statut pending-reboot indique qu'un redémarrage est nécessaire pour appliquer certaines modifications de paramètre.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}

À ce stade, le cluster est inactif et l'instance de base de données serverless-v2-instance-1 consomme 12,5 ACUs. Le paramètre innodb_buffer_pool_size est déjà ajusté en fonction de la capacité actuelle de l'instance de base de données. Le paramètre max_connections reflète toujours la valeur de l'ancienne capacité maximale. La réinitialisation de cette valeur exige de redémarrer l'instance de base de données.

Note

Si vous définissez le max_connections paramètre directement dans un groupe de paramètres de base de données personnalisé, aucun redémarrage n'est nécessaire.

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               15572402176 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+---------------+
| gibibytes     |
+---------------+
| 14.5029296875 |
+---------------+
1 row in set (0.00 sec)

À présent, nous redémarrons l'instance de base de données et nous attendons qu'elle soit de nouveau disponible.

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

L'état pending-reboot est effacé. La valeur in-sync confirme qu'Aurora a appliqué l'ensemble des modifications de paramètre en attente.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}

Le paramètre innodb_buffer_pool_size a augmenté jusqu'à sa taille finale pour une instance de base de données inactive. Le paramètre max_connections a augmenté pour refléter une valeur dérivée du nombre maximal d'ACU. La formule utilisée par Aurora pour max_connections entraîne une augmentation de 1 000 lorsque la taille de mémoire double.

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               16139681792 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|  15.03125 |
+-----------+
1 row in set (0.00 sec)

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              4000 |
+-------------------+
1 row in set (0.00 sec)

Nous définissons la plage de capacité entre 0,5 et 128 ACUs et redémarrons l'instance de base de données. À présent, l'instance de base de données inactive a une taille de cache de mémoire tampon inférieure à 1 Gio. Nous la mesurons donc en mébioctets (Mio). La valeur 5 000 de max_connections est dérivée de la taille de mémoire du paramètre de capacité maximale.

mysql> select @@innodb_buffer_pool_size / pow(2,20) as mebibytes, @@max_connections;
+-----------+-------------------+
| mebibytes | @@max_connections |
+-----------+-------------------+
|       672 |              5000 |
+-----------+-------------------+
1 row in set (0.00 sec)

Exemple : modifiez le Aurora Serverless v2 plage de capacité d'un cluster Aurora PostgreSQL

Les exemples de CLI suivants montrent comment mettre à jour la plage ACU pour Aurora Serverless v2 Instances de base de données dans un cluster Aurora PostgreSQL existant.

1. La plage de capacité du cluster commence entre 0,5 et 1 ACU.

2. Modifiez la plage de capacité sur 8—32. ACUs

3. Modifiez la plage de capacité sur 12,5 à 80. ACUs

4. Modifiez la plage de capacité sur 0,5 à 128. ACUs

5. Ramenez la capacité à sa plage initiale de 0,5 à 1 ACU.

La figure suivante montre les changements de capacité sur Amazon CloudWatch.

L'instance de base de données est inactive et réduite à 0,5 ACUs. Les paramètres de capacité suivants s'appliquent à l'instance de base de données à ce stade.

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

Ensuite, nous modifions la plage de capacité du cluster. Une fois la commande modify-db-cluster terminée, la plage ACU pour le cluster est de 8 à 32.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}

La modification de la plage de capacité modifie les valeurs par défaut de certains paramètres de configuration. Aurora peut appliquer immédiatement certaines de ces nouvelles valeurs par défaut. Cependant, certaines modifications de paramètre ne prennent effet qu'après un redémarrage. Le statut pending-reboot indique qu'un redémarrage est nécessaire pour appliquer certaines modifications de paramètre.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}

À ce stade, le cluster est inactif et l'instance serverless-v2-instance-1 de base de données consomme 8.0 ACUs. Le paramètre shared_buffers est déjà ajusté en fonction de la capacité actuelle de l'instance de base de données. Le paramètre max_connections reflète toujours la valeur de l'ancienne capacité maximale. La réinitialisation de cette valeur exige de redémarrer l'instance de base de données.

Note

Si vous définissez le max_connections paramètre directement dans un groupe de paramètres de base de données personnalisé, aucun redémarrage n'est nécessaire.

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)

Nous redémarrons l'instance de base de données et nous attendons qu'elle soit de nouveau disponible.

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

Maintenant que l'instance de base de données est redémarrée, le statut pending-reboot est effacé. La valeur in-sync confirme qu'Aurora a appliqué l'ensemble des modifications de paramètre en attente.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}

Après le redémarrage, max_connections indique la valeur de la nouvelle capacité maximale.

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)

Ensuite, nous modifions la plage de capacité du cluster de 12,5 à 80. ACUs

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}

À ce stade, le cluster est inactif et l'instance de base de données serverless-v2-instance-1 consomme 12,5 ACUs. Le paramètre shared_buffers est déjà ajusté en fonction de la capacité actuelle de l'instance de base de données. La valeur max_connections est toujours de 5 000.

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

Nous redémarrons à nouveau, mais les valeurs des paramètres restent les mêmes. Cela est dû au fait qu'il max_connections a une valeur maximale de 5 000 pour un Aurora Serverless v2 Cluster de base de données exécutant Aurora PostgreSQL.

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

Nous définissons maintenant la plage de capacité de 0,5 à 128 ACUs. Le cluster de base de données est réduit à 10 ACUs, puis à 2. Nous redémarrons l'instance de base de données.

postgres=> show max_connections;
 max_connections
-----------------
 2000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

La max_connections valeur de Aurora Serverless v2 Les instances de base de données sont basées sur la taille de mémoire dérivée du maximum ACUs. Toutefois, lorsque vous spécifiez une capacité minimale de 0 ou 0,5 ACUs sur des instances de base de données compatibles avec PostgreSQL, la valeur maximale de max_connections est plafonnée à 2 000.

Maintenant, nous remettons la capacité à sa plage initiale de 0,5 0 1 ACU et nous redémarrons l'instance de base de données. Le paramètre max_connections a retrouvé sa valeur d'origine.

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

Utilisation de groupes de paramètres pour Aurora Serverless v2

Lorsque vous créez votre Aurora Serverless v2 Cluster de base de données, vous choisissez un moteur de base de données Aurora spécifique et un groupe de paramètres de cluster de base de données associé. Si vous n'êtes pas familier avec la façon dont Aurora utilise les groupes de paramètres pour appliquer les paramètres de configuration de manière cohérente entre les clusters, consultez Groupes de paramètres pour Amazon Aurora (). Toutes ces procédures de création, de modification, d'application et d'autres actions relatives aux groupes de paramètres s'appliquent à Aurora Serverless v2.

La fonctionnalité de groupe de paramètres fonctionne généralement de la même manière entre les clusters provisionnés et les clusters contenant Aurora Serverless v2 Instances de base de données :

• Les valeurs de paramètre par défaut pour l'ensemble des instances de base de données du cluster sont définies par le groupe de paramètres du cluster.

• Vous pouvez remplacer certains paramètres pour des instances de base de données spécifiques en spécifiant un groupe de paramètres de base de données personnalisé pour ces instances de base de données. Vous pouvez le faire pendant le débogage ou le réglage des performances pour certaines instances de base de données. Supposons, par exemple, que vous ayez un cluster contenant des Aurora Serverless v2 Instances de base de données et certaines instances de base de données provisionnées. Dans ce cas, vous pouvez spécifier des paramètres différents pour les instances de base de données approvisionnées à l'aide d'un groupe de paramètres de base de données personnalisé.

• Dans Aurora Serverless v2, vous pouvez utiliser tous les paramètres dont l'SupportedEngineModesattribut contient la valeur provisioned dans le groupe de paramètres. Entrée Aurora Serverless v1, vous ne pouvez utiliser que le sous-ensemble de paramètres figurant serverless dans l'SupportedEngineModesattribut.

Rubriques

• Valeurs des paramètres par défaut

• Nombre maximum de connexions pour Aurora Serverless v2

• Paramètres qu'Aurora ajuste Aurora Serverless v2 évolue vers le haut et vers le bas

• Paramètres sur la base desquels Aurora calcule Aurora Serverless v2 capacité maximale

Valeurs des paramètres par défaut

La différence cruciale entre les instances de base de données provisionnées et Aurora Serverless v2 Les instances de base de données permettent à Aurora de remplacer toutes les valeurs de paramètres personnalisés pour certains paramètres liés à la capacité de l'instance de base de données. Les valeurs de paramètre personnalisées s'appliquent toujours à l'ensemble des instances de base de données approvisionnées de votre cluster. Pour plus de détails sur la façon dont Aurora Serverless v2 Les instances de base de données interprètent les paramètres des groupes de paramètres Aurora, voirParamètres de configuration des clusters Aurora. Pour les paramètres spécifiques qui Aurora Serverless v2 remplacements, voir Paramètres qu'Aurora ajuste Aurora Serverless v2 évolue vers le haut et vers le bas et. Paramètres sur la base desquels Aurora calcule Aurora Serverless v2 capacité maximale

Vous pouvez obtenir une liste des valeurs par défaut pour les groupes de paramètres par défaut des différents moteurs de base de données Aurora en utilisant la commande describe-db-cluster-parametersCLI et en interrogeant le Région AWS. Les valeurs suivantes peuvent être utilisées pour les -db-parameter-group-name options --db-parameter-group-family et pour les versions du moteur compatibles avec Aurora Serverless v2.

Moteur de base de données et version	Famille du groupe de paramètres	Nom du groupe de paramètres par défaut
Aurora MySQL version 3	aurora-mysql8.0	default.aurora-mysql8.0
Aurora PostgreSQL version 13.x	aurora-postgresql13	default.aurora-postgresql13
Aurora PostgreSQL version 14.x	aurora-postgresql14	default.aurora-postgresql14
Aurora PostgreSQL version 15.x	aurora-postgresql15	default.aurora-postgresql15
Aurora PostgreSQL version 16.x	aurora-postgresql16	default.aurora-postgresql16

L'exemple suivant illustre l'obtention d'une liste de paramètres depuis le groupe de clusters de bases de données par défaut pour Aurora MySQL version 3 et Aurora PostgreSQL version 13. Il s'agit des versions d'Aurora MySQL et d'Aurora PostgreSQL que vous utilisez avec Aurora Serverless v2.

Dans Linux, macOS, ou Unix:

aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-mysql8.0 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text

aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-postgresql13 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text

Dans Windows:

aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-mysql8.0 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text

aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-postgresql13 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text

Nombre maximum de connexions pour Aurora Serverless v2

Pour Aurora MySQL et Aurora PostgreSQL, Aurora Serverless v2 Les instances de base de données maintiennent le max_connections paramètre constant afin que les connexions ne soient pas interrompues lorsque l'instance de base de données diminue. La valeur par défaut de ce paramètre est dérivée d'une formule basée sur la taille de la mémoire de l'instance de base de données. Pour plus d'informations sur la formule et les valeurs par défaut des classes d'instance de base de données approvisionnée, consultez Nombre maximal de connexions à une instance de base de SQL données Aurora My et Nombre maximal de connexions à une instance de SQL base de données Aurora Postgre.

Lorsque Aurora Serverless v2 évalue la formule, il utilise la taille de mémoire basée sur les unités de capacité Aurora maximales (ACUs) pour l'instance de base de données, et non sur la valeur ACU actuelle. Si vous modifiez la valeur par défaut, nous vous recommandons d'utiliser une variation de la formule plutôt que de spécifier une valeur constante. De cette façon, Aurora Serverless v2 peut utiliser un réglage approprié en fonction de la capacité maximale.

Lorsque vous modifiez la capacité maximale d'un Aurora Serverless v2 Cluster de base de données, vous devez redémarrer le Aurora Serverless v2 Instances de base de données pour mettre à jour la max_connections valeur. Cela est dû au fait qu'max_connectionsil s'agit d'un paramètre statique pour Aurora Serverless v2.

Le tableau suivant indique les valeurs par défaut max_connections pour Aurora Serverless v2 sur la base de la valeur ACU maximale.

Maximum ACUs	Nombre maximal de connexions par défaut sur Aurora MySQL	Nombre maximal de connexions par défaut sur Aurora PostgreSQL
1	90	189
4	135	823
8	1 000	1 669
16	2 000	3 360
32	3 000	5 000
64	4 000	5 000
128	5 000	5 000
192	6 000	5 000
256	6 000	5 000

Note

La max_connections valeur de Aurora Serverless v2Les instances de base de données sont basées sur la taille de mémoire dérivée du maximum ACUs. Toutefois, lorsque vous spécifiez une capacité minimale de 0 ou 0,5 ACUs sur des instances de base de données compatibles avec PostgreSQL, la valeur maximale de max_connections est plafonnée à 2 000.

Pour obtenir des exemples spécifiques montrant comment max_connections évolue avec la valeur maximale d'ACU, consultez Exemple : modifiez le Aurora Serverless v2 plage de capacité d'un cluster Aurora MySQL et Exemple : modifiez le Aurora Serverless v2 plage de capacité d'un cluster Aurora PostgreSQL.

Paramètres qu'Aurora ajuste Aurora Serverless v2 évolue vers le haut et vers le bas

Pendant le redimensionnement automatique, Aurora Serverless v2 doit être en mesure de modifier les paramètres de chaque instance de base de données afin de fonctionner au mieux en fonction de l'augmentation ou de la diminution de la capacité. Par conséquent, vous ne pouvez pas remplacer certains paramètres liés à la capacité. Pour les paramètres que vous pouvez remplacer, évitez de coder en dur les valeurs fixes. Les remarques suivantes s'appliquent aux paramètres liés à la capacité.

Pour Aurora MySQL, Aurora Serverless v2 redimensionne certains paramètres de manière dynamique lors de la mise à l'échelle. Pour les paramètres suivants, Aurora Serverless v2 n'utilise aucune valeur de paramètre personnalisée que vous spécifiez :

• innodb_buffer_pool_size

• innodb_purge_threads

• table_definition_cache

• table_open_cache

Pour Aurora PostgreSQL, Aurora Serverless v2 redimensionne le paramètre suivant de manière dynamique lors de la mise à l'échelle. Pour les paramètres suivants, Aurora Serverless v2 n'utilise aucune valeur de paramètre personnalisée que vous spécifiez :

• shared_buffers

Pour tous les paramètres autres que ceux listés ici, Aurora Serverless v2 Les instances de base de données fonctionnent de la même manière que les instances de base de données provisionnées. La valeur de paramètre par défaut est héritée du groupe de paramètres de cluster. Vous pouvez modifier la valeur par défaut pour l'ensemble du cluster à l'aide d'un groupe de paramètres de cluster personnalisé. Sinon, vous pouvez modifier la valeur par défaut de certaines instances de base de données à l'aide d'un groupe de paramètres de base de données personnalisé. Les paramètres dynamiques sont immédiatement mis à jour. Les modifications apportées aux paramètres statiques ne prennent effet qu'après le redémarrage de l'instance de base de données.

Paramètres sur la base desquels Aurora calcule Aurora Serverless v2 capacité maximale

Pour les paramètres suivants, Aurora PostgreSQL utilise des valeurs par défaut dérivées de la taille de mémoire basée sur le nombre maximal d'ACU, comme avec max_connections :

• autovacuum_max_workers

• autovacuum_vacuum_cost_limit

• autovacuum_work_mem

• effective_cache_size

• maintenance_work_mem

Éviter les out-of-memory erreurs

Si l'un de vos Aurora Serverless v2 Les instances de base de données atteignent constamment la limite de leur capacité maximale. Aurora indique cette condition en définissant l'instance de base de données sur le statut deincompatible-parameters. Lorsque l'instance de base de données a le statut incompatible-parameters, certaines opérations sont bloquées. Par exemple, vous ne pouvez pas mettre à niveau la version du moteur.

Généralement, votre instance de base de données passe dans cet état lorsqu'elle redémarre fréquemment en raison d' out-of-memoryerreurs. Aurora enregistre un événement lorsque ce type de redémarrage se produit. Vous pouvez afficher l'événement en suivant la procédure de la rubrique Consulter les RDS événements Amazon. Une utilisation exceptionnellement élevée de la mémoire peut se produire en raison de la surcharge provoquée par l'activation de paramètres tels que Performance Insights et l'authentification IAM. Elle peut également se produire en raison d'une charge de travail importante sur votre instance de base de données ou de la gestion des métadonnées associées à un grand nombre d'objets de schéma.

Si la pression de la mémoire diminue de sorte que l'instance de base de données n'atteint pas très souvent sa capacité maximale, Aurora rétablit automatiquement le statut available de l'instance de base de données.

Pour vous remettre de cet état, vous pouvez prendre tout ou partie des mesures suivantes :

• Augmenter la limite inférieure de capacité pour Aurora Serverless v2 Instances de base de données en modifiant la valeur minimale de l'unité de capacité Aurora (ACU) pour le cluster. Cela évite les situations problématiques où une base de données inactive fait l'objet d'une réduction d'échelle jusqu'à une capacité où la mémoire est inférieure à la mémoire nécessaire pour les fonctionnalités activées dans votre cluster. Après avoir modifié les paramètres ACU du cluster, redémarrez le Aurora Serverless v2 instance de base de données. Cela permet d'évaluer si Aurora peut réinitialiser le statut sur available.

• Augmenter la limite supérieure de capacité pour Aurora Serverless v2 Instances de base de données en modifiant la valeur ACU maximale pour le cluster. Cela évite les situations problématiques où une base de données occupée ne peut pas faire l'objet d'une augmentation d'échelle jusqu'à une capacité où la mémoire est suffisante pour les fonctionnalités activées dans votre cluster et pour la charge de travail de la base de données. Après avoir modifié les paramètres ACU du cluster, redémarrez le Aurora Serverless v2 instance de base de données. Cela permet d'évaluer si Aurora peut réinitialiser le statut sur available.

• Désactivez les paramètres de configuration exigeant une surcharge de mémoire. Supposons, par exemple, que des fonctionnalités telles que AWS Identity and Access Management (IAM), Performance Insights ou la réplication des journaux binaires Aurora MySQL soient activées mais que vous ne les utilisez pas. Si c'est le cas, vous pouvez les désactiver. Vous pouvez également augmenter les valeurs de capacité minimale et maximale du cluster pour tenir compte de la mémoire utilisée par ces fonctionnalités. Pour obtenir des directives sur le choix des valeurs de capacité minimale et maximale, consultez Choisir le Aurora Serverless v2 plage de capacité pour un cluster Aurora.

• Réduisez la charge de travail sur l'instance de base de données. Par exemple, vous pouvez ajouter des instances de base de données de lecteur au cluster afin de répartir la charge issue des requêtes en lecture seule sur d'autres instances de base de données.

• Réglez le code SQL utilisé par votre application pour utiliser moins de ressources. Par exemple, vous pouvez examiner vos plans de requête, vérifier le journal des requêtes lentes ou ajuster les index de vos tables. Vous pouvez également effectuer d'autres types de réglages SQL traditionnels.

Statistiques Amazon CloudWatch importantes pour Aurora Serverless v2

Pour commencer à utiliser Amazon CloudWatch pour votre Aurora Serverless v2 Instance de base de données, voirVisualisation Aurora Serverless v2 se connecte à Amazon CloudWatch. Pour en savoir plus sur la façon de surveiller les clusters de base de données Aurora via CloudWatch, consultezSurveillance des événements du journal sur Amazon CloudWatch.

Vous pouvez consulter votre Aurora Serverless v2 Les instances de base de données CloudWatch permettent de surveiller la capacité consommée par chaque instance de base de données à l'aide de la ServerlessDatabaseCapacity métrique. Vous pouvez également surveiller toutes les CloudWatch métriques Aurora standard, telles que DatabaseConnections etQueries. Pour obtenir la liste complète des CloudWatch mesures que vous pouvez surveiller pour Aurora, consultez CloudWatch Métriques Amazon pour Amazon Aurora. Les métriques, de niveau cluster et de niveau instance, sont décrites aux rubriques Métriques de niveau cluster pour Amazon Aurora et Métriques de niveau instance pour Amazon Aurora.

Il est important de surveiller les indicateurs suivants CloudWatch au niveau de l'instance afin que vous puissiez comprendre comment votre Aurora Serverless v2 Les instances de base de données augmentent ou diminuent. Toutes ces métriques sont calculées toutes les secondes. De cette façon, vous pouvez surveiller l'état actuel de votre Aurora Serverless v2 Instances de base de données. Vous pouvez configurer des alarmes pour vous avertir le cas échéant Aurora Serverless v2 L'instance de base de données approche d'un seuil pour les métriques liées à la capacité. Vous pouvez déterminer si les valeurs de capacité minimale et maximale sont appropriées ou si vous devez les ajuster. Vous pouvez déterminer où concentrer vos efforts pour optimiser l'efficacité de votre base de données.

• ServerlessDatabaseCapacity. En tant que métrique au niveau de l'instance, elle indique le nombre de personnes ACUs représentées par la capacité actuelle de l'instance de base de données. En tant que métrique au niveau du cluster, elle représente la moyenne des ServerlessDatabaseCapacity valeurs de tous les Aurora Serverless v2 Instances de base de données dans le cluster. Cette métrique est uniquement une métrique au niveau du cluster dans Aurora Serverless v1. Dans Aurora Serverless v2, il est disponible au niveau de l'instance de base de données et au niveau du cluster.

• ACUUtilization. Cette métrique est nouvelle dans Aurora Serverless v2. Cette valeur est représentée sous forme de pourcentage. Elle est calculée comme la valeur de la métrique ServerlessDatabaseCapacity divisée par le nombre maximal d'ACU du cluster de bases de données. Tenez compte des directives suivantes pour interpréter cette métrique et prendre les mesures nécessaires :

  • Si cette métrique se rapproche de la valeur 100.0, l'instance de base de données a fait l'objet d'une augmentation d'échelle aussi élevée que possible. Envisagez d'augmenter le nombre maximal d'ACU pour le cluster. De cette façon, les instances de base de données de lecteur et d'enregistreur peuvent être mis à l'échelle jusqu'à une capacité supérieure.

  • Supposons qu'une charge de travail en lecture seule force une instance de base de données de lecteur à se rapprocher de la valeur 100.0 pour ACUUtilization, alors que l'instance de base de données d'enregistreur n'est pas proche de sa capacité maximale. Dans ce cas, envisagez d'ajouter des instances de base de données de lecteur supplémentaires au cluster. De cette façon, vous pouvez répartir la partie en lecture seule de la charge de travail sur un plus grand nombre d'instances de base de données, réduisant ainsi la charge sur chaque instance de base de données de lecteur.

  • Supposons que vous exécutiez une application de production, où les performances et la capacité de mise à l’échelle sont les principaux facteurs à prendre en compte. Dans ce cas, vous pouvez définir le nombre maximal d'ACU du cluster sur une valeur élevée. Votre objectif est que la métrique ACUUtilization soit toujours inférieure à 100.0. Avec un nombre maximal d'ACU élevé, vous avez la garantie que l'espace est suffisant en cas de pics d'activité inattendus de la base de données. Seule la capacité de base de données réellement consommée vous est facturée.

• CPUUtilization. Cette métrique est interprétée différemment dans Aurora Serverless v2 que dans les instances de base de données provisionnées. Dans Aurora Serverless v2, cette valeur est un pourcentage calculé comme la quantité de processeur actuellement utilisée divisée par la capacité du processeur disponible sous la valeur ACU maximale du cluster de base de données. Aurora surveille automatiquement cette valeur et augmente votre Aurora Serverless v2 Instance de base de données lorsque l'instance de base de données utilise régulièrement une proportion élevée de sa capacité de processeur.

  Si cette métrique se rapproche de la valeur 100.0, l'instance de base de données a atteint sa capacité de processeur maximale. Envisagez d'augmenter le nombre maximal d'ACU pour le cluster. Si cette métrique se rapproche de la valeur 100.0 sur une instance de base de données de lecteur, envisagez d'ajouter des instances de base de données de lecteur supplémentaires au cluster. De cette façon, vous pouvez répartir la partie en lecture seule de la charge de travail sur un plus grand nombre d'instances de base de données, réduisant ainsi la charge sur chaque instance de base de données de lecteur.

• FreeableMemory. Cette valeur représente la quantité de mémoire inutilisée disponible lorsque Aurora Serverless v2 L'instance de base de données est dimensionnée à sa capacité maximale. Pour chaque ACU dont la capacité actuelle est inférieure à la capacité maximale, cette valeur augmente d'environ 2 Gio. Par conséquent, cette métrique ne se rapproche pas de zéro tant que l'instance de base de données ne fait pas l'objet d'une augmentation d'échelle aussi élevée que possible.

  Si cette métrique se rapproche de la valeur 0, l'instance de base de données a fait l'objet d'une augmentation d'échelle aussi élevée que possible et se rapproche de la limite de sa mémoire disponible. Envisagez d'augmenter le nombre maximal d'ACU pour le cluster. Si cette métrique se rapproche de la valeur 0 sur une instance de base de données de lecteur, envisagez d'ajouter des instances de base de données de lecteur supplémentaires au cluster. De cette façon, vous pouvez répartir la partie en lecture seule de la charge de travail sur un plus grand nombre d'instances de base de données, réduisant ainsi l'utilisation de la mémoire sur chaque instance de base de données de lecteur.

• TempStorageIops. Nombre d'E/S par seconde réalisées sur le stockage local attaché à l'instance de base de données. Il inclut les E/S par seconde pour les lectures et les écritures. Cette métrique représente un nombre et est mesurée une fois par seconde. Il s'agit d'une nouvelle métrique pour Aurora Serverless v2. Pour plus de détails, voirMétriques de niveau instance pour Amazon Aurora.

• TempStorageThroughput. Volume de données transférées depuis et vers le stockage local associé à l'instance de base de données. Cette métrique représente des octets et est mesurée une fois par seconde. Il s'agit d'une nouvelle métrique pour Aurora Serverless v2. Pour plus de détails, voirMétriques de niveau instance pour Amazon Aurora.

Généralement, la plupart des mises à l'échelle pour Aurora Serverless v2 Les instances de base de données sont causées par l'utilisation de la mémoire et l'activité du processeur. Les métriques TempStorageIops et TempStorageThroughput peuvent vous aider à diagnostiquer les rares cas où l'activité du réseau pour les transferts entre votre instance de base de données et vos périphériques de stockage locaux est responsable d'augmentations de capacité inattendues. Pour surveiller d'autres activités du réseau, vous pouvez utiliser ces métriques existantes :

• NetworkReceiveThroughput

• NetworkThroughput

• NetworkTransmitThroughput

• StorageNetworkReceiveThroughput

• StorageNetworkThroughput

• StorageNetworkTransmitThroughput

Vous pouvez demander à Aurora de publier une partie ou la totalité des journaux de base de données sur Amazon CloudWatch Logs. Pour obtenir des instructions, consultez les rubriques suivantes en fonction de votre moteur de base de données :

• Publication des journaux Aurora PostgreSQL sur Amazon Logs CloudWatch

• Publication des journaux Amazon Aurora MySQL sur Amazon CloudWatch Logs

Comment ? Aurora Serverless v2 les statistiques s'appliquent à votre AWS facture

Le Aurora Serverless v2 les frais figurant sur votre AWS facture sont calculés en fonction des ServerlessDatabaseCapacity mêmes indicateurs que vous pouvez surveiller. Le mécanisme de facturation peut différer de la CloudWatch moyenne calculée pour cette métrique dans les cas où vous utilisez Aurora Serverless v2 capacité pendant une partie d'une heure seulement. Cela peut également être différent si des problèmes du système rendent la CloudWatch métrique indisponible pendant de brèves périodes. Par conséquent, la valeur correspondant aux heures ACU peut être légèrement différente sur votre facture que si vous calculez vous-même le nombre à partir de la valeur moyenne de ServerlessDatabaseCapacity.

Exemples de CloudWatch commandes pour Aurora Serverless v2 metrics

Les AWS CLI exemples suivants montrent comment vous pouvez surveiller les CloudWatch indicateurs les plus importants liés à Aurora Serverless v2. Dans chaque cas, remplacez la Value= chaîne du --dimensions paramètre par votre propre identifiant Aurora Serverless v2 instance de base de données.

L'exemple Linux suivant affiche les valeurs de capacité minimale, maximale et moyenne d'une instance de base de données, mesurées toutes les 10 minutes sur une heure. La commande Linux date indique les heures de début et de fin par rapport à la date et à l'heure actuelles. La fonction sort_by du paramètre --query trie les résultats par ordre chronologique en fonction du champ Timestamp.

aws cloudwatch get-metric-statistics --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Les exemples Linux suivants illustrent la surveillance de la capacité de chaque instance de base de données d'un cluster. Ils mesurent l'utilisation de capacité minimale, maximale et moyenne de chaque instance de base de données. Les mesures sont effectuées une fois par heure sur une période de trois heures. Ces exemples utilisent la ACUUtilization métrique représentant un pourcentage de la limite supérieure de ACUs, au lieu de ServerlessDatabaseCapacity représenter un nombre fixe de ACUs. De cette façon, vous n'avez pas besoin de connaître les chiffres réels pour les nombres d'ACU minimal et maximal dans la plage de capacité. Les pourcentages sont compris entre 0 et 100.

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_writer_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_reader_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

L'exemple Linux suivant effectue des mesures similaires aux précédentes. Dans ce cas, les mesures concernent la métrique CPUUtilization. Les mesures sont effectuées toutes les 10 minutes sur une période d'une heure. Les chiffres représentent le pourcentage de processeur disponible utilisé, en fonction des ressources de processeur disponibles pour la valeur de capacité maximale de l'instance de base de données.

aws cloudwatch get-metric-statistics --metric-name "CPUUtilization" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

L'exemple Linux suivant effectue des mesures similaires aux précédentes. Dans ce cas, les mesures concernent la métrique FreeableMemory. Les mesures sont effectuées toutes les 10 minutes sur une période d'une heure.

aws cloudwatch get-metric-statistics --metric-name "FreeableMemory" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Surveillance Aurora Serverless v2 performance avec Performance Insights

Vous pouvez utiliser Performance Insights pour surveiller les performances de Aurora Serverless v2 Instances de base de données. Pour connaître les procédures relatives à Performance Insights, consultez Surveillance de la charge de base de données avec Performance Insights sur Amazon Aurora.

Les nouveaux compteurs Performance Insights suivants s'appliquent à Aurora Serverless v2 Instances de base de données :

• os.general.serverlessDatabaseCapacity— La capacité actuelle de l'instance de base de données dans ACUs. La valeur correspond à la ServerlessDatabaseCapacity CloudWatch métrique de l'instance de base de données.

• os.general.acuUtilization : pourcentage de la capacité actuelle par rapport à la capacité maximale configurée. La valeur correspond à la ACUUtilization CloudWatch métrique de l'instance de base de données.

• os.general.maxConfiguredAcu— La capacité maximale que vous avez configurée pour cela Aurora Serverless v2 instance de base de données. C'est mesuré en ACUs.

• os.general.minConfiguredAcu— La capacité minimale que vous avez configurée pour cela Aurora Serverless v2 instance de base de données. Il est mesuré en ACUs

Pour obtenir la liste complète des compteurs Performance Insights, consultez Métrique de compteur de Performance Insights.

Lorsque vCPU des valeurs sont affichées pour un Aurora Serverless v2 Instance de base de données dans Performance Insights, ces valeurs représentent des estimations basées sur la valeur ACU de l'instance de base de données. À l'intervalle par défaut d'une minute, toutes les valeurs vCPU fractionnelles sont arrondies au nombre entier le plus proche. Pour les intervalles plus longs, la valeur vCPU affichée correspond à la moyenne des valeurs entières de vCPU pour chaque minute.

Résolution des problèmes Aurora Serverless v2 problèmes de capacité

Dans certains cas, Aurora Serverless v2 ne réduit pas la capacité minimale, même en l'absence de charge sur la base de données. Plusieurs raisons sont possibles :

• Certaines fonctionnalités peuvent augmenter l'utilisation des ressources et empêcher la réduction de la base de données à sa capacité minimale. Les principales fonctions sont notamment :

  • Bases de données globales Aurora

  • Exportation de CloudWatch journaux

  • Activation de pg_audit sur les clusters de bases de données compatibles avec Aurora PostgreSQL

  • Surveillance améliorée

  • Performance Insights

  Pour de plus amples informations, veuillez consulter Choisir le minimum Aurora Serverless v2 paramètre de capacité pour un cluster.

• Si une instance de lecteur n'est pas réduite au minimum et conserve une capacité égale ou supérieure à celle de l'instance d'écriture, vérifiez le niveau de priorité de l'instance de lecteur. Aurora Serverless v2 les instances de base de données de lecteur de niveau 0 ou 1 sont maintenues à une capacité minimale au moins aussi élevée que celle de l'instance de base de données d'écriture. Changez le niveau de priorité du processus de lecture à 2 ou plus pour qu'il augmente et diminue indépendamment du processus d'écriture. Pour de plus amples informations, veuillez consulter Choix du niveau de promotion pour un Aurora Serverless v2 lecteur.

• Définissez tous les paramètres de la base de données qui ont un impact sur la taille de la mémoire partagée à leurs valeurs par défaut. La définition d'une valeur supérieure à la valeur par défaut augmente les besoins en mémoire partagée et empêche la base de données de se réduire à la capacité minimale. Par exemple, max_connections et max_locks_per_transaction.

  Note

  La mise à jour des paramètres de mémoire partagée nécessite un redémarrage de la base de données pour que les changements prennent effet.

• De lourdes charges de travail de base de données peuvent augmenter l'utilisation des ressources.

• D'importants volumes de base de données peuvent augmenter l'utilisation des ressources.

  Amazon Aurora utilise des ressources de mémoire et de processeur pour la gestion des clusters de bases de données. Aurora nécessite plus d'UC et de mémoire pour gérer des clusters de bases de données comportant d'importants volumes de base de données. Si la capacité minimale de votre cluster est inférieure à la capacité minimale requise pour la gestion du cluster, votre cluster ne sera pas réduit à la capacité minimale.

• Les processus d'arrière-plan, tels que la purge, peuvent également augmenter l'utilisation des ressources.

Si la base de données n'est toujours pas réduite à la capacité minimale configurée, arrêtez et redémarrez la base de données pour récupérer les fragments de mémoire qui ont pu s'accumuler au fil du temps. L'arrêt et le démarrage d'une base de données entraînent un temps d'arrêt, il est donc recommandé de le faire avec parcimonie.