Réduction verticale à zéro ACU avec pause et reprise automatiques pour Aurora Serverless v2 - Amazon Aurora
Présentation de la pause automatique Conditions préalables et limitations Activation et désactivation de la pause automatique Fonctionnement de la pause automatique Configuration de la pause automatique et des clusters Aurora Surveillance de la pause automatique Résolution des problèmes liés à la pause automatique Conception relatives à la conception de la pause automatique

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.

Réduction verticale à zéro ACU avec pause et reprise automatiques pour Aurora Serverless v2

Vous pouvez spécifier que les instances de base de données Aurora Serverless v2 sont réduites verticalement à 0 ACU et qu’elles se mettent automatiquement en pause si aucune connexion n’est initiée par l’activité des utilisateurs au cours d’une période spécifiée. Pour ce faire, spécifiez une valeur ACU minimale correspondant à zéro pour votre cluster de bases de données. La capacité d’une instance ne vous est pas facturée lorsque l’instance est à l’état de pause. L’activation de la fonctionnalité de pause et de reprise automatiques (pause automatique) pour les clusters Aurora peu utilisés ou présentant des périodes d’inactivité prolongées peut vous aider à gérer les coûts de votre flotte de bases de données.

Note

La fonctionnalité de pause automatique est disponible pour Aurora Serverless v2 avec Aurora PostgreSQL et Aurora MySQL. Vous devrez peut-être mettre à niveau la version de votre moteur de base de données Aurora pour tirer parti de cette fonctionnalité. Pour déterminer les versions de moteur où une capacité minimale de 0 ACU est disponible, consultez Capacité Aurora Serverless v2.

Présentation de la fonctionnalité de pause automatique Aurora Serverless v2

Les instances de base de données Aurora Serverless v2 peuvent être mises en pause automatiquement après une période sans connexion utilisateur et reprendre automatiquement lorsqu’une demande de connexion arrive. La fonctionnalité de pause et de reprise automatiques d’Aurora Serverless v2 permet de gérer les coûts pour les systèmes qui ne sont pas soumis à un objectif de niveau de service (SLO) strict. Par exemple, vous pouvez activer cette fonctionnalité pour les clusters utilisés pour le développement et les tests, ou pour les applications internes où une courte pause est acceptable pendant le redémarrage de la base de données. Si votre charge de travail implique des périodes d’inactivité et peut tolérer de légers retards de connexion lors de la reprise de l’instance, envisagez de mettre en pause automatiquement vos instances Aurora Serverless v2 afin de réduire les coûts.

Pour contrôler ce comportement, spécifiez si les instances de base de données Aurora Serverless v2 d’un cluster peuvent être mises en pause automatiquement ou non, et pendant combien de temps chaque instance doit rester inactive avant de se mettre en pause. Pour activer le comportement de pause automatique pour toutes les instances de base de données Aurora Serverless v2 d’un cluster Aurora, définissez la valeur correspondant à la capacité minimale du cluster sur 0 ACU.

Si vous avez déjà tiré parti de la fonctionnalité d’Aurora Serverless v1 qui appliquait 0 ACU après une période d’inactivité, vous pouvez passer à Aurora Serverless v2 et utiliser sa fonctionnalité de pause automatique correspondante.

Les avantages en termes d’économies de coûts de la fonctionnalité de pause automatique sont similaires à ceux de l’utilisation de la fonctionnalité d’arrêt et de démarrage de cluster. La mise en pause automatique d’Aurora Serverless v2 présente les avantages supplémentaires d’une reprise plus rapide par rapport au démarrage d’un cluster arrêté et à l’automatisation du processus de détermination du moment de la pause et de la reprise de chaque instance de base de données.

La fonctionnalité de pause automatique fournit également une granularité supplémentaire dans le contrôle des coûts des ressources de calcul au sein de votre cluster. Vous pouvez activer la pause de certaines instances de lecteur même si l’instance de l’enregistreur et les autres lecteurs du cluster restent actifs en permanence. Pour ce faire, attribuez aux instances de lecteur qui peuvent être mises en pause indépendamment des autres instances une priorité de basculement comprise entre 2 et 15.

Les instances de l’enregistreur et toutes les instances de lecteur dont les priorités de basculement sont de 0 et 1 se mettent en pause et reprennent toujours en même temps. Ainsi, les instances de ce groupe se mettent en pause après qu’aucune connexion n’a eu lieu pendant l’intervalle de temps spécifié.

Les clusters de bases de données Aurora peuvent contenir une combinaison d’instances de base de données d’enregistreur et de lecteur, ainsi que d’instances de base de données et d’instances de base de données Aurora Serverless v2 provisionnées. Par conséquent, pour utiliser cette fonctionnalité de manière efficace, il est utile de comprendre les aspects suivants du mécanisme de pause automatique :

  • Circonstances dans lesquelles une instance de base de données peut se mettre automatiquement en pause.

  • Cas dans lesquels une instance de base de données ne peut pas se mettre en pause. Par exemple, l’activation de certaines fonctionnalités d’Aurora ou l’exécution de certains types d’opérations sur le cluster peuvent empêcher les instances de se mettre en pause, même en l’absence de connexion à ces instances.

  • Conséquences en matière de surveillance et de facturation lorsqu’une instance est mise en pause.

  • Actions pouvant entraîner la reprise du traitement par une instance de base de données.

  • Modification de la capacité d’une instance de base de données au moment des événements de pause et de reprise.

  • Comment contrôler l’intervalle d’inactivité avant la pause d’une instance de base de données.

  • Comment coder la logique de l’application pour gérer la période pendant laquelle une instance de base de données reprend le traitement.

Conditions préalables et limitations de la fonctionnalité Aurora Serverless v2 de pause automatique

Avant d’utiliser la fonctionnalité de pause automatique, vérifiez les versions de moteur à utiliser. Vérifiez également si la pause automatique fonctionne en combinaison avec les autres fonctionnalités Aurora que vous avez l’intention d’utiliser. Vous ne pouvez pas activer la pause automatique si vous utilisez une version de moteur qui ne la prend pas en charge. Pour les fonctionnalités incompatibles, aucune erreur ne s’affichera si vous les utilisez en combinaison avec la pause automatique. Si le cluster utilise des fonctionnalités ou des paramètres incompatibles, les instances Aurora Serverless v2 ne seront pas automatiquement mises en pause.

Certaines conditions ou certains paramètres empêchent les instances Aurora Serverless v2 de se mettre en pause automatiquement. Pour plus d’informations, consultez Situations dans lesquelles Aurora Serverless v2 n’applique pas de pause automatique.

Activation et désactivation de la fonctionnalité de pause automatique

Vous pouvez activer et désactiver la fonctionnalité de pause automatique au niveau du cluster. Pour cela, vous devez utiliser les mêmes procédures que lorsque vous ajustez la capacité minimale et maximale du cluster. La fonctionnalité de pause automatique est représentée par une capacité minimale de 0 ACU.

Activation de la pause automatique pour les instances Aurora Serverless v2 d’un cluster

Suivez la procédure décrite dans Définition de la plage de capacité Aurora Serverless v2 d’un cluster. Pour la capacité minimale, choisissez 0 ACU. Lorsque vous choisissez une capacité minimale de 0 ACU, vous pouvez également spécifier la durée pendant laquelle l’instance doit rester inactive avant qu’elle ne soit automatiquement mise en pause.

L’exemple d’interface de ligne de commande suivant montre comment créer un cluster Aurora en activant la fonctionnalité de pause automatique et en définissant l’intervalle de pause automatique sur 10 minutes (600 secondes). 

aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \
    --master-username myuser \
    --manage-master-user-password

L’exemple d’interface de ligne de commande suivant montre comment activer la fonctionnalité de pause automatique pour un cluster Aurora existant. Cet exemple définit l’intervalle de pause automatique sur une heure (3 600 secondes). 

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

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

Intervalle d’expiration configurable de la fonctionnalité Aurora Serverless v2 de pause automatique

L’intervalle d’expiration est représenté dans l’attribut ServerlessV2ScalingConfiguration de votre cluster Aurora. Vous pouvez spécifier cet intervalle dans la AWS Management Console lors de la création ou de la modification d’un cluster Aurora, si la capacité minimale est définie sur 0 ACU. Vous pouvez le spécifier dans l’AWS CLI en utilisant le paramètre --serverless-v2-scaling-configuration lors de la création ou de la modification d’un cluster Aurora. Vous pouvez le spécifier dans l’API RDS en utilisant le paramètre ServerlessV2ScalingConfiguration lors de la création ou de la modification d’un cluster Aurora.

L’intervalle minimum que vous pouvez définir est de 300 secondes (5 minutes). C’est la valeur par défaut si vous ne spécifiez aucun intervalle. L’intervalle maximum que vous pouvez définir est 86 400 secondes (1 journée).

Supposons que vous désactiviez la fonctionnalité de pause automatique pour un cluster en remplaçant la capacité minimale du cluster par une valeur différente de zéro. Dans ce cas, la propriété d’intervalle sera supprimée de l’attribut ServerlessV2ScalingConfiguration. L’absence de cette propriété fournit une confirmation supplémentaire que la fonctionnalité de pause automatique est désactivée pour ce cluster. Si vous réactivez ultérieurement la pause automatique, vous pourrez à nouveau spécifier un intervalle personnalisé à ce moment-là.

Reprise d’une instance Aurora Serverless v2 mise en pause automatique

  • Lorsque vous vous connectez à une instance Aurora Serverless v2 mise en pause, celle-ci reprend automatiquement et accepte la connexion.

  • Une tentative de connexion qui n’inclut pas d’informations d’identification valides entraîne tout de même la reprise de l’instance de base de données.

  • Si vous vous connectez via le point de terminaison de l’enregistreur, Aurora entame la reprise de l’instance de base de données de l’enregistreur si elle a été automatiquement mise en pause. Dans le même temps, Aurora reprend toutes les instances de lecteur mises en pause automatique dont la priorité de basculement est de 0 ou 1, ce qui signifie que leur capacité est liée à la capacité de l’instance de l’enregistreur.

  • Si vous vous connectez via le point de terminaison du lecteur, Aurora choisit une instance de lecteur de manière aléatoire. Si cette instance de lecteur est mise en pause, Aurora la reprend. Aurora reprend également l’instance de l’enregistreur en premier, car elle doit toujours être active si des instances de lecteur sont actives. Lorsqu’Aurora reprend cette instance d’enregistreur, cela entraîne également la reprise de toutes les instances de lecteur des niveaux 0 et 1 de la promotion de basculement.

  • Si vous envoyez une demande à votre cluster via l’API de données RDS, Aurora reprend l’instance de l’enregistreur si elle est mise en pause. Aurora traite ensuite la demande de l’API de données.

  • Lorsque vous modifiez la valeur d’un paramètre de configuration dans un groupe de paramètres de cluster de bases de données, Aurora reprend automatiquement toutes les instances Aurora Serverless v2 mises en pause dans tous les clusters qui utilisent ce groupe de paramètres de cluster. De même, lorsque vous modifiez la valeur d’un paramètre dans un groupe de paramètres de base de données, Aurora reprend automatiquement toutes les instances Aurora Serverless v2 mises en pause qui utilisent ce groupe de paramètres de base de données. Le même comportement de reprise automatique s’applique lorsque vous modifiez un cluster pour attribuer un autre groupe de paramètres de cluster, ou lorsque vous modifiez une instance pour attribuer un autre groupe de paramètres de base de données.

  • L’exécution d’une demande de retour en arrière permet de reprendre automatiquement l’instance d’enregistreur Aurora Serverless v2 si elle est mise en pause. Aurora traite la demande de retour en arrière une fois que l’instance d’enregistreur a repris ses activités. Vous pouvez revenir à une période pendant laquelle une instance Aurora Serverless v2 a été mise en pause.

  • La création d’un instantané de cluster ou la suppression d’un instantané n’entraîne la reprise d’aucune instance Aurora Serverless v2.

  • La création d’un clone Aurora oblige Aurora à reprendre l’instance d’enregistreur du cluster en cours de clonage.

  • Si une instance mise en pause reçoit un grand nombre de demandes de connexion avant la fin de sa reprise, il est possible que certaines sessions ne puissent pas se connecter. Nous recommandons d’implémenter une logique de nouvelle tentative pour les connexions aux clusters Aurora ayant certaines instances Aurora Serverless v2 pour lesquelles la pause automatique est activée. Par exemple, vous pouvez réessayer trois fois une connexion ayant échoué.

  • Aurora peut effectuer certains types de maintenance interne mineure sans mettre une instance hors veille. Cependant, certains types de maintenance qui ont lieu pendant la fenêtre de maintenance du cluster nécessitent qu’Aurora reprenne l’instance. Lorsque la maintenance est terminée, l’instance est automatiquement remise en pause s’il n’y a plus d’activité après l’intervalle spécifié.

    Note

    Aurora ne reprend pas automatiquement une instance mise en pause pour les tâches planifiées spécifiques au moteur, telles que celles de l’extension PostgreSQL pg_cron ou du planificateur d’événements MySQL. Pour garantir l’exécution de ces tâches, établissez une connexion manuelle avec l’instance avant l’heure planifiée. Aurora ne met en file d’attente aucune tâche lorsque l’heure planifiée a lieu alors que l’instance de base de données est mise en pause. Ces tâches seront ignorées lorsque l’instance reprendra ultérieurement.

  • Si le cluster Aurora subit un basculement alors qu’une instance Aurora Serverless v2 est mise en pause automatique, Aurora peut reprendre une instance, puis la promouvoir cette instance en tant qu’enregistreur. La même chose peut se produire si une ou plusieurs instances de base de données sont supprimées du cluster alors qu’une instance est mise en pause. Dans ce cas, l’instance deviendra l’enregistreur dès sa reprise.

  • Les opérations qui modifient les propriétés du cluster entraînent également la reprise des instances Aurora Serverless v2 mises en pause automatique. Par exemple, une instance mise en pause automatique reprend son activité pour des opérations telles que les suivantes :

    • Modification de la plage de mise à l’échelle du cluster.

    • Mise à niveau de la version du moteur du cluster.

    • Description ou téléchargement des fichiers journaux à partir d’une instance mise en pause. Vous pouvez examiner les données de journal historiques des instances en pause en activant le chargement des journaux vers CloudWatch et en analysant ces journaux via CloudWatch.

Désactivation de la pause automatique pour les instances Aurora Serverless v2 d’un cluster

Suivez la procédure décrite dans Définition de la plage de capacité Aurora Serverless v2 d’un cluster. Pour la capacité minimale, choisissez une valeur égale ou supérieure à 0,5. Lorsque vous désactivez la fonctionnalité de pause automatique, l’intervalle d’inactivité de l’instance est réinitialisé. Si vous réactivez la pause automatique, vous devez spécifier un nouvel intervalle d’expiration.

L’exemple d’interface de ligne de commande suivant montre comment désactiver la fonctionnalité de pause automatique pour un cluster Aurora existant. La sortie describe-db-clusters indique que l’attribut SecondsUntilAutoPause est supprimé lorsque la capacité minimale est définie sur une valeur différente de zéro. 

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

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

Fonctionnement de la pause automatique dans Aurora Serverless v2

Vous pouvez utiliser les informations suivantes pour planifier votre utilisation de la fonctionnalité de pause automatique. Comprendre les circonstances dans lesquelles les instances se mettent en pause, reprennent ou restent actives peut vous aider à trouver un juste milieu entre disponibilité, réactivité et économies de coûts.

Que se passe-t-il en cas de mise en pause d’instances Aurora Serverless v2

Lorsqu’une instance de base de données Aurora Serverless v2 se met en pause après une période sans connexion :

  • Aurora commence à mettre en pause l’instance une fois que l’intervalle spécifié s’est écoulé sans aucune connexion à l’instance, quel que soit le nombre d’ACU dont elle dispose à ce moment-là.

  • Le mécanisme de pause n’est pas instantané. Une instance Aurora Serverless v2 sur le point d’être mise en pause automatique peut attendre un court instant pour prendre en compte toutes les modifications apportées au stockage Aurora.

  • Les frais pour cette instance sont suspendus. La métrique ServerlessV2Usage a la valeur 0 lorsque l’instance est en pause.

  • La valeur d’état de l’instance ne change pas. L’état est toujours affiché comme « disponible ».

  • L’instance arrête d’écrire dans les fichiers journaux de la base de données. Elle arrête d’envoyer des métriques à CloudWatch, à part 0 % pour CPUUtilization et ACUUtilization, et 0 pour ServerlessDatabaseCapacity.

  • Aurora émet des événements lorsqu’une instance de base de données Aurora Serverless v2 commence à se mettre en pause ou met fin à sa pause et si le mécanisme de pause est interrompu ou échoue. Pour plus d’informations sur ces événements, consultez Événements d’instance de base de données.

Que se passe-t-il lorsque les instances Aurora Serverless v2 mises en pause automatiquement reprennent

Lorsqu’une instance de base de données Aurora Serverless v2 reprend après avoir été automatiquement mise en pause, les conditions suivantes s’appliquent :

  • Toutes les modifications de paramètres incluses dans les modifications pending-reboot sont appliquées lorsque l’instance reprend.

  • Aurora émet des événements au niveau de l’instance lorsque chaque instance de base de données Aurora Serverless v2 commence à reprendre son activité ou termine sa reprise et si l’instance ne peut pas reprendre pour une raison quelconque. Pour plus d’informations sur ces événements, consultez Événements d’instance de base de données.

  • Toutes les connexions demandées sont établies une fois que l’instance de base de données a fini de reprendre son activité. Le délai de reprise étant généralement d’environ 15 secondes, nous vous recommandons de régler les paramètres de délai d’expiration des clients pour qu’ils soient supérieurs à 15 secondes. Par exemple, dans les paramètres de votre pilote JDBC, vous pouvez ajuster les valeurs des paramètres connectTimeout et sslResponseTimeout pour qu’elles soient supérieures à 15 secondes.

Note

Si une instance Aurora Serverless v2 reste en pause pendant plus de 24 heures, Aurora peut la mettre en veille prolongée, ce qui lui prendra plus de temps pour reprendre. Dans ce cas, le temps de reprise peut être de 30 secondes ou plus, ce qui équivaut à peu près à un redémarrage de l’instance. Si votre base de données présente des périodes d’inactivité qui durent plus d’une journée, nous vous recommandons de définir des délais de connexion de 30 secondes ou plus.

Fonctionnement de la facturation des instances pour les clusters Aurora Serverless v2 mis en pause automatique

Lorsqu’une instance Aurora Serverless v2 est mise en pause automatiquement, ses frais d’instance sont nuls. La métrique ServerlessV2Usage est nulle pendant cette période. AWS facture toujours les frais de stockage Aurora et d’autres aspects du cluster qui ne sont pas liés à cette instance de base de données spécifique.

Situations dans lesquelles Aurora Serverless v2 n’applique pas de pause automatique

  • Si la valeur de capacité minimale de votre cluster de bases de données est supérieure à 0 ACU, les instances Aurora Serverless v2 du cluster ne sont pas automatiquement mises en pause. Si vous avez des clusters avec des instances Aurora Serverless v2 datant qui existaient avant que la fonctionnalité de pause automatique ne soit disponible, le paramètre de capacité minimale le plus bas était de 0,5 ACU. Pour utiliser la fonctionnalité de pause automatique avec ces clusters, remplacez le paramètre de capacité minimale par 0 ACU.

  • Si des connexions initiées par l’utilisateur sont ouvertes sur une instance Aurora Serverless v2, celle-ci ne sera pas mise en pause. L’instance ne se met pas non plus en pause pendant des activités telles que l’application de correctifs et les mises à niveau. Les connexions administratives utilisées par Aurora pour les surveillances de l’état ne sont pas considérées comme des activités et n’empêchent pas l’instance de se mettre en pause.

  • Dans un cluster Aurora PostgreSQL sur lequel la réplication logique est activée, ou dans un cluster Aurora MySQL sur lequel la réplication du journal binaire est activée, l’instance d’enregistreur et toutes les instances de lecteur dont le niveau de promotion de basculement correspond à 0 ou à 1 ne sont pas automatiquement mises en pause. Aurora effectue constamment un minimum d’activités pour vérifier l’état de la connexion de réplication.

    Pour les clusters sur lesquels la réplication est activée, vous pouvez toujours avoir des instances de lecteur Aurora dans le cluster source qui se mettent en pause automatiquement. Pour cela, définissez leur priorité de basculement sur une valeur autre que 0 ou 1. De cette façon, elles pourront être mises en pause indépendamment de l’instance d’enregistreur.

  • Si votre cluster Aurora est associé à un proxy RDS, ce dernier maintient une connexion ouverte avec chaque instance de base de données du cluster. Dès lors, aucune instance Aurora Serverless v2 d’un tel cluster n’est automatiquement mise en pause.

  • Si votre cluster est le cluster principal d’une base de données globale Aurora, Aurora ne met pas automatiquement en pause l’instance d’enregistreur Aurora Serverless v2. Cela est dû au fait qu’un niveau d’activité constant est nécessaire sur l’instance d’enregistreur pour pouvoir gérer les autres clusters de la base de données globale. Comme l’instance d’enregistreur reste active, toutes les instances de lecteur Aurora Serverless v2 dont la priorité de basculement est de 0 ou 1 ne sont pas mises en pause automatiquement.

  • Les instances Aurora Serverless v2 des clusters secondaires d’une base de données Aurora Global Database ne se mettent pas en pause automatiquement. Si un cluster de bases de données est promu qu statut de cluster autonome, la fonctionnalité de pause automatique devient effective si toutes les autres conditions sont remplies.

  • Dans un cluster associé à une intégration zéro ETL à Redshift, l’instance d’enregistreur et toutes les instances de lecteur des niveaux de promotion de basculement 0 et 1 en cas ne se mettent pas en pause automatiquement.

  • Outre l’activité sur le port de base de données principal de l’instance, si la fonctionnalité Babelfish est activée sur une instance Aurora PostgreSQL, toutes les connexions et activités sur le port T-SQL empêchent la mise en pause automatique de l’instance.

Fonctionnement de la pause automatique avec la fonctionnalité d’arrêt et de démarrage du cluster

Vous pouvez arrêter et démarrer un cluster Aurora lorsque la fonctionnalité de pause automatique est activée. Le fait que certaines instances soient mises en pause n’a pas d’importance. Lorsque vous redémarrez le cluster, toutes les instances Aurora Serverless v2 mises en pause reprennent automatiquement.

Lorsqu’un cluster Aurora est arrêté, les instances Aurora Serverless v2 mises en pause ne reprennent pas automatiquement en fonction des tentatives de connexion. Une fois le cluster redémarré, les mécanismes habituels de pause et de reprise des instances Aurora Serverless v2 s’appliquent.

Fonctionnement de la maintenance et des mises à niveau pour les clusters Aurora Serverless v2 mis en pause automatiquement

  • Lorsqu’une instance Aurora Serverless v2 est mise en pause automatiquement, si vous tentez de mettre à niveau le cluster Aurora, Aurora reprend l’instance et la met à niveau.

  • Aurora reprend régulièrement toutes les instances Aurora Serverless v2 mises en pause automatiquement pour effectuer des opérations de maintenance, telles que des mises à niveau de versions mineures et des modifications de propriétés telles que les groupes de paramètres.

  • Lorsqu’une instance Aurora Serverless v2 sort de son état de veille pour une opération administrative telle qu’une mise à niveau ou l’application d’une maintenance, Aurora attend au moins 20 minutes avant de mettre à nouveau cette instance en pause. L’objectif est de permettre à toutes les opérations en arrière-plan de se terminer. Cette période de 20 minutes permet également d’éviter de mettre en pause et de reprendre l’instance plusieurs fois si celle-ci subit plusieurs opérations administratives successives.

Différences du comportement de pause automatique entre Aurora Serverless v2 et Aurora Serverless v1

  • Le temps de reprise est amélioré dans Aurora Serverless v2 par rapport à Aurora Serverless v1. Le délai de reprise est généralement d’environ 15 secondes si l’instance a été mise en pause pendant moins de 24 heures. Si l’instance a été mise en pause pendant plus de 24 heures, le délai de reprise peut être plus long.

  • Avec la méthode appliquée par Aurora Serverless v2 aux clusters multi-AZ, certaines instances de base de données du cluster peuvent être mise en pause tandis que d’autres sont actives. L’instance de l’enregistreur reprend chaque fois qu’un lecteur est exécuté, car l’enregistreur est nécessaire pour coordonner certaines activités au sein du cluster. Comme Aurora Serverless v1 n’utilise pas d’instances de lecteur, l’ensemble du cluster serait toujours mis en pause ou actif.

  • Lorsque le point de terminaison du lecteur choisit au hasard une instance de lecteur à laquelle se connecter, cette instance peut déjà être active ou peut avoir été mise en pause automatiquement. Ainsi, le temps d’accès à l’instance de lecteur peut varier et être plus difficile à prévoir. Les clusters multi-AZ qui utilisent Aurora Serverless v2 et la mise en pause automatique peuvent donc bénéficier de la configuration de points de terminaison personnalisés pour des cas d’utilisation spécifiques en lecture seule, au lieu de diriger toutes les sessions en lecture seule vers le point de terminaison du lecteur.

  • Les instances Aurora Serverless v2 sont soumises à des opérations de maintenance à la même fréquence que les instances provisionnées. Étant donné qu’Aurora reprend automatiquement les instances lorsque ce type de maintenance est nécessaire, vous constaterez peut-être que les instances Aurora Serverless v2 reprennent plus fréquemment que les clusters Aurora Serverless v1.

Fonctionnement de la pause automatique Aurora Serverless v2 pour différents types de clusters Aurora

Les considérations relatives à la fonctionnalité de pause automatique dépendent du nombre d’instances présentes dans votre cluster Aurora, des niveaux de promotion du basculement des instances de lecteur et du fait que toutes les instances sont Aurora Serverless v2 ou une combinaison des Aurora Serverless v2 et d’instances provisionnées.

Lorsque la fonction de pause automatique est activée, vous pouvez organiser votre cluster Aurora de manière à trouver le juste équilibre entre haute disponibilité, réponse rapide et capacité de mise à l’échelle en fonction de votre cas d’utilisation. Pour ce faire, vous devez choisir la combinaison d’instances Aurora Serverless v2, d’instances provisionnées et de niveaux de promotion du basculement pour les instances de base de données de votre cluster.

Les types de configurations suivants présentent différents compromis entre haute disponibilité et optimisation des coûts pour votre cluster :

  • Pour un système de développement et de test, vous pouvez configurer un cluster de bases de données dans une seule zone de disponibilité avec une instance de base de données Aurora Serverless v2. Cette instance unique traite toutes les demandes de lecture et d’écriture. Lorsque le cluster n’est pas utilisé pendant des intervalles de temps importants, l’instance de base de données se met en pause. À ce stade, les coûts de calcul de la base de données pour votre cluster sont également mis en pause.

  • Pour un système exécutant une application où la haute disponibilité est une priorité, mais où le cluster reste totalement inactif pendant des périodes spécifiques, vous pouvez configurer un cluster multi-AZ dans lequel les instances de base de données d’enregistreur et de lecteur sont Aurora Serverless v2. Définissez l’instance de lecteur sur une priorité de basculement de 0 ou 1, de sorte que l’instance de l’enregistreur et celle du lecteur se mettent en pause et reprennent en même temps. Vous bénéficiez ainsi d’un basculement rapide lorsque le cluster est actif. Lorsque le cluster reste inactif pendant une durée supérieure au seuil de pause automatique, les frais d’instance de base de données pour les deux instances sont mis en pause. Lorsque le cluster reprend le traitement, la première session de base de données met peu de temps à se connecter.

  • Supposons que votre cluster soit constamment actif avec un minimum d’activité et qu’il nécessite une réponse rapide quelle que soit la connexion. Dans ce cas, vous pouvez créer un cluster avec plusieurs instances de lecteur Aurora Serverless v2 et dissocier les fonctionnalités de certaines instances de lecteur de celle de l’enregistreur. Spécifiez une priorité de basculement de 0 ou 1 pour l’instance d’enregistreur et pour une instance de lecteur. Spécifiez une priorité supérieure à 1 pour les autres instances de lecteur. Ainsi, les instances de lecteur situées dans les niveaux de priorité les plus élevés pourront être mises en pause automatiquement, même lorsque l’enregistreur et l’un des lecteurs restent actifs.

    Dans ce cas, vous pouvez utiliser d’autres techniques pour garantir que le cluster reste disponible en permanence tout en réduisant verticalement sa capacité pendant les périodes d’inactivité :

    • Vous pouvez utiliser des instances provisionnées pour l’enregistreur et le lecteur de priorité 0 ou 1. Ainsi, deux instances de base de données ne se mettent jamais en pause automatiquement et sont toujours disponibles pour traiter le trafic de base de données et effectuer des basculements.

    • Vous pouvez configurer un point de terminaison personnalisé qui inclut les instances Aurora Serverless v2 des niveaux de priorité les plus élevés, mais pas l’enregistreur ni les lecteurs des niveaux de promotion 0 ou 1. Ainsi, vous pouvez diriger les sessions en lecture seule qui ne sont pas sensibles à la latence vers des lecteurs susceptibles d’être mis en pause automatiquement. Vous pouvez éviter d’utiliser le point de terminaison du lecteur pour de telles demandes, car Aurora peut diriger les connexions de ce point de terminaison vers l’instance de lecteur qui reste active en permanence ou vers l’une des instances mises en pause automatiquement. L’utilisation du point de terminaison personnalisé vous permet de diriger les connexions vers différents groupes d’instances en fonction de vos préférences en matière de réponse rapide ou de mise à l’échelle supplémentaire.

Fonctionnement de la pause automatique Aurora Serverless v2 pour l’instance d’enregistreur d’un cluster de bases de données

Lorsqu’un cluster de bases de données Aurora ne contient qu’une seule instance de base de données, le mécanisme de pause et de reprise automatiques de l’instance de base de données est simple. Cela dépend uniquement de l’activité de l’instance de l’enregistreur. Vous pouvez utiliser cette configuration pour les clusters destinés au développement et aux tests, ou pour exécuter des applications où la haute disponibilité n’est pas cruciale. Notez que dans un cluster à instance unique, Aurora dirige les connexions via le point de terminaison du lecteur vers l’instance de base de données de l’enregistreur. Ainsi, pour un cluster de bases de données à instance unique, la tentative de connexion au point de terminaison du lecteur entraîne la reprise de l’instance de base de données d’enregistreur mise en pause automatiquement.

Les facteurs supplémentaires suivants s’appliquent aux clusters Aurora dotés de plusieurs instances de base de données :

  • Dans un cluster de bases de données Aurora, l’accès à l’instance de base de données de l’enregistreur est généralement fréquent. Par conséquent, il se peut que l’instance de base de données de l’enregistreur reste active même lorsqu’une ou plusieurs instances de base de données du lecteur se mettent en pause automatiquement.

  • Certaines activités sur les instances de base de données du lecteur nécessitent que cette instance de base de données de l’enregistreur soit disponible. Par conséquent, les instances de base de données de l’enregistreur ne peuvent pas être mises en pause tant que toutes les instances du lecteur ne le sont pas également. La reprise d’une instance de lecteur entraîne automatiquement la reprise de l’instance d’enregistreur, même si votre application n’y accède pas directement.

  • Les instances de lecteur Aurora Serverless v2 dont les niveaux de promotion du basculement correspondent à 0 et 1 se mettent à l’échelle pour maintenir leur capacité synchronisée avec l’instance d’enregistreur. Ainsi, lorsqu’une instance d’enregistreur Aurora Serverless v2 reprend, il en va de même pour toutes les instances de lecteur Aurora Serverless v2 dont les niveaux de promotion correspondent à 0 ou 1.

Fonctionnement de la pause automatique Aurora Serverless v2 pour les clusters multi-AZ

Dans un cluster de bases de données Aurora contenant à la fois une instance de base de données d’enregistreur et une ou plusieurs instances de base de données de lecteur, certaines instances de base de données Aurora Serverless v2 peuvent être suspendues tandis que d’autres sont actives. L’instance d’enregistreur et toutes les instances de lecteur dont les priorités de basculement sont de 0 et 1 se mettent en pause et reprennent toujours en même temps. Les instances de lecteur dont la priorité est différente de 0 ou 1 peuvent se mettre en pause et reprendre indépendamment des autres instances.

Lorsque vous utilisez cette fonctionnalité pour des clusters comportant plusieurs instances de lecteur, vous pouvez gérer les coûts sans sacrifier la haute disponibilité. L’instance d’enregistreur et une ou deux autres instances de lecteur peuvent rester actives en permanence, tandis que les autres instances de lecteur peuvent se mettre en pause lorsqu’elles ne sont pas nécessaires pour gérer un trafic de lecture important.

Le fait qu’une instance de lecteur puisse être automatiquement mise en pause dépend de sa capacité à se mettre à l’échelle indépendamment ou du fait que la capacité est liée à celle de l’instance de base de données de l’enregistreur. Cette propriété de mise à l’échelle dépend de la priorité de basculement de l’instance de base de données du lecteur. Lorsque la priorité du lecteur est de 0 ou 1, la capacité du lecteur suit la capacité de l’instance de base de données de l’enregistreur. Par conséquent, pour permettre aux instances de base de données du lecteur de se mettre en pause automatiquement dans le plus large éventail de situations, définissez leur priorité sur une valeur supérieure à 1.

Le délai de reprise d’une instance de lecteur peut être légèrement plus long que celui d’une instance d’enregistreur. Pour obtenir une réponse rapide en cas de mise en pause d’instances, connectez-vous au point de terminaison du cluster.

Fonctionnement de la pause automatique Aurora Serverless v2 pour les clusters dotés d’instances provisionnées

Aucune instance de base de données provisionnée dans votre cluster de bases de données Aurora ne se met en pause automatiquement. Seules les instances de base de données Aurora Serverless v2, avec la classe d’instance db.serverless, peuvent utiliser la fonctionnalité de pause automatique.

Lorsque votre cluster Aurora contient des instances de base de données provisionnées, aucune instance d’enregistreur Aurora Serverless v2 ne se met en pause automatiquement. Cela est dû au fait que l’instance d’enregistreur doit rester disponible tant que toutes les instances de lecteur sont actives. Le fait que l’enregistreur Aurora Serverless v2 reste actif signifie également que les instances de lecteur Aurora Serverless v2 dont les priorités de basculement sont de 0 ou 1 ne se mettent pas en pause automatiquement dans un cluster hybride contenant des instances provisionnées.

Surveillance des clusters Aurora utilisant la pause automatique

Pour surveiller Aurora, vous devez déjà connaître les procédures de surveillance indiquées dans Surveillance des métriques Amazon Aurora avec Amazon CloudWatch et les métriques CloudWatch répertoriées dans Référence des métriques pour Amazon Aurora. Sachez que certaines considérations particulières doivent être prises en compte lorsque vous surveillez des clusters Aurora qui utilisent la fonctionnalité de pause automatique :

  • Il peut y avoir des périodes pendant lesquelles les instances Aurora Serverless v2 n’enregistrent pas les données de journal ni la plupart des métriques, car elles sont en pause. Les seules métriques envoyées à CloudWatch lorsqu’une instance est en pause sont 0 % pour CPUUtilization et ACUUtilization, et 0 pour ServerlessDatabaseCapacity.

  • Vous pouvez vérifier si les instances Aurora Serverless v2 se mettent en pause plus ou moins fréquemment que prévu. Pour ce faire, vérifiez à quelle fréquence la métrique ServerlessDatabaseCapacity passe d’une valeur différente de zéro à zéro, et combien de temps elle reste nulle. Si les instances ne restent pas en pause aussi longtemps que prévu, vous n’économiserez pas autant que vous le pourriez en termes de coûts. Si les instances se mettent en pause et reprennent plus fréquemment que prévu, il se peut que votre cluster subisse une latence inutile lorsqu’il répond aux demandes de connexion. Pour plus d’informations sur les facteurs qui déterminent si les instances Aurora Serverless v2peuvent se mettre en pause et à quelle fréquence, consultez Conditions préalables et limitations de la fonctionnalité Aurora Serverless v2 de pause automatique, Situations dans lesquelles Aurora Serverless v2 n’applique pas de pause automatique et Résolution des problèmes liés à la pause automatique Aurora Serverless v2.

  • Vous pouvez également examiner un fichier journal qui enregistre les opérations de pause et de reprise automatiques pour une instance Aurora Serverless v2. Si une instance n’a pas été mise en pause après le délai d’expiration, ce fichier journal indique également la raison pour laquelle la pause automatique n’a pas eu lieu. Pour plus d’informations, consultez Surveillance de l’activité de mise en pause et de reprise d’Aurora Serverless v2.

Vérifier si une instance Aurora Serverless v2 est mise en pause

Pour déterminer si une instance Aurora Serverless v2 est en état de pause, vous pouvez observer sa métrique ACUUtilization. Cette métrique a la valeur 0 lorsque l’instance est en pause.

Lorsqu’une instance Aurora Serverless v2 est mise en pause, la valeur de son état apparaît toujours comme étant Disponible. Il en va de même lorsqu’une instance Aurora Serverless v2 mise en pause est en cours de reprise. Cela est dû au fait que vous pouvez vous connecter avec succès à ce type d’instance, même si la connexion est légèrement retardée.

Toutes les métriques liées à la disponibilité des instances Aurora prennent en compte la période pendant laquelle l’instance est en pause comme une période de disponibilité.

Événements pour les opérations de pause et de reprise automatiques

Aurora émet des événements pour les instances Aurora Serverless v2 lorsque les opérations de pause et de reprise automatiques démarrent, se terminent ou sont annulées. Les événements liés à la fonction de pause automatique sont compris entre RDS-EVENT-0370 et RDS-EVENT-0374. Pour plus d’informations sur ces événements, consultez Événements d’instance de base de données.

Fonctionnement de la pause automatique avec Performance Insights et la surveillance améliorée

Lorsqu’une instance Aurora Serverless v2 est mise en pause, Aurora ne collecte pas d’informations de surveillance pour cette instance via Performance Insights ou la surveillance améliorée. Lorsque l’instance reprend, il se peut qu’il y ait un bref délai avant qu’Aurora ne recommence à collecter ces informations de surveillance.

Interactions de la fonctionnalité Aurora Serverless v2 de pause automatique avec les métriques Aurora

Lorsqu’une instance Aurora Serverless v2 est mise en pause, elle n’émet pas la plupart des métriques CloudWatch et n’écrit aucune information dans les journaux de sa base de données. Les seules métriques envoyées à CloudWatch lorsqu’une instance est en pause sont 0 % pour CPUUtilization et ACUUtilization, et 0 pour ServerlessDatabaseCapacity.

Lorsque CloudWatch calcule des statistiques relatives à la disponibilité et à la durée de fonctionnement des instances ou des clusters, les instances Aurora Serverless v2 sont considérées comme disponibles pendant la période de mise en pause.

Lorsque vous lancez une action de l’AWS CLI ou de l’API RDS pour décrire ou télécharger les journaux d’une instance Aurora Serverless v2 mise en pause, cette instance reprend automatiquement pour rendre les informations du journal disponibles.

Exemple de métriques CloudWatch

Les exemples AWS CLI suivants montrent comment observer l’évolution de la capacité d’une instance au fil du temps. Au cours de cette période, l’instance se met automatiquement en pause puis reprend. Lorsqu’elle est en pause, la métrique ServerlessDatabaseCapacity indique la valeur 0. Pour déterminer si l’instance a été mise en pause à un moment quelconque au cours de la période, nous vérifions si la capacité minimale pendant cette période a été nulle.

L’exemple Linux suivant représente une instance Aurora Serverless v2 qui a été automatiquement mise en pause pendant un certain temps. Nous échantillonnons ServerlessDatabaseCapacity chaque minute, sur une période de trois minutes. Une valeur d’ACU minimale de 0,0 confirme que l’instance a été mise en pause à un moment donné au cours de chaque minute. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:11:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:12:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None

Ensuite, nous essayons d’établir une connexion avec l’instance Aurora Serverless v2 mise en pause. Dans cet exemple, nous utilisons intentionnellement un mot de passe incorrect afin que la tentative de connexion échoue. Malgré cet échec, la tentative de connexion oblige Aurora à reprendre l’instance mise en pause. 


$ mysql -h my_cluster_endpoint.rds.amazonaws.com -u admin -pwrong-password

ERROR 1045 (28000): Access denied for user 'admin'@'ip_address' (using password: YES)

L’exemple Linux suivant montre que l’instance mise en pause a repris, est restée inactive pendant environ cinq minutes, puis est revenue à son état de pause. L’instance a repris à une capacité de 2,0 ACU. Ensuite, elle a légèrement augmenté verticalement, par exemple pour effectuer un nettoyage interne. Comme elle n’a reçu aucune tentative de connexion utilisateur dans le délai de cinq minutes, elle est directement passée de 4 ACU à l’état de pause. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
DATAPOINTS	2.0	2024-08-02T22:14:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:15:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:16:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:17:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:18:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:19:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:20:00+00:00	None

Si le rapport était destiné à montrer à quelle vitesse l’instance a augmenté verticalement pour gérer la charge de travail, nous pouvons spécifier Maximum pour la statistique au lieu de Minimum. Pour la planification de la capacité et l’estimation des coûts, nous pouvons spécifier une période plus longue et utiliser la statistique Average. De cette façon, nous avons pu déterminer les valeurs de capacité typiques pendant les périodes de forte activité, de faible activité et d’état de pause. Pour examiner le comportement aux moments précis où la pause et la reprise ont lieu, nous pouvons spécifier une période d’une seconde et examiner un intervalle de temps plus court. Les valeurs d’horodatage figurant dans la sortie, par exemple 2024-08-02T22:13:00+00:00, indiquent le format permettant de spécifier des paramètres précis pour les options --start-time et --end-time.

Résolution des problèmes liés à la pause automatique Aurora Serverless v2

Si vous constatez que les instances Aurora Serverless v2 ne se mettent pas en pause aussi souvent que prévu, recherchez les causes possibles suivantes :

  • Vérifiez que la version d’Aurora que vous utilisez prend en charge une capacité minimale de 0 ACU. Pour en savoir plus sur les plages de capacité des différentes versions d’Aurora, consultez Capacité Aurora Serverless v2.

  • Vérifiez que la valeur de capacité minimale du cluster est définie sur 0 ACU.

  • Vérifiez que l’instance en question utilise réellement la classe d’instance Aurora Serverless v2 db.serverless, et non l’une des classes d’instance provisionnées.

  • Vérifiez que le cluster n’utilise aucun des paramètres ou fonctionnalités incompatibles à partir de Conditions préalables et limitations de la fonctionnalité Aurora Serverless v2 de pause automatique.

  • Examinez le fichier journal indiquant à quel moment les instances Aurora Serverless v2 ont été mises en pause ou reprises, ou à quel moment Aurora n’a pas pu mettre en pause ou reprendre une instance pour une raison ou une autre. Pour plus d’informations, consultez Surveillance de l’activité de mise en pause et de reprise d’Aurora Serverless v2.

  • Vérifiez si des clients ou des applications maintiennent les connexions ouvertes pendant de longues périodes. À l’inverse, vérifiez si des applications utilisant l’API de données RDS ou les fonctions Lambda envoient des demandes fréquentes afin que l’instance ne soit jamais inactive assez longtemps pour être mise en pause. Vous pouvez examiner les métriques CloudWatch telles que ConnectionAttempts et DatabaseConnections. Pour plus d’informations, consultez Métriques de niveau instance pour Amazon Aurora.

  • Si une instance de lecteur se met rarement en pause, voire jamais, vérifiez sa priorité de basculement. Si le lecteur est utilisé pour la mise à l’échelle de la lecture et non comme lecteur de secours en cas de basculement, définissez sa priorité sur une valeur comprise entre 2 et 15.

  • Si l’instance d’enregistreur se met rarement en pause, voire jamais, vérifiez l’utilisation des instances de lecteur. L’enregistreur ne peut se mettre en pause que si l’ensemble du cluster est inactif. Cela est dû au fait qu’une connexion à une instance de lecteur entraîne la reprise de l’enregistreur.

  • Si votre application reçoit des délais d’expiration lors des demandes de connexion alors que les instances Aurora Serverless v2 reprennent leur activité, envisagez de prolonger l’intervalle d’expiration utilisé par le code de votre application ou le cadre de base de données sous-jacent. Des délais de connexion plus longs réduisent le risque d’échec des connexions lors de la reprise des instances Aurora Serverless v2. Cependant, les délais d’attente plus longs peuvent également ralentir la détection des problèmes de disponibilité dans votre cluster par votre application.

    À l’inverse, envisagez d’allonger l’intervalle de pause automatique afin que les applications ne trouvent pas aussi souvent d’instances en pause.

    S’il n’existe pas d’équilibre logique entre le comportement de pause automatique et la réactivité du cluster pour votre application, ce cluster n’est peut-être pas adapté à la fonctionnalité de pause automatique.

  • Si vous estimez la durée pendant laquelle vos instances Aurora Serverless v2 sont mises en pause, sachez que certains facteurs empêchent de faire des prévisions précises.

    • Les instances peuvent reprendre périodiquement pour effectuer des opérations de maintenance, pour appliquer des mises à niveau de versions mineures ou pour apporter des modifications à des groupes de paramètres.

    • Pour les clusters multi-AZ, il existe des situations dans lesquelles la reprise d’une instance entraîne également la reprise d’autres instances. La reprise d’un lecteur entraîne toujours la reprise de l’enregistreur. La reprise de l’enregistreur entraîne toujours la reprise des lecteurs dont les priorités de basculement sont de 0 ou 1.

    Nous recommandons de mesurer le temps de pause réel sur une période de plusieurs jours, avec une charge de travail réaliste. Utilisez ensuite ces mesures pour définir une base de référence pour la durée prévue de pause d’une instance.

  • Vous constaterez peut-être que des opérations internes telles que la purge MySQL, le planificateur d’événements MySQL, l’autovacuum de PostgreSQL ou les tâches PostgreSQL planifiées via l’extension pg_cron ne s’exécutent pas ou ne se terminent pas. L’instance ne reprend pas automatiquement pour effectuer ce type d’opérations qui n’impliquent pas de connexion utilisateur à la base de données. Si ce type d’opérations internes est en cours à l’expiration de la pause automatique, les tâches de maintenance telles que la purge MySQL et l’autovacuum de PostgreSQL sont annulées. Les tâches planifiées à partir du planificateur d’événements MySQL ou de l’extension PostgreSQL pg_cron sont également annulées si elles sont en cours au moment où Aurora lance l’opération de pause.

    Si vous devez vous assurer que l’instance est régulièrement active afin de pouvoir effectuer les opérations planifiées, vous pouvez lancer une connexion pour que l’instance reprenne avant l’heure de début de la tâche. Vous pouvez également augmenter l’intervalle de pause automatique afin que les opérations telles que l’autovacuum puissent s’exécuter plus longtemps une fois l’activité de l’utilisateur terminée. Vous pouvez également utiliser des mécanismes tels que les fonctions Lambda pour effectuer des opérations de base de données selon un calendrier, de manière à ce que l’instance reprenne automatiquement si nécessaire.

Considérations relatives à la conception de la fonctionnalité Aurora Serverless v2 de pause automatique

Lorsqu’une instance de base de données Aurora Serverless v2 reprend après avoir été automatiquement mise en pause, elle commence avec une capacité relativement faible et augmente verticalement à partir de là. Cette capacité de départ s’applique même si l’instance de base de données avait une capacité supérieure juste avant sa mise en pause automatique.

Utilisez cette fonctionnalité avec les applications qui peuvent tolérer un intervalle d’environ 15 secondes lors de l’établissement d’une connexion. Cela tient compte du cas typique où une instance Aurora Serverless v2 reprend en raison d’une seule connexion entrante ou de quelques-unes. Si l’instance a été mise en pause pendant plus de 24 heures, le délai de reprise peut être plus long.

Si votre application utilisait déjà Aurora Serverless v1 et sa fonctionnalité de pause automatique, vous avez peut-être déjà mis en place de tels intervalles d’expiration pour les tentatives de connexion. Si vous utilisez déjà Aurora Serverless v2 en combinaison avec la fonctionnalité Aurora d’arrêt et de démarrage de cluster, le temps de reprise des instances Aurora Serverless v2 mises en pause automatiquement est généralement beaucoup plus court que le temps de démarrage d’un cluster arrêté.

Lorsque vous codez la logique de connexion de votre application, réessayez la connexion si la première tentative renvoie une erreur dont la cause est passagère. (Si l’erreur est due à un échec d’authentification, corrigez les informations d’identification avant de réessayer.) Une erreur qui se produit juste après la reprise peut être due à l’expiration d’un délai ou aux limites de la base de données. Une nouvelle tentative peut résoudre les problèmes dans les cas plus rares où une instance Aurora Serverless v2 reprend en raison d’un nombre élevé de demandes de connexion simultanées. Dans ce cas, le traitement de certaines connexions peut prendre plus de temps que d’habitude ou dépasser la limite de connexions simultanées lors de la première tentative.

Pendant le développement et le débogage de l’application, ne laissez pas les sessions client ni les outils de programmation avec des connexions ouvertes à la base de données. Aurora ne met pas en pause une instance si des connexions initiées par l’utilisateur sont ouvertes, même si ces connexions n’exécutent aucune instruction ou transaction SQL. Lorsqu’une seule instance Aurora Serverless v2 d’un cluster Aurora ne peut pas être mise en pause, la mise en pause d’autres instances de ce cluster peut également échouer. Pour plus d’informations, consultez Situations dans lesquelles Aurora Serverless v2 n’applique pas de pause automatique.

Aurora émet des événements lorsqu’une instance de base de données Aurora Serverless v2 commence à reprendre son activité ou termine sa reprise et si l’instance ne peut pas reprendre pour une raison quelconque. Pour plus d’informations sur ces événements, consultez Événements d’instance de base de données.