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.

Performances et mise à l'échelle pour Aurora Serverless v2

Les procédures et exemples suivants montrent comment définir la plage de capacité pour les clusters Aurora Serverless v2 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 bien savoir comment fonctionne la mise à l’échelle d'Aurora Serverless v2. Le mécanisme de mise à l'échelle est différent de celui d'Aurora Serverless v1. Pour en savoir plus, consultez Aurora Serverless v2 mise à l'échelle.

Choix de la plage de capacité Aurora Serverless v2 pour un cluster Aurora

Avec les instances de base de données Aurora Serverless v2, vous définissez la plage de capacité qui s'applique à toutes les instances de base de données de votre cluster de bases de données en même temps que vous ajoutez la première instance de base de données Aurora Serverless v2 au cluster de bases 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 toutes les modifications des paramètres peut exiger de redémarrer chaque instance de base de données Aurora Serverless v2.

Choix de la valeur minimale de capacité Aurora Serverless v2 pour un cluster

Il peut s'avérer tentant de toujours choisir 0,5 comme valeur minimale de capacité Aurora Serverless v2. 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, selon la façon dont vous utilisez ce cluster et les autres paramètres que vous configurez, une capacité minimale différente peut être la plus efficace. Tenez compte des facteurs suivants lors du choix de la valeur minimale de capacité :

Choix de la valeur maximale de capacité Aurora Serverless v2 pour un cluster

Il peut s'avérer tentant de toujours choisir une valeur élevée pour la valeur maximale de capacité Aurora Serverless v2. 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é :

Exemple : Modification de la plage de capacité Aurora Serverless v2 d'un cluster Aurora MySQL

L' AWS CLI exemple suivant montre comment mettre à jour la plage ACU pour les instances de Aurora Serverless v2 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.

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 : Modification de la plage de capacité Aurora Serverless v2 d'un cluster Aurora PostgreSQL

Les exemples d'interface de ligne de commande suivants montrent comment mettre à jour la plage d'ACU pour les instances de base de données Aurora Serverless v2 d'un cluster Aurora PostgreSQL existant.

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.

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. C'est parce que max_connections présente une valeur maximale de 5 000 pour un cluster de bases de données Aurora Serverless v2 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 des Aurora Serverless v2 instances de base de données est basée 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 des groupes de paramètres pour Aurora Serverless v2

Lorsque vous créez votre cluster de base de données Aurora Serverless v2, vous choisissez un moteur de bases 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 pour les groupes de paramètres s'appliquent à Aurora Serverless v2.

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

Valeurs des paramètres par défaut

La différence cruciale entre les instances de base de données approvisionnées et les instances de base de données Aurora Serverless v2 réside dans le fait qu'Aurora remplace toutes les valeurs de paramètre personnalisées pour certains paramètres liés à la capacité d'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 en savoir plus sur la façon dont les instances de base de données Aurora Serverless v2 interprètent les paramètres des groupes de paramètres Aurora, consultez Paramètres de configuration des clusters Aurora. Pour obtenir les paramètres qui sont remplacés par Aurora Serverless v2, consultez Paramètres ajustés par Aurora en fonction de l'augmentation et de la réduction d'échelle d'Aurora Serverless v2 et Paramètres calculés par Aurora en fonction de la capacité maximale d'Aurora Serverless v2.

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 options --db-parameter-group-family et -db-parameter-group-name pour les versions de moteur compatibles avec Aurora Serverless v2.

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. Ce sont les versions d'Aurora MySQL et d'Aurora PostgreSQL que vous utilisez avec Aurora Serverless v2.

Pour LinuxmacOS, 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 maximal de connexions pour Aurora Serverless v2

Pour Aurora MySQL et Aurora PostgreSQL, les instances de base de données Aurora Serverless v2 maintiennent une valeur constante pour le paramètre max_connections afin que les connexions ne soient pas interrompues lorsque l'instance de base de données fait l'objet d'une réduction d'échelle. 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 données Aurora MySQL et Nombre maximal de connexions à une instance de base de données Aurora PostgreSQL.

Lors de l'Aurora Serverless v2évaluation de la formule, elle 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 cluster de bases de données Aurora Serverless v2, vous devez redémarrer les instances de base de données Aurora Serverless v2 pour mettre à jour la valeur max_connections. Cela est dû au fait que max_connections est un paramètre statique pour Aurora Serverless v2.

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

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

Paramètres ajustés par Aurora en fonction de l'augmentation et de la réduction d'échelle d'Aurora Serverless v2

Lors de la mise à l'échelle automatique, Aurora Serverless v2 doit être en mesure de modifier les paramètres pour que chaque instance de base de données fonctionne 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 dynamiquement pendant 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 :

Pour Aurora PostgreSQL, Aurora Serverless v2 redimensionne dynamiquement le paramètre suivant pendant 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 :

Pour tous les paramètres autres que ceux énumérés ici, les instances de base de données Aurora Serverless v2 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 calculés par Aurora en fonction de la capacité maximale d'Aurora Serverless v2

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 :

Éviter les out-of-memory erreurs

Si l'une de vos instances de base de données Aurora Serverless v2 atteint systématiquement la limite de sa capacité maximale, Aurora indique cette condition en définissant le statut de l'instance de base de données sur incompatible-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 :

Statistiques Amazon CloudWatch importantes pour Aurora Serverless v2

Pour commencer à utiliser Amazon CloudWatch pour votre Aurora Serverless v2 instance de base de données, consultezVisualisation Aurora Serverless v2 se connecte à Amazon CloudWatch. Pour en savoir plus sur la surveillance des clusters de base de données Aurora via CloudWatch, consultezSurveillance des événements du journal sur Amazon CloudWatch.

Vous pouvez afficher vos Aurora Serverless v2 instances de base de données CloudWatch pour 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 métriques suivantes CloudWatch au niveau de l'instance afin de comprendre comment vos Aurora Serverless v2 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 le statut actuel de vos instances de base de données Aurora Serverless v2. Vous pouvez définir des alarmes qui vous avertissent si une instance de base de données Aurora Serverless v2 se rapproche 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.

Généralement, la plupart des augmentations d'échelle pour Aurora Serverless v2 est engendrée 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 :

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 :

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

Les Aurora Serverless v2 frais figurant sur votre AWS facture sont calculés en fonction des mêmes ServerlessDatabaseCapacity 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 n'utilisez la Aurora Serverless v2 capacité que pendant une partie d'heure. 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 les Aurora Serverless v2 métriques

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

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 des performances d'Aurora Serverless v2 avec Performance Insights

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

Les nouveaux compteurs Performance Insights suivants s'appliquent aux instances de base de données Aurora Serverless v2.

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

Lorsque les valeurs vCPU sont affichées pour une instance de base de données Aurora Serverless v2 dans Performance Insights, ces valeurs représentent des estimations basées sur le nombre d'ACU pour 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 de capacité d'Aurora Serverless v2

Dans certains cas, Aurora Serverless v2 ne se réduit pas à la capacité minimale, même si la base de données n'est pas chargée. Plusieurs raisons sont possibles :

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.