Performances et évolutivité pour Aurora Serverless v2 - Amazon Aurora
Choix de la plage de capacitéUtilisation de groupes de paramètres pour Aurora Serverless v2Éviter les out-of-memory erreurs CloudWatch Indicateurs importantsSurveillance Aurora Serverless v2 performance avec Performance InsightsRésolution des problèmes Aurora Serverless v2 problèmes de capacité

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 é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 la mise à l'échelle 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.

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.

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 la capacité. Cette valeur permet à l'instance de base de données de procéder à une réduction d'échelle maximale lorsqu'elle est complètement inactive. Toutefois, selon la façon dont vous utilisez ce cluster et les autres paramètres que vous configurez, une autre valeur 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 définir 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, chacune ACU correspond à environ 2 GiB 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 de manière optimale lorsque les instances de base de données ont une certaine quantité de données dans le cache tampon, pensez à spécifier un ACU paramètre minimum selon lequel la mémoire est suffisamment grande 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 ramener les données dans le cache tampon est importante, il peut être plus efficace de choisir une ACU valeur minimale plus élevée.

  • 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 les exigences en mémoire de votre charge de travail allouée sont trop élevées pour les petites classes d'instances de base de données telles que T3 ou T4g, choisissez un ACU paramètre minimum fournissant une mémoire comparable à celle d'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 certains cas, votre cluster peut contenir Aurora Serverless v2 des instances de base de données de lecteur qui évoluent indépendamment du rédacteur. Si c'est le cas, choisissez une valeur minimale de capacité suffisamment élevée pour que, lorsque l'instance de base de données de l'enregistreur est occupée à traiter une charge de travail exigeante en écriture, les instances de base de données de lecteur puissent appliquer les modifications depuis l'enregistreur sans prendre de retard. Si vous constatez un retard de réplica dans les lecteurs aux niveaux de promotion 2 à 15, envisagez d'augmenter la valeur minimale de capacité de votre 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 comparable CPU à celle de l'instance de base de données du rédacteur.

  • 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 maximumACUs. Toutefois, lorsque vous spécifiez une capacité minimale de 0,5 ACUs sur des instances de base de données SQL compatibles avec Postgre, la valeur maximale de max_connections est plafonnée à 2 000.

    Si vous avez l'intention d'utiliser le SQL cluster Aurora Postgre pour une charge de travail à connexion élevée, pensez à utiliser un ACU paramètre minimum 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 ACU valeurs 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é. Ainsi, si vous spécifiez une capacité maximale relativement élevée et que l'instance de base de données passe le plus clair de son temps à proximité de cette capacité, envisagez d'augmenter le ACU paramètre minimum. 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 la 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,5ACUs. 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 définir un ACU paramètre maximum de 64 pour configurer un Aurora Serverless v2 Instance de base de données pouvant atteindre approximativement la même capacité. En effet, chacune ACU correspond à environ 2 GiB 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 votre budget limite 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 dans votre cluster, le maximum théorique Aurora Serverless v2 la capacité que le cluster peut consommer à tout moment est n fois supérieure à la ACU valeur maximale du 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 un paramètre qui dispose encore de suffisamment de mémoire et de CPU ressources pour que l'application continue de fonctionner.

  • Si vous activez dans votre cluster des paramètres qui augmentent l'utilisation de la mémoire pour chaque instance de base de données, tenez compte de cette mémoire lorsque vous déterminez la ACU valeur maximale. Ces paramètres incluent ceux relatifs à Performance Insights, aux requêtes Aurora My SQL parallel, au schéma de SQL performance Aurora My et à la réplication des journaux SQL binaires Aurora My. Assurez-vous que la ACU valeur maximale autorise 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 la résolution des problèmes liés à la combinaison d'un ACU paramètre maximal faible et des fonctionnalités Aurora qui entraînent une surcharge de mémoire, consultezÉviter les out-of-memory erreurs.

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

L' AWS CLI exemple suivant montre comment mettre à jour la ACU plage pour Aurora Serverless v2 Instances de base de données dans un SQL cluster Aurora My 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 à 8ACUs. 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 modify-db-cluster commande terminée, la ACU plage 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,5ACUs. 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 max_connections paramètre a été augmenté pour refléter une valeur dérivée de la ACU valeur maximale. 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 Postgre SQL

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

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

  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. Rétablissez la capacité à sa plage initiale de 0,5 ACU à 1.

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

CloudWatch graphique de Aurora Serverless v2 changements de capacité

L'instance de base de données est inactive et réduite à 0,5ACUs. 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 modify-db-cluster commande terminée, la ACU plage du cluster est comprise entre 8,0 et 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.0ACUs. 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,5ACUs. 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 bases 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 à 128ACUs. Le cluster de base de données est réduit à 10ACUs, 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 maximumACUs. Toutefois, lorsque vous spécifiez une capacité minimale de 0,5 ACUs sur des instances de base de données SQL compatibles avec Postgre, la valeur maximale de max_connections est plafonnée à 2 000.

Nous ramenons maintenant la capacité à sa plage initiale de 0,5 à 1 ACU et 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 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.

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 toute valeur de paramètre personnalisée 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 selon lesquels 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 describe-db-cluster-parametersCLIcommande 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 Ma SQL version 3

aurora-mysql8.0

default.aurora-mysql8.0

Aurora Postgre SQL version 1.3.x

aurora-postgresql13

default.aurora-postgresql13

Aurora Postgre SQL version 1.4.x

aurora-postgresql14

default.aurora-postgresql14

Aurora Postgre SQL version 1.5.x

aurora-postgresql15

default.aurora-postgresql15

Aurora Postgre SQL version 1.6.x

aurora-postgresql16

default.aurora-postgresql16

L'exemple suivant obtient une liste de paramètres à partir du groupe de clusters de base de données par défaut pour Aurora My SQL version 3 et Aurora Postgre SQL 13. Il s'agit des SQL versions Aurora My SQL et Aurora Postgre 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 My SQL et Aurora Postgrer, SQL 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 ACU valeur 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 ACU valeur maximale.

Maximum ACUs Nombre maximal de connexions par défaut sur Aurora My SQL Nombre maximal de connexions par défaut sur Aurora Postgre SQL
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 v2 Les instances de base de données sont basées sur la taille de mémoire dérivée de la capacité maximale. Toutefois, lorsque vous spécifiez une capacité minimale de 0,5 ACUs sur des instances de base de données SQL compatibles avec Postgre, la valeur maximale de max_connections est plafonnée à 2 000.

Pour des exemples spécifiques illustrant la façon dont max_connections les modifications sont associées à la ACU valeur maximale, reportez-vous Exemple : modifiez le Aurora Serverless v2 plage de capacité d'un SQL cluster Aurora My aux sections etExemple : modifiez le Aurora Serverless v2 plage de capacité d'un cluster Aurora Postgre SQL.

Paramètres selon lesquels 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 Postgrer, SQL 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 Postgre SQL utilise des valeurs par défaut dérivées de la taille de la mémoire en fonction du ACU paramètre maximal, comme pour : 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. L'utilisation de la mémoire peut être anormalement élevée en raison de la surcharge liée à l'activation de paramètres tels que Performance Insights et IAM l'authentification. 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 ACU paramètres 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 ACU valeur maximale du 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 ACU paramètres 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 Aurora My SQL binary log replication 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.

  • Ajustez le SQL code 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 SQL réglage 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 ACUs représentés 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 ServerlessDatabaseCapacity métrique divisée par la ACU valeur maximale 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 ACU paramètre maximal 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 la ACU valeur maximale du cluster sur un nombre élevé. Votre objectif est que la métrique ACUUtilization soit toujours inférieure à 100.0. Avec une ACU valeur maximale élevée, vous pouvez être sûr qu'il y a suffisamment de place pour faire face à des pics inattendus d'activité 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é CPU actuellement utilisée divisée par la CPU capacité disponible sous la ACU valeur maximale du cluster de bases 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 constamment une grande partie de sa CPU capacité.

    Si cette métrique approche une valeur de100.0, l'instance de base de données a atteint sa CPU capacité maximale. Envisagez d'augmenter le ACU paramètre maximal 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 fois ACU que la capacité actuelle est inférieure à la capacité maximale, cette valeur augmente d'environ 2 GiB. 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 ACU paramètre maximal 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. Le nombre d'opérations IOPS effectuées sur le stockage local attaché à l'instance de base de données. Il inclut le IOPS 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.

En règle générale, la plupart des mises à l'échelle pour Aurora Serverless v2 Les instances de base de données sont causées par l'utilisation et l'CPUactivité de la mémoire. 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 CloudWatch. Vous sélectionnez les journaux à publier en activant les paramètres de configuration tels que general_log et slow_query_log dans le groupe de paramètres du cluster de base de données associé au cluster qui contient votre Aurora Serverless v2 Instances de base de données. Lorsque vous désactivez un paramètre de configuration de journal, la publication de ce journal s' CloudWatch arrête. Vous pouvez également supprimer les identifiants CloudWatch s'ils ne sont plus nécessaires.

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. Ainsi, il se peut que la valeur de ACU -hours sur votre facture soit légèrement différente de celle que vous pourriez voir si vous calculez le nombre vous-même à partir de la valeur ServerlessDatabaseCapacity moyenne.

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 deACUs, au lieu de ServerlessDatabaseCapacity représenter un nombre fixe deACUs. Ainsi, vous n'avez pas besoin de connaître les chiffres réels pour les ACU valeurs minimale et maximale de 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 ressources disponibles CPU utilisées, sur la base CPU des ressources disponibles par rapport au paramètre de capacité maximale défini pour 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 dansACUs. 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é enACUs.

  • 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 ACU valeur de l'instance de base de données. À l'intervalle par défaut d'une minute, toutes les CPU valeurs fractionnaires de v sont arrondies au nombre entier le plus proche. Pour les intervalles plus longs, la CPU valeur v indiquée est la moyenne des CPU valeurs entières v 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 pg_audit sur des clusters de bases de données SQL compatibles avec Aurora Postgre

    • 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 de la mémoire et CPU des ressources pour la gestion des clusters de bases de données. Aurora a besoin de plus CPU de mémoire pour gérer les clusters de bases de données dotés de volumes de base de données plus importants. 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.