Mise à l'échelle jusqu'à zéro ACUs 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 Comment fonctionne la pause automatique Configurations de pause automatique et de cluster Aurora Surveillance de la pause automatique Résolution des problèmes liés à la pause automatique Conception d'applications pour 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.

Mise à l'échelle jusqu'à zéro ACUs avec pause et reprise automatiques pour Aurora Serverless v2

Vous pouvez spécifier que Aurora Serverless v2 Les instances de base de données sont réduites à zéro ACUs et s'interrompent automatiquement 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 ACU valeur minimale de zéro pour votre cluster de base de données. La capacité de l'instance ne vous est pas facturée lorsqu'une instance est en 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 parc de bases de données.

Note

La fonction de pause automatique est disponible pour Aurora Serverless v2 avec Aurora Postgre SQL 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 les versions de moteur où une capacité minimale de 0 ACUs est disponible, voirAurora Serverless v2 capacity.

Vue d'ensemble du Aurora Serverless v2 fonction de pause automatique

Aurora Serverless v2 Les instances de base de données peuvent être mises en pause automatiquement après une période sans connexion utilisateur et reprendre automatiquement lorsqu'une demande de connexion arrive. Le Aurora Serverless v2 la fonction de pause/reprise automatique permet de gérer les coûts pour les systèmes qui n'ont pas d'objectif de niveau de service strict ()SLO. 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 comporte des périodes d'inactivité et peut tolérer de légers retards de connexion lors de la reprise de l'instance, envisagez d'utiliser la pause automatique avec votre Aurora Serverless v2 instances pour réduire les coûts.

Vous pouvez contrôler ce comportement en spécifiant si Aurora Serverless v2 Les instances de base de données d'un cluster peuvent être mises en pause automatiquement ou non, et la durée pendant laquelle chaque instance doit rester inactive avant de s'interrompre. Pour activer le comportement de pause automatique pour tous les Aurora Serverless v2 Instances de base de données dans un cluster Aurora, vous définissez la valeur de capacité minimale du cluster sur zéroACUs.

Si vous avez déjà profité du Aurora Serverless v1 fonctionnalité redimensionnée à zéro ACUs après une période d'inactivité, vous pouvez passer à Aurora Serverless v2 et utilisez la fonction de pause automatique correspondante.

Les avantages en termes d'économies de coûts de la fonction de pause automatique sont similaires à ceux de l'utilisation de la fonction de cluster arrêt/démarrage. Pause automatique pour Aurora Serverless v2 présente les avantages supplémentaires d'une reprise plus rapide que le démarrage d'un cluster arrêté et de 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 fonction 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 rédacteur et les autres lecteurs du cluster restent actifs à tout moment. 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 du rédacteur et toutes les instances du lecteur dont les priorités de basculement sont 0 et 1 s'interrompent et reprennent toujours en même temps. Ainsi, les instances de ce groupe s'interrompent après qu'aucune d'entre elles n'ait de connexion pendant l'intervalle de temps spécifié.

Les clusters de base de données Aurora peuvent contenir une combinaison d'instances de base de données d'écriture et de lecture et provisionnés et Aurora Serverless v2 Instances de base de donné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 être automatiquement interrompue.

  • Quand une instance de base de données peut être empêchée de se suspendre. 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 s'arrêter, même en l'absence de connexion à ces instances.

  • Les conséquences pour la surveillance et la facturation lorsqu'une instance est suspendue.

  • Quelles actions entraînent la reprise du traitement par une instance de base de données ?

  • Comment la capacité d'une instance de base de données change 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 limites du Aurora Serverless v2 fonction de pause automatique

Avant d'utiliser la fonction de pause automatique, vérifiez les versions du moteur à utiliser. Vérifiez également si la pause automatique fonctionne en combinaison avec les autres fonctionnalités d'Aurora que vous avez l'intention d'utiliser. Vous ne pouvez pas activer la pause automatique si vous utilisez une version du 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 une pause automatique. Si le cluster utilise des fonctionnalités ou des paramètres incompatibles, Aurora Serverless v2 les instances ne seront pas automatiquement mises en pause.

Certaines conditions ou certains paramètres empêchent Aurora Serverless v2 les instances ne sont pas mises en pause automatiquement. Pour de plus amples informations, veuillez consulter Situations dans lesquelles Aurora Serverless v2 ne s'arrête pas automatiquement.

Activation et désactivation de la fonction de pause automatique

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

Activer la pause automatique pour Aurora Serverless v2 instances d'un cluster

Suivez la procédure décrite dans Réglage du Aurora Serverless v2 plage de capacité pour un cluster. Pour la capacité minimale, choisissez 0ACUs. Lorsque vous choisissez une capacité minimale de 0ACUs, vous pouvez également spécifier la durée pendant laquelle l'instance doit être inactive avant qu'elle ne soit automatiquement mise en pause.

L'CLIexemple suivant montre comment créer un cluster Aurora avec la fonctionnalité de pause automatique activée et l'intervalle de pause automatique défini sur dix 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'CLIexemple suivant montre comment activer la fonctionnalité de pause automatique pour un cluster Aurora existant. Cet exemple définit l'intervalle de pause automatique à 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
}

Configurable Aurora Serverless v2 intervalle de temporisation de pause automatique

L'intervalle de temporisation est représenté dans l'ServerlessV2ScalingConfigurationattribut de votre cluster Aurora. Vous pouvez spécifier cet intervalle AWS Management Console lors de la création ou de la modification d'un cluster Aurora, si la capacité minimale est définie sur zéroACUs. Vous pouvez le spécifier dans le en AWS CLI utilisant le --serverless-v2-scaling-configuration paramètre lors de la création ou de la modification d'un cluster Aurora. Vous pouvez le spécifier dans le en RDS API utilisant le ServerlessV2ScalingConfiguration paramètre 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 (cinq minutes). Il s'agit de la valeur par défaut si vous ne spécifiez aucun intervalle. L'intervalle maximum que vous pouvez définir est de 86 400 secondes (un jour).

Supposons que vous désactiviez la fonction de pause automatique pour un cluster en modifiant la capacité minimale du cluster à une valeur différente de zéro. Dans ce cas, la propriété interval est supprimée de l'ServerlessV2ScalingConfigurationattribut. 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 pouvez à nouveau spécifier un intervalle personnalisé à ce moment-là.

Reprise d'une pause automatique Aurora Serverless v2 instance

  • Lorsque vous vous connectez à un Aurora Serverless v2 Par exemple, il reprend et accepte automatiquement la connexion.

  • Une tentative de connexion qui n'inclut pas d'informations d'identification valides entraîne toujours la reprise de l'instance de base de données.

  • Si vous vous connectez via le point de terminaison du rédacteur, Aurora reprend l'instance de base de données du rédacteur si elle est automatiquement suspendue. Dans le même temps, Aurora reprend toutes les instances de lecteur mises en pause automatique dont la priorité de basculement est 0 ou 1, ce qui signifie que leur capacité est liée à la capacité de l'instance d'écriture.

  • 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 suspendue, Aurora la reprend. Aurora reprend également l'instance d'écriture en premier, car l'instance de rédacteur doit toujours être active si des instances de lecteur sont actives. Lorsque Aurora reprend cette instance de rédacteur, cela entraîne également la reprise de toutes les instances de lecteur des niveaux zéro et un de la promotion Failover.

  • Si vous envoyez une demande à votre cluster via les RDS donnéesAPI, Aurora reprend l'instance du rédacteur si elle est suspendue. Aurora traite ensuite la API demande de données.

  • Lorsque vous modifiez la valeur d'un paramètre de configuration dans un groupe de paramètres de cluster de base de données, Aurora reprend automatiquement toute pause Aurora Serverless v2 instances de 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 toute pause Aurora Serverless v2 instances 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 entraîne automatiquement la reprise du Aurora Serverless v2 instance d'écriture si elle est en pause. Aurora traite la demande de retour en arrière une fois que l'instance du rédacteur a repris ses activités. Vous pouvez revenir à une époque où un Aurora Serverless v2 l'instance a été suspendue.

  • La prise d'un instantané du cluster ou la suppression d'un instantané n'en entraîne aucune Aurora Serverless v2 instances à reprendre.

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

  • Si une instance suspendue 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 vous recommandons d'implémenter une logique de nouvelle tentative pour les connexions aux clusters Aurora dotés de Aurora Serverless v2 instances avec pause automatique activée. Par exemple, vous pouvez réessayer trois fois une connexion ayant échoué.

  • Aurora peut effectuer certains types de maintenance interne mineure sans réveiller une instance. 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 suspendue à nouveau s'il n'y a plus d'activité après l'intervalle spécifié.

    Note

    Aurora ne reprend pas automatiquement une instance suspendue pour les tâches planifiées spécifiques au moteur, telles que celles de l'SQLpg_cronextension Postgre ou du planificateur d'événements My. SQL 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 se produit alors que l'instance de base de données est suspendue. Ces tâches sont ignorées lorsque l'instance reprend ultérieurement.

  • Si le cluster Aurora subit un basculement alors qu'un Aurora Serverless v2 l'instance est mise en pause automatiquement, Aurora peut reprendre une instance puis promouvoir cette instance en tant que rédactrice. 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 suspendue. Dans ce cas, l'instance devient le rédacteur dès sa reprise.

  • Les opérations qui modifient les propriétés du cluster entraînent également une suspension automatique Aurora Serverless v2 instances à reprendre. Par exemple, une instance mise en pause automatique reprend 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.

    • Décrire ou télécharger des fichiers journaux à partir d'une instance suspendue. Vous pouvez examiner les données de journal historiques des instances en pause en activant le téléchargement des journaux CloudWatch et en analysant les journaux par le biais de ces derniers. CloudWatch

Désactiver la pause automatique pour Aurora Serverless v2 instances d'un cluster

Suivez la procédure décrite dans Réglage du Aurora Serverless v2 plage de capacité pour un cluster. Pour la capacité minimale, choisissez une valeur égale ou supérieure à 0,5. Lorsque vous désactivez la fonction de pause automatique, l'intervalle d'inactivité de l'instance est réinitialisé. Si vous réactivez la pause automatique, vous spécifiez un nouvel intervalle de temporisation.

L'CLIexemple suivant montre comment désactiver la fonctionnalité de pause automatique pour un cluster Aurora existant. La describe-db-clusters sortie indique que l'SecondsUntilAutoPauseattribut 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
}

Comment le Aurora Serverless v2 la fonction de pause automatique fonctionne

Vous pouvez utiliser les informations suivantes pour planifier votre utilisation de la fonction de pause automatique. Comprendre les circonstances dans lesquelles les instances s'interrompent, reprennent ou restent actives peut vous aider à trouver un équilibre entre disponibilité, réactivité et économies de coûts.

Que se passe-t-il lorsque Aurora Serverless v2 pause des instances

Quand un Aurora Serverless v2 L'instance de base de données s'arrête après une période sans connexion :

  • Aurora commence à suspendre l'instance une fois l'intervalle spécifié écoulé sans aucune connexion à l'instance, quel que soit le nombre de connexions de ACUs l'instance à ce moment-là.

  • Le mécanisme de pause n'est pas instantané. Un Aurora Serverless v2 Une instance sur le point d'être mise en pause automatique peut attendre brièvement pour suivre toutes les modifications apportées au stockage Aurora.

  • Les frais d'instance pour cette instance sont suspendus. La ServerlessV2Usage métrique a une valeur de 0 lorsque l'instance est en pause.

  • La valeur du statut de l'instance ne change pas. Le statut est toujours affiché comme « disponible ».

  • L'instance arrête d'écrire dans les fichiers journaux de la base de données. Il arrête d'envoyer des métriques à CloudWatch, sauf en enregistrant zéro pour cent pour CPUUtilization etACUUtilization, et zéro pourServerlessDatabaseCapacity.

  • Aurora émet des événements lorsqu'un Aurora Serverless v2 L'instance de base de données commence la pause, termine la pause et si le mécanisme de pause est interrompu ou échoue. Pour plus de détails sur ces événements, consultezÉvènements d'instance de base de données.

Que se passe-t-il en cas de pause automatique Aurora Serverless v2 les instances reprennent

Quand un Aurora Serverless v2 L'instance de base de données reprend après avoir été automatiquement suspendue, les conditions suivantes s'appliquent :

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

  • Aurora émet des événements au niveau de l'instance lorsque chaque Aurora Serverless v2 L'instance de base de données commence à reprendre, termine sa reprise et si l'instance ne peut pas reprendre pour une raison quelconque. Pour plus de détails 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 ses activités. 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 JDBC pilote, vous pouvez ajuster les valeurs des sslResponseTimeout paramètres connectTimeout et pour qu'elles soient supérieures à 15 secondes.

Note

Si un Aurora Serverless v2 l'instance reste en pause pendant plus de 24 heures, Aurora peut mettre l'instance en veille plus profonde dont la reprise prend plus de temps. 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 les délais de connexion à 30 secondes ou plus.

Comment fonctionne la facturation par instance en cas de pause automatique Aurora Serverless v2 clusters

Alors qu'un Aurora Serverless v2 l'instance est mise en pause automatiquement, ses frais d'instance sont nuls. La ServerlessV2Usage métrique est nulle pendant cette période. AWS 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 ne s'arrête pas automatiquement

  • Si la valeur de capacité minimale de votre cluster de base de données est supérieure à zéroACUs, Aurora Serverless v2 les instances du cluster ne s'interrompent pas automatiquement. Si vous avez des clusters existants avec Aurora Serverless v2 dans les instances antérieures à la disponibilité de la fonction de pause automatique, le paramètre de capacité minimale le plus bas était de 0,5ACUs. Pour utiliser la fonction de pause automatique avec de tels clusters, modifiez le paramètre de capacité minimale à zéroACUs.

  • Si des connexions initiées par l'utilisateur sont ouvertes à Aurora Serverless v2 instance, l'instance ne s'arrêtera pas. L'instance ne s'interrompt pas non plus lorsque des activités telles que l'application de correctifs et les mises à niveau sont en cours. Les connexions administratives utilisées par Aurora pour les contrôles de santé ne sont pas considérées comme des activités et n'empêchent pas l'instance de s'arrêter.

  • Dans un SQL cluster Aurora Postgre sur lequel la réplication logique est activée, ou dans un SQL cluster Aurora My sur lequel la réplication du journal binaire est activée, l'instance d'écriture et toutes les instances de lecteur des niveaux zéro et un de promotion de basculement ne s'interrompent pas automatiquement. Aurora effectue une activité minimale constante 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 du lecteur Aurora dans le cluster source qui s'interrompent automatiquement. Pour ce faire, définissez leur priorité de basculement sur une valeur autre que zéro ou un. De cette façon, ils peuvent être suspendus indépendamment de l'instance du rédacteur.

  • Si votre cluster Aurora est associé à un RDS proxy, celui-ci maintient une connexion ouverte avec chaque instance de base de données du cluster. Ainsi, n'importe quel Aurora Serverless v2 les instances d'un tel cluster ne seront pas automatiquement mises en pause.

  • Si votre cluster est le cluster principal d'une base de données globale Aurora, Aurora ne suspend pas automatiquement le Aurora Serverless v2 instance d'écrivain. Cela est dû au fait qu'un niveau d'activité constant est nécessaire sur l'instance du rédacteur pour gérer les autres clusters de la base de données globale. Étant donné que l'instance du rédacteur reste active, toute Aurora Serverless v2 les instances de lecteur dont la priorité de basculement est zéro ou un ne sont pas non plus mises en pause automatique.

  • Aurora Serverless v2 les instances des clusters secondaires d'une base de données globale Aurora ne s'interrompent pas automatiquement. Si un cluster de base de données est promu en cluster autonome, la fonctionnalité de pause automatique devient effective si toutes les autres conditions sont remplies.

  • Dans un cluster associé à une ETL intégration zéro à Redshift, l'instance Writer et toutes les instances de lecteur appartenant aux niveaux zéro et 1 de promotion en cas de basculement ne s'interrompent pas 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 SQL instance Aurora Postgre, toute connexion ou activité sur le SQL port T empêche la suspension automatique de l'instance.

Comment fonctionne la pause automatique avec la fonction d'arrêt/démarrage du cluster

Vous pouvez arrêter et démarrer un cluster Aurora lorsque la fonctionnalité de pause automatique est activée. Peu importe si certaines instances sont suspendues. Lorsque vous redémarrez le cluster, tout est suspendu Aurora Serverless v2 les instances sont automatiquement reprises.

Lorsqu'un cluster Aurora est arrêté, tout est suspendu Aurora Serverless v2 les instances 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 Aurora Serverless v2 les instances s'appliquent.

Comment fonctionnent la maintenance et les mises à niveau en cas de pause automatique Aurora Serverless v2 clusters

  • Alors qu'un Aurora Serverless v2 l'instance est automatiquement suspendue. Si vous tentez de mettre à niveau le cluster Aurora, Aurora reprend l'instance et la met à niveau.

  • Aurora reprend régulièrement toute pause automatique Aurora Serverless v2 instances 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.

  • Après une Aurora Serverless v2 l'instance se ré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 suspendre à nouveau cette instance. C'est pour permettre à toutes les opérations en arrière-plan de se terminer. La période de vingt minutes permet également d'éviter de suspendre et de reprendre l'instance plusieurs fois si celle-ci subit plusieurs opérations administratives successives.

Différences de comportement de pause automatique entre Aurora Serverless v2 and 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é suspendue pendant moins de 24 heures. Si l'instance est suspendue pendant plus de 24 heures, le délai de reprise peut être plus long.

  • La façon dont Aurora Serverless v2 s'applique aux clusters multi-AZ signifie que certaines instances de base de données du cluster peuvent être suspendues tandis que d'autres sont actives. L'instance du rédacteur reprend chaque fois qu'un lecteur est en cours d'exécution, car le rédacteur est nécessaire pour coordonner certaines activités au sein du cluster. Parce que Aurora Serverless v1 n'utilise pas d'instances de lecteur, l'ensemble du cluster serait toujours suspendu ou actif.

  • Lorsque le point de terminaison du lecteur choisit au hasard une instance de lecteur à laquelle se connecter, cette instance de lecteur est peut-être déjà active ou peut être mise en pause automatiquement. Ainsi, le temps d'accès à l'instance de lecteur peut varier et être plus difficile à prévoir. Clusters multi-AZ qui utilisent Aurora Serverless v2 et la pause automatique peut 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.

  • Aurora Serverless v2 les instances 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 lorsqu'une telle maintenance est nécessaire, vous constaterez peut-être que Aurora Serverless v2 les instances reprennent plus fréquemment que Aurora Serverless v1 clusters l'ont fait.

Comment ? Aurora Serverless v2 la pause automatique fonctionne 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 de Aurora Serverless v2 et approvisionné.

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 évolutivité en fonction de votre cas d'utilisation. Pour ce faire, choisissez la combinaison de Aurora Serverless v2 instances, instances provisionnées et 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 base de données mono-AZ avec Aurora Serverless v2 Instance de base de données. L'instance unique répond à 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 s'arrête. À ce stade, les coûts de calcul de la base de données pour votre cluster sont également suspendus.

  • 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, vous pouvez configurer un cluster multi-AZ dans lequel se trouvent à la fois les instances de base de données d'écriture et de lecture Aurora Serverless v2. Définissez l'instance de lecteur sur une priorité de basculement zéro ou un, de sorte que l'instance du rédacteur et celle du lecteur s'interrompent et reprennent en même temps. Vous bénéficiez désormais 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 suspendus. 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 Aurora Serverless v2 instance de lecteur, et découplez les capacités de certaines instances de lecteur de celles du rédacteur. Spécifiez une priorité de basculement zéro ou un pour l'instance du rédacteur et une instance du lecteur. Spécifiez une priorité supérieure à une pour les autres instances du lecteur. Ainsi, les instances de lecteur situées dans les niveaux de priorité les plus élevés peuvent être mises en pause automatiquement, même lorsque le rédacteur 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 sa capacité pendant les périodes d'inactivité :

    • Vous pouvez utiliser des instances provisionnées pour le rédacteur et le lecteur de priorité 0 ou 1. Ainsi, deux instances de base de données ne s'interrompent jamais automatiquement et sont toujours disponibles pour traiter le trafic de base de données et effectuer des basculements sur incident.

    • Vous pouvez configurer un point de terminaison personnalisé qui inclut Aurora Serverless v2 les instances des niveaux de priorité les plus élevés, mais pas le rédacteur ou 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 les lecteurs susceptibles d'être automatiquement suspendus. Vous pouvez éviter d'utiliser le point de terminaison du lecteur pour de telles demandes, car Aurora peut diriger les connexions du point de terminaison du lecteur vers l'instance de lecteur toujours active 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 capacité d'évolutivité supplémentaire.

Comment ? Aurora Serverless v2 la pause automatique fonctionne pour l'instance d'écriture dans un cluster de base de données

Lorsqu'un cluster de base de données Aurora ne contient qu'une seule instance de base de données, le mécanisme de suspension automatique et de reprise de l'instance de base de données est simple. Cela dépend uniquement de l'activité de l'instance du rédacteur. Vous pouvez avoir une telle configuration pour les clusters utilisés pour le développement et les 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 du rédacteur. Ainsi, pour un cluster de base 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'écriture mise en pause automatiquement.

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

  • Au sein d'un cluster de base de données Aurora, l'instance de base de données du rédacteur est généralement fréquemment consultée. Par conséquent, il se peut que l'instance de base de données du rédacteur reste active même lorsqu'une ou plusieurs instances de base de données du lecteur s'interrompent automatiquement.

  • Certaines activités sur les instances de base de données du lecteur nécessitent que cette instance de base de données du rédacteur soit disponible. Par conséquent, les instances de base de données du rédacteur 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 de rédacteur, même si votre application n'y accède pas directement.

  • Aurora Serverless v2 les instances de lecteur en promotion failover sont de niveau zéro et une échelle pour maintenir leur capacité synchronisée avec l'instance de rédacteur. Ainsi, lorsqu'un Aurora Serverless v2 l'instance de rédacteur reprend, tout comme n'importe laquelle Aurora Serverless v2 les instances de lecteur qui se situent dans les niveaux de promotion zéro ou un.

Comment ? Aurora Serverless v2 la pause automatique fonctionne pour les clusters multi-AZ

Au sein d'un cluster de base de données Aurora contenant à la fois une instance de base de données d'écriture et une ou plusieurs instances de base de données de lecture, certaines Aurora Serverless v2 Les instances de base de données peuvent être suspendues alors que d'autres instances de base de données sont actives. L'instance Writer et toutes les instances de lecteur dont les priorités de basculement sont 0 et 1 sont toujours mises en pause et reprennent en même temps. Les instances de lecteur dont la priorité est différente de 0 ou 1 peuvent être mises 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 du rédacteur et une ou deux autres instances de lecteur peuvent rester actives à tout moment, tandis que les instances de lecteur supplémentaires peuvent faire une 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 la capacité de sa capacité à évoluer indépendamment ou du fait que la capacité est liée à celle de l'instance de base de données d'écriture. Cette propriété de dimensionnement dépend de la priorité de basculement de l'instance de base de données du lecteur. Lorsque la priorité du lecteur est égale à zéro ou à un, la capacité du lecteur suit la capacité de l'instance de base de données du rédacteur. Par conséquent, pour permettre aux instances de base de données du lecteur de s'arrêter automatiquement dans le plus large éventail de situations, définissez leur priorité sur une valeur supérieure à un.

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

Comment ? Aurora Serverless v2 la pause automatique fonctionne pour les clusters dotés d'instances provisionnées

Aucune instance de base de données provisionnée dans votre cluster de base de données Aurora ne sera automatiquement interrompue. Uniquement Aurora Serverless v2 Les instances de base de données, avec la classe d'db.serverlessinstance, peuvent utiliser la fonctionnalité de pause automatique.

Lorsque votre cluster Aurora contient des instances de base de données provisionnées, Aurora Serverless v2 l'instance Writer ne s'arrête pas automatiquement. Cela est dû au fait que l'instance du rédacteur doit rester disponible tant que toutes les instances de lecteur sont actives. Le fait que Aurora Serverless v2 l'écrivain reste actif signifie également que tout Aurora Serverless v2 les instances de lecteur dont les priorités de basculement sont 0 et 1 ne s'interrompent pas automatiquement dans un cluster hybride contenant des instances provisionnées.

Surveillance des clusters Aurora qui utilisent la pause automatique

Pour surveiller Aurora, vous devez déjà connaître les procédures de surveillance Surveillance des métriques (Amazon Aurora) avec Amazon CloudWatch et les CloudWatch mesures répertoriées dansRé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 où Aurora Serverless v2 les instances n'enregistrent pas les données du journal et la plupart des métriques car elles sont suspendues. Les seules mesures envoyées CloudWatch lorsqu'une instance est en pause sont zéro pour cent pour CPUUtilization etACUUtilization, et zéro pourServerlessDatabaseCapacity.

  • Vous pouvez vérifier si Aurora Serverless v2 les instances s'interrompent plus ou moins fréquemment que prévu. Pour ce faire, vérifiez à quelle fréquence la ServerlessDatabaseCapacity métrique 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 s'interrompent 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 influent sur la question de savoir si et à quelle fréquence Aurora Serverless v2 les instances peuvent faire une pause Conditions préalables et limites du Aurora Serverless v2 fonction de pause automatiqueSituations dans lesquelles Aurora Serverless v2 ne s'arrête pas automatiquement, voir etRésolution des problèmes pour Aurora Serverless v2 pause automatique.

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

Vérifier si un Aurora Serverless v2 l'instance est suspendue

Pour déterminer si un Aurora Serverless v2 l'instance est en pause, vous pouvez observer la ACUUtilization métrique de l'instance. Cette métrique a une valeur de zéro lorsque l'instance est en pause.

Alors qu'un Aurora Serverless v2 l'instance est suspendue, sa valeur d'état est toujours répertoriée comme Disponible. Il en va de même pendant une pause Aurora Serverless v2 l'instance est en cours de reprise. En effet, vous pouvez vous connecter avec succès à une telle instance, même si la connexion est légèrement retardée.

Toutes les mesures liées à la disponibilité des instances Aurora prennent en compte la période pendant laquelle l'instance est suspendue comme le temps pendant lequel l'instance était disponible.

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

Aurora diffuse des événements pour Aurora Serverless v2 instances où 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 terminésRDS-EVENT-0370. RDS-EVENT-0374 Pour plus de détails sur ces événements, consultezÉvènements d'instance de base de données.

Comment fonctionne la pause automatique avec Performance Insights et Enhanced Monitoring

Alors qu'un Aurora Serverless v2 l'instance est suspendue, Aurora ne collecte pas d'informations de surveillance pour cette instance via Performance Insights ou Enhanced Monitoring. Lorsque l'instance est reprise, il peut s'écouler un bref délai avant qu'Aurora ne recommence à collecter ces informations de surveillance.

Comment le Aurora Serverless v2 la fonction de pause automatique interagit avec les métriques Aurora

Alors qu'un Aurora Serverless v2 l'instance est suspendue, elle n'émet pas la plupart des CloudWatch métriques et n'écrit aucune information dans ses journaux de base de données. Les seules mesures envoyées CloudWatch lorsqu'une instance est en pause sont zéro pour cent pour CPUUtilization etACUUtilization, et zéro pourServerlessDatabaseCapacity.

Quand CloudWatch le calcul des statistiques est-il lié à la disponibilité et à la disponibilité des instances ou des clusters, Aurora Serverless v2 les instances sont considérées comme disponibles pendant la durée de leur pause.

Lorsque vous lancez une RDS API action AWS CLI ou pour décrire ou télécharger les journaux d'une pause Aurora Serverless v2 instance, l'instance redémarre automatiquement pour rendre les informations du journal disponibles.

Exemple de CloudWatch métriques

Les AWS CLI exemples suivants montrent comment vous pouvez observer l'évolution de la capacité d'une instance au fil du temps. Pendant cette période, l'instance s'arrête automatiquement puis reprend. Lorsqu'elle est en pause, la ServerlessDatabaseCapacity métrique indique une valeur de zéro. Pour déterminer si l'instance a été suspendue à un moment quelconque au cours de la période, nous vérifions si la capacité minimale pendant cette période était nulle.

L'exemple Linux suivant représente un Aurora Serverless v2 instance qui a été automatiquement suspendue pendant un certain temps. Nous les échantillonnons ServerlessDatabaseCapacity chaque minute, sur une période de trois minutes. La ACU valeur minimale de 0,0 confirme que l'instance a été suspendue à 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 le Aurora Serverless v2 instance. Dans cet exemple, nous utilisons intentionnellement un mot de passe incorrect afin que la tentative de connexion échoue. Malgré l'échec, la tentative de connexion oblige Aurora à reprendre l'instance suspendue. 


$ 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 suspendue a repris, est restée inactive pendant environ cinq minutes, puis est revenue à son état suspendu. L'instance a repris à une capacité de 2,0ACUs. Ensuite, il s'est légèrement agrandi, par exemple pour effectuer un nettoyage interne. Comme il n'a reçu aucune tentative de connexion utilisateur dans le délai de cinq minutes, il est passé ACUs directement de la version 4.0 à l'état suspendu. 


$ 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 s'est développée pour gérer la charge de travail, nous pouvons spécifier Maximum la statistique au lieu de. Minimum Pour la planification des capacités et l'estimation des coûts, nous pouvons spécifier une période plus longue et utiliser les Average statistiques. De cette façon, nous avons pu déterminer des valeurs de capacité typiques pendant les périodes de forte activité, de faible activité et d'état de pause. Pour examiner le comportement pendant les périodes précises de pause et de reprise, nous pouvons spécifier une période d'une seconde et examiner un intervalle de temps plus court. Les valeurs d'horodatage de la sortie, par exemple2024-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 pour Aurora Serverless v2 pause automatique

Si tu trouves ça Aurora Serverless v2 les instances ne s'interrompent pas aussi souvent que prévu. Vérifiez les causes possibles suivantes :

  • Vérifiez que la version d'Aurora que vous utilisez prend en charge une capacité minimale de zéroACUs. Pour les plages de capacité des différentes versions d'Aurora, voirAurora Serverless v2 capacity.

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

  • Vérifiez que l'instance en question utilise réellement Aurora Serverless v2 classe d'instancedb.serverless, pas l'une des classes d'instance provisionnées.

  • Vérifiez que le cluster n'utilise aucun des paramètres ou fonctionnalités incompatibles deConditions préalables et limites du Aurora Serverless v2 fonction de pause automatique.

  • Examinez le fichier journal indiquant quand Aurora Serverless v2 les instances ont été suspendues, reprises ou Aurora n'a pas pu suspendre ou reprendre une instance pour une raison quelconque. Pour de plus amples informations, veuillez consulter Surveillance Aurora Serverless v2 suspendre et reprendre l'activité.

  • Vérifiez si des clients ou des applications maintiennent les connexions ouvertes pendant de longues périodes. À l'inverse, vérifiez si les applications qui utilisent RDS les fonctions Data API ou 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 CloudWatch indicateurs tels que ConnectionAttempts etDatabaseConnections. Pour de plus amples informations, veuillez consulter Métriques de niveau instance pour Amazon Aurora.

  • Si une instance de lecteur s'arrête rarement, voire jamais, vérifiez sa priorité de basculement. Si le lecteur est utilisé pour le redimensionnement de la lecture et non comme support en cas de basculement, réglez-le sur une priorité comprise entre 2 et 15.

  • Si l'instance du rédacteur s'arrête rarement, voire jamais, vérifiez l'utilisation que vous faites des instances du lecteur. Le rédacteur ne peut faire une 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 du rédacteur.

  • Si votre application reçoit des délais d'attente lors de demandes de connexion alors que Aurora Serverless v2 les instances reprennent, pensez à allonger le délai d'expiration utilisé par le code de votre application ou le framework de base de données sous-jacent. Des délais de connexion plus longs réduisent le risque d'échec des connexions lorsque Aurora Serverless v2 les instances reprennent. 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 rencontrent pas 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 un bon candidat pour utiliser la fonctionnalité de pause automatique.

  • Si vous estimez la durée de votre Aurora Serverless v2 les instances seront suspendues, sachez que certains facteurs font qu'il est impossible de faire des prédictions précises.

    • Les instances peuvent reprendre périodiquement pour effectuer des opérations de maintenance, des mises à niveau de versions mineures ou pour appliquer 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 du rédacteur. La reprise du rédacteur entraîne toujours la reprise des lecteurs dont les priorités de basculement sont 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 pendant laquelle vous pouvez vous attendre à ce qu'une instance soit suspendue.

  • Vous constaterez peut-être que les opérations internes telles que My SQL purge, My SQL Event Scheduler, Postgre SQL Autovacuum ou les tâches Postgre planifiées via l'pg_cronextension ne sont pas en cours SQL d'exécution ou ne se terminent pas. L'instance ne reprend pas automatiquement pour effectuer de telles opérations qui n'impliquent pas de connexion utilisateur à la base de données. Si de telles opérations internes sont en cours à l'expiration du délai de pause automatique, les tâches de maintenance telles que My SQL purge et Postgre SQL autovacuum sont annulées. Les tâches planifiées à partir du planificateur d'SQLévénements My ou de l'SQLpg_cronextension Postgre 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 pour effectuer des opérations planifiées, vous pouvez établir une connexion pour reprendre l'instance 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'aspiration automatique 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 à reprendre automatiquement l'instance si nécessaire.

Considérations relatives à la conception des applications pour Aurora Serverless v2 fonction de pause automatique

Quand un Aurora Serverless v2 L'instance de base de données reprend après avoir été automatiquement mise en pause, elle commence avec une capacité relativement faible et augmente à 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 représente le cas typique où un Aurora Serverless v2 l'instance reprend en raison d'une ou d'un petit nombre de connexions entrantes. Si l'instance est suspendue 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 fonction de pause automatique, vous avez peut-être déjà mis en place de tels délais d'expiration pour les tentatives de connexion. Si vous utilisez déjà Aurora Serverless v2 en combinaison avec la fonction d'arrêt/démarrage du cluster Aurora, le temps de reprise en cas de pause automatique Aurora Serverless v2 les instances sont généralement beaucoup plus courtes que le délai de démarrage d'un cluster arrêté.

Lorsque vous codez la logique de connexion dans votre application, réessayez de vous connecter si la première tentative renvoie une erreur d'origine transitoire. (Si l'erreur est due à un échec d'authentification, corrigez les informations d'identification avant de réessayer.) Une erreur qui se produit immédiatement après la reprise peut être un délai d'attente ou une erreur liée aux limites de la base de données. Une nouvelle tentative peut résoudre les problèmes dans les cas plus rares où un Aurora Serverless v2 l'instance est reprise 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 des applications, ne laissez pas les sessions client ou les outils de programmation connectés à la base de données ouverts. Aurora ne suspend pas une instance si des connexions initiées par l'utilisateur sont ouvertes, que ces connexions n'exécutent aucune instruction SQL ou transaction. Quand un Aurora Serverless v2 une instance d'un cluster Aurora ne peut pas être mise en pause, d'autres instances du cluster peuvent également être empêchées de le faire. Pour de plus amples informations, veuillez consulter Situations dans lesquelles Aurora Serverless v2 ne s'arrête pas automatiquement.

Aurora émet des événements lorsqu'un Aurora Serverless v2 L'instance de base de données commence à reprendre, termine sa reprise et si l'instance ne peut pas reprendre pour une raison quelconque. Pour plus de détails sur ces événements, consultezÉvènements d'instance de base de données.