Fonctionnement d'Aurora Serverless v1

Vous allez pouvoir découvrir comment fonctionne Aurora Serverless v1.

Architecture d'Aurora Serverless v1

L'image suivante illustre l'architecture d'Aurora Serverless v1.

Au lieu d'allouer et de gérer les serveurs de base de données, vous spécifiez des unités de capacité Aurora (ACU). Chaque unité de capacité combine environ 2 gigaoctets (Go) de mémoire, avec une UC et une mise en réseau correspondantes. Le stockage de base de données s'échelonne automatiquement de 10 gibioctets (GiO) jusqu'à 128 tebibytes (TiB), ce qui équivaut au stockage dans un cluster de base de données Aurora standard.

Vous pouvez définir l'unité de capacité minimale et maximale. L'unité de capacité Aurora minimale est l'unité de capacité la plus petite à laquelle le cluster de bases de données peut être dimensionné. L'unité de capacité Aurora maximale est l'unité de capacité la plus grande à laquelle le cluster de bases de données peut être dimensionné. En fonction de vos paramètres, Aurora Serverless v1 crée automatiquement des règles de mise à l'échelle pour les seuils d'utilisation de l'UC, de connexions et de mémoire disponible.

Aurora Serverless v1 gère le groupe de ressources « à chaud » dans une Région AWS pour minimiser le temps de mise à l'échelle. Quand Aurora Serverless v1 ajoute de nouvelles ressources au cluster de bases de données Aurora, il utilise la flotte de routeurs pour faire basculer les connexions client actives vers les nouvelles ressources. Quelle que soit l'heure, seules les ACU qui sont activement utilisées dans votre cluster de bases de données Aurora vous sont facturées.

Mise à l'échelle automatique pour Aurora Serverless v1

La capacité allouée à votre cluster de bases de données Aurora Serverless v1 est mise à l'échelle de manière transparente en fonction de la charge générée par votre application client. Ici, la charge représente l'utilisation du processeur et le nombre de connexions. Lorsque la capacité est limitée par l'un ou l'autre de ces facteurs, Aurora Serverless v1 se met à l'échelle. Aurora Serverless v1 se met également à l'échelle lorsqu'il détecte des problèmes de performances qui peuvent être résolus en procédant ainsi.

Vous pouvez afficher les événements de mise à l'échelle pour votre cluster Aurora Serverless v1 dans la AWS Management Console. Lors de la mise à l'échelle automatique, Aurora Serverless v1 réinitialise la métrique EngineUptime. La valeur de métrique de réinitialisation ne signifie pas que la mise à l'échelle transparente a rencontré des problèmes ou que des connexions Aurora Serverless v1 ont été interrompues. C'est simplement le point de départ de la disponibilité à la nouvelle capacité. Pour en savoir plus sur les métriques, consultez Surveillance des métriques d'un cluster de bases de données Amazon Aurora.

Lorsque votre cluster de bases de données Aurora Serverless v1 n'a pas de connexions actives, il peut se redimensionner jusqu'à la capacité zéro (0 ACU). Pour en savoir plus, consultez la section Mettre en pause et reprendre pour Aurora Serverless v1.

Lorsqu'il a besoin d'effectuer une opération de mise à l'échelle, Aurora Serverless v1 essaie d'abord d'identifier un point de mise à l'échelle, un moment où aucune requête n'est en cours de traitement. Aurora Serverless v1 peut ne pas être en mesure de trouver un point de mise à l'échelle pour les raisons suivantes :

• Requêtes de longue durée

• Transactions en cours

• Tables temporaires ou verrous de table

Pour augmenter le taux de réussite de votre cluster de bases de données Aurora Serverless v1 lors de la recherche d'un point de mise à l'échelle, nous vous recommandons d'éviter les requêtes et les transactions de longue durée. Pour en savoir plus sur les opérations de blocage d'échelle et comment les éviter, consultez Best practices for working with Aurora Serverless v1.

Par défaut, Aurora Serverless v1 tente de trouver un point de mise à l'échelle pendant 5 minutes (300 secondes). Vous pouvez spécifier un délai d'attente différent lorsque vous créez ou modifiez le cluster. Le délai d'attente peut être compris entre 60 secondes et 10 minutes (600 secondes). Si Aurora Serverless v1 ne peut pas trouver de point de mise à l'échelle dans la période spécifiée, l'opération de scalabilité automatique expire.

Par défaut, si la mise à l'échelle automatique ne trouve pas de point de mise à l'échelle avant l'expiration, Aurora Serverless v1 maintient le cluster à la capacité actuelle. Vous pouvez modifier ce comportement par défaut lorsque vous créez ou modifiez votre cluster de bases de données Aurora Serverless v1 en sélectionnant l'option Forcer le changement de capacité. Pour plus d'informations, consultez Action de délai d'attente pour les modifications de capacité.

Action de délai d'attente pour les modifications de capacité

Si la scalabilité automatique expire avec la recherche d'un point de mise à l'échelle, Aurora conserve par défaut la capacité actuelle. Vous pouvez faire en sorte que Aurora force le changement en sélectionnant l'option Force the capacity change (Forcer le changement de capacité). Cette option est disponible dans la section Autoscaling timeout and action (Délai de mise à l'échelle automatique et action) de la page Create database (Créer une base de données), lorsque vous créez le cluster.

Par défaut, l'option Force the capacity change (Forcer le changement de capacité) n'est pas sélectionnée. Ne la sélectionnez pas pour que la capacité de votre cluster de bases de données Aurora Serverless v1 reste inchangée si l'opération de mise à l'échelle échoue sans trouver de point de mise à l'échelle.

Si vous choisissez cette option, votre cluster de bases de données Aurora Serverless v1 appliquera le changement de capacité, même sans point de mise à l'échelle. Avant de sélectionner cette option, tenez compte des conséquences de sa sélection :

• Toutes les transactions en cours de processus sont interrompues et le message d'erreur suivant s'affiche.

  Aurora MySQL version 2 – ERREUR 1105 (HY000) : La dernière transaction a été interrompue en raison d'une mise à l'échelle transparente. Veuillez réessayer.

  Vous pouvez renvoyer les transactions dès que votre cluster de bases de données Aurora Serverless v1 est disponible.

• Les connexions aux tables temporaires et aux verrous sont abandonnées.

  Nous vous recommandons de sélectionner l'option Force the capacity change (Forcer le changement de capacité) uniquement si votre application peut récupérer des connexions interrompues ou des transactions incomplètes.

Les choix que vous faites dans AWS Management Console lorsque vous créez un cluster de bases de données Aurora Serverless v1 sont stockés dans l'objet ScalingConfigurationInfo, dans les propriétés SecondsBeforeTimeout et TimeoutAction. La valeur de la propriété TimeoutAction est définie sur l'une des valeurs suivantes lorsque vous créez votre cluster :

• RollbackCapacityChange – Cette valeur est définie lorsque vous sélectionnez l'option Roll back the capacity change (Restaurer le changement de capacité). Il s'agit du comportement de par défaut.

• ForceApplyCapacityChange – Cette valeur est définie lorsque vous sélectionnez l'option Force the capacity change (Forcer le changement de capacité).

Vous pouvez obtenir la valeur de cette propriété sur un Aurora Serverless v1 cluster de base de données existant à l'aide de la describe-db-clustersAWS CLIcommande, comme indiqué ci-dessous.

Pour LinuxmacOS, ou Unix :

aws rds describe-db-clusters --region region \
  --db-cluster-identifier your-cluster-name \
  --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

Dans Windows :

aws rds describe-db-clusters --region region ^
  --db-cluster-identifier your-cluster-name ^
  --query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"

À titre d'exemple, ce qui suit montre la requête et la réponse pour un cluster de base de données Aurora Serverless v1 nommé west-coast-sles dans la région USA Ouest (Californie du Nord).

$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles 
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

[
    {
        "ScalingConfigurationInfo": {
            "MinCapacity": 1,
            "MaxCapacity": 64,
            "AutoPause": false,
            "SecondsBeforeTimeout": 300,
            "SecondsUntilAutoPause": 300,
            "TimeoutAction": "RollbackCapacityChange"
        }
    }
]

Comme le montre la réponse, ce cluster de bases de données Aurora Serverless v1 utilise le paramètre par défaut.

Pour plus d'informations, consultez Création d'un cluster de bases de données Aurora Serverless v1. Après avoir créé votre Aurora Serverless v1, vous pouvez modifier l'action d'expiration et d'autres paramètres de capacité à tout moment. Pour savoir comment procéder, consultez Modification d'un cluster de bases de données Aurora Serverless v1.

Mettre en pause et reprendre pour Aurora Serverless v1

Vous pouvez choisir de mettre en pause votre cluster de bases de données Aurora Serverless v1 après un certain temps sans activité. Spécifiez la durée d'inactivité du cluster de base de données avant que celui-ci soit mis en pause. Lorsque vous sélectionnez cette option, le temps d'inactivité par défaut est de cinq minutes, mais vous pouvez modifier cette valeur. Il s'agit d'une étape facultative.

Lorsque le cluster de base de données est en pause, aucune activité de calcul ou de mémoire ne se produit ; vous êtes facturé uniquement pour le stockage. Si des connexions de bases de données sont demandées lorsqu'un cluster de bases de données Aurora Serverless v1 est en pause, celui-ci reprend automatiquement et répond aux demandes de connexion.

Lorsque le cluster de base de données reprend l'activité, il a la même capacité que lorsque Aurora a mis en pause le cluster. Le nombre d'ACU dépend de la quantité mise à l'échelle par Aurora pour le cluster vers le haut ou vers le bas avant de le mettre en pause.

Note

Si un cluster de base de données est mis en pause pendant plus de sept jours, il peut être sauvegardé avec un instantané. Dans ce cas, Aurora restaure le cluster de base de données à partir de l'instantané lorsqu'il y a une demande de connexion à celui-ci.

Détermination du nombre maximal de connexions à une base de données pour Aurora Serverless v1

Les exemples suivants s'appliquent à un cluster de bases de données Aurora Serverless v1 compatible avec MySQL 5.7. Vous pouvez utiliser un client MySQL ou l'éditeur de requêtes, si vous y avez configuré l'accès. Pour plus d'informations, consultez Exécution de requêtes dans l'éditeur de requête.

Pour trouver le nombre maximal de connexions à une base de données

1. Trouvez la plage de capacité de votre cluster de bases de données Aurora Serverless v1 à l'aide d'AWS CLI.

   aws rds describe-db-clusters \
       --db-cluster-identifier my-serverless-57-cluster \
       --query 'DBClusters[*].ScalingConfigurationInfo|[0]'

   Le résultat indique que sa plage de capacité est comprise entre 1 et 4 ACU.

   {
       "MinCapacity": 1,
       "AutoPause": true,
       "MaxCapacity": 4,
       "TimeoutAction": "RollbackCapacityChange",
       "SecondsUntilAutoPause": 3600
   }

2. Exécutez la requête SQL suivante pour trouver le nombre maximal de connexions.

   select @@max_connections;

   Le résultat affiché correspond à la capacité minimale du cluster, 1 ACU.

   @@max_connections
   90

3. Mettez le cluster à l'échelle jusqu'à 8 à 32 ACU.

   Pour plus d’informations sur le dimensionnement, consultez Modification d'un cluster de bases de données Aurora Serverless v1.

4. Confirmez la plage de capacité.

   {
       "MinCapacity": 8,
       "AutoPause": true,
       "MaxCapacity": 32,
       "TimeoutAction": "RollbackCapacityChange",
       "SecondsUntilAutoPause": 3600
   }

5. Trouvez le nombre maximal de connexions.

   select @@max_connections;

   Le résultat affiché correspond à la capacité minimale du cluster, 8 ACU.

   @@max_connections
   1000

6. Mettez le cluster à l'échelle jusqu'à la valeur maximale acceptée, 256 ACU.

7. Confirmez la plage de capacité.

   {
       "MinCapacity": 256,
       "AutoPause": true,
       "MaxCapacity": 256,
       "TimeoutAction": "RollbackCapacityChange",
       "SecondsUntilAutoPause": 3600
   }

8. Trouvez le nombre maximal de connexions.

   select @@max_connections;

   Le résultat affiché correspond à 256 ACU.

   @@max_connections
   6000

   Note

   La valeur max_connections n'est pas mise à l'échelle de manière linéaire avec le nombre d'ACU.

9. Remettez le cluster à l'échelle sur 1 à 4 ACU.

   {
       "MinCapacity": 1,
       "AutoPause": true,
       "MaxCapacity": 4,
       "TimeoutAction": "RollbackCapacityChange",
       "SecondsUntilAutoPause": 3600
   }

   Cette fois, la valeur max_connections correspond à 4 ACU.

   @@max_connections
   270

10. Réduisez le cluster à 2 ACU.

    @@max_connections
    180

    Si vous avez configuré le cluster pour qu'il s'arrête après un certain temps d'inactivité, il est réduit à 0 ACU. Cependant, max_connections ne tombe pas en dessous de 1 ACU.

    @@max_connections
    90

Groupes de paramètres pour Aurora Serverless v1

Lorsque vous créez votre cluster de base de données Aurora Serverless v1, vous choisissez un moteur de bases de données Aurora spécifique et un groupe de paramètres de cluster de base de données associé. Contrairement aux clusters de bases de données Aurora provisionnés, un cluster de bases de données Aurora Serverless v1 possède une seule instance de bases de données en lecture/écriture configurée avec un groupe de paramètres de cluster de données uniquement. — Il n'a pas de groupe de paramètres de bases de données distinct. Lors de la mise à l'échelle automatique, Aurora Serverless v1 doit être en mesure de modifier les paramètres pour que le cluster fonctionne mieux en fonction de l'augmentation ou de la diminution de la capacité. Ainsi, avec un cluster de bases de données Aurora Serverless v1, certaines des modifications que vous pourriez apporter aux paramètres d'un type de moteur de bases de données particulier peuvent ne pas s'appliquer.

Par exemple, un cluster de bases de données Aurora Serverless v1 basé sur Aurora PostgreSQL– ne peut pas utiliser apg_plan_mgmt.capture_plan_baselines et d'autres paramètres qui peuvent être utilisés sur des clusters de bases de données Aurora PostgreSQL provisionnés pour la gestion du plan de requête.

Vous pouvez obtenir une liste des valeurs par défaut pour les groupes de paramètres par défaut des différents moteurs de base de données Aurora en utilisant la commande CLI describe-engine-default-cluster-parameters et en interrogeant le. Région AWS Pour l'option --db-parameter-group-family, vous pouvez utiliser les valeurs suivantes :

Aurora MySQL version 2	aurora-mysql5.7
Aurora PostgreSQL version 11	aurora-postgresql11
Aurora PostgreSQL version 13	aurora-postgresql13

Nous vous recommandons de configurer AWS CLI avec votre identifiant de clé d'accès AWS et votre clé d'accès secrète AWS, et de configurer votre Région AWS avant d'utiliser les commandes AWS CLI. La fourniture de la région à votre configuration CLI vous évite d'entrer dans le paramètre --region lors de l'exécution des commandes. Pour en savoir plus sur la configuration d'AWS CLI, consultez Principes de base de la configuration dans le Guide de l'utilisateur AWS Command Line Interface.

L'exemple suivant obtient une liste de paramètres du groupe de clusters de bases de données par défaut pour Aurora MySQL version 2.

Pour LinuxmacOS, ou Unix :

aws rds describe-engine-default-cluster-parameters \
  --db-parameter-group-family aurora-mysql5.7 --query \
  'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \
  --output text

Dans Windows :

aws rds describe-engine-default-cluster-parameters ^
   --db-parameter-group-family aurora-mysql5.7 --query ^
   "EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^
   --output text

Modification des valeurs des paramètres pour l Aurora Serverless v1

Comme expliqué dans Groupes de paramètres pour Amazon Aurora, vous ne pouvez pas modifier directement les valeurs d'un groupe de paramètres par défaut, quel que soit son type (groupe de paramètres de cluster de bases de données, groupe de paramètres de bases de données). Au lieu de cela, vous créez un groupe de paramètres personnalisé basé sur le groupe de paramètres de cluster de bases de données par défaut pour votre moteur de bases de données Aurora et modifiez les paramètres selon les besoins sur ce groupe de paramètres. Par exemple, vous souhaiterez peut-être modifier certains paramètres de votre Aurora Serverless v1 cluster de base de données afin de consigner les requêtes ou de télécharger des journaux spécifiques au moteur de base de données sur Amazon CloudWatch.

Pour créer un groupe de paramètres de cluster de bases de données personnalisé

1. Connectez-vous à l'AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

2. Choisissez Groupes de paramètres.

3. Choisissez Créer un groupe de paramètres pour ouvrir le volet des détails du groupe de paramètres.

4. Choisissez le groupe de cluster de bases de données par défaut correspondant au moteur de base de données que vous souhaitez utiliser pour votre cluster de bases de données Aurora Serverless v1. Veillez à choisir les options suivantes :

   1. Pour Famille de groupes de paramètres, choisissez la famille correspondant au moteur de base de données choisi. Assurez-vous que le nom de votre choix comporte le préfixe aurora-.

   2. Pour Type, choisissez Groupe de paramètres de cluster DB.

   3. Pour Nom du groupe et Description, entrez des noms descriptifs pour vous ou les autres utilisateurs susceptibles d'utiliser votre cluster de bases de données Aurora Serverless v1 et ses paramètres.

   4. Sélectionnez Créer.

Votre groupe de paramètres de cluster de bases de données personnalisé est ajouté à la liste des groupes de paramètres disponibles dans votre Région AWS. Vous pouvez utiliser votre groupe de paramètres de cluster de bases de données personnalisé lorsque vous créez des clusters de bases de données Aurora Serverless v1. Vous pouvez également modifier un cluster de bases de données Aurora Serverless v1 existant pour utiliser votre groupe de paramètres de cluster de bases de données personnalisé. Une fois que votre cluster de bases de données Aurora Serverless v1 commence à utiliser votre groupe de paramètres de cluster de bases de données personnalisé, vous pouvez modifier les valeurs des paramètres dynamiques à l'aide d'AWS Management Console ou d'AWS CLI.

Vous pouvez également utiliser la console pour afficher une side-by-side comparaison des valeurs de votre groupe de paramètres de cluster de base de données personnalisé par rapport au groupe de paramètres de cluster de base de données par défaut, comme illustré dans la capture d'écran suivante.

Lorsque vous modifiez des valeurs de paramètre sur un cluster de bases de données actif, Aurora Serverless v1 démarre une mise à l'échelle transparente afin d'appliquer les modifications de paramètres. Si votre cluster de bases de données Aurora Serverless v1 est à l'état de pause, il reprend et commence à être mis à l'échelle afin qu'il puisse effectuer la modification. L'opération de mise à l'échelle d'une modification de groupe de paramètres force toujours un changement de capacité, sachez donc que la modification des paramètres peut entraîner l'abandon des connexions si aucun point de mise à l'échelle ne peut être trouvé pendant la période de mise à l'échelle.

Journalisation pour Aurora Serverless v1

Par défaut, les journaux d'erreurs pour Aurora Serverless v1 sont activés et automatiquement chargés sur Amazon CloudWatch. Vous pouvez également demander à votre Aurora Serverless v1 cluster de bases de données de télécharger des journaux spécifiques au moteur de base de données Aurora vers. CloudWatch Pour ce faire, activez les paramètres de configuration dans votre groupe de paramètres de cluster de bases de données personnalisé. Votre Aurora Serverless v1 cluster de base de données télécharge ensuite tous les journaux disponibles sur Amazon CloudWatch. À ce stade, vous pouvez l'utiliser CloudWatch pour analyser les données du journal, créer des alarmes et afficher les métriques.

Pour Aurora MySQL, le tableau suivant indique les journaux que vous pouvez activer. Lorsqu'elles sont activées, elles sont automatiquement téléchargées depuis votre Aurora Serverless v1 cluster de bases de données vers Amazon CloudWatch.

Journal Aurora MySQL	Description
general_log	Crée le journal général. Paramétrez sur 1 pour activer. La valeur par défaut est désactivée (0).
log_queries_not_using_indexes	Journalise les requêtes dans le journal des requêtes lentes qui n'utilisent pas d'index. La valeur par défaut est désactivée (0). Paramétrez sur 1 pour activer ce journal.
long_query_time	Empêche l'enregistrement des requêtes rapides dans le journal des requêtes lentes. Peut être défini sur une valeur flottante comprise entre 0 et 31 536 000. La valeur par défaut est 0 (non active).
server_audit_events	Liste des événements à capturer dans les journaux. Les valeurs prises en charge sont CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML, et TABLE.
server_audit_logging	Paramétrez sur 1 pour activer la journalisation d'audit de serveur. Si vous activez cette option, vous pouvez spécifier les événements d'audit auxquels les envoyer CloudWatch en les listant dans le server_audit_events paramètre.
slow_query_log	Crée un journal des requêtes lentes. Paramétrez sur 1 pour activer le journal des requêtes lentes. La valeur par défaut est désactivée (0).

Pour plus d'informations, consultez Utilisation de l'audit avancé avec un cluster Amazon Aurora My SQL DB.

Pour Aurora PostgreSQL, le tableau suivant indique les journaux que vous pouvez activer. Lorsqu'ils sont activés, ils sont automatiquement téléchargés depuis votre Aurora Serverless v1 cluster de base de données vers Amazon CloudWatch avec les journaux d'erreurs habituels.

Journal Aurora PostgreSQL	Description
log_connections	Activé par défaut et ne peut pas être modifié. Il journalise les détails pour toutes les nouvelles connexions client.
log_disconnections	Activé par défaut et ne peut pas être modifié. Journalise toutes les déconnexions du client.
log_hostname	Désactivé par défaut et ne peut pas être modifié. Les noms d'hôtes ne sont pas enregistrés.
log_lock_waits	La valeur par défaut est 0 (désactivée). Paramétrez sur 1 pour journaliser les attentes de verrouillage.
log_min_duration_statement	Durée minimale (en millisecondes) d'exécution d'une instruction avant qu'elle ne soit journalisée.
log_min_messages	Définit les niveaux des messages qui sont enregistrés. Les valeurs prises en charge sont debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. Pour consigner les données de performances dans le journal postgres , définissez la valeur sur debug1.
log_temp_files	Journalise l'utilisation de fichiers temporaires qui sont au-dessus des kilo-octets (Ko) spécifiés.
log_statement	Contrôle les instructions SQL spécifiques qui sont journalisées. Les valeurs prises en charge sont none, ddl, mod et all. La valeur par défaut est none.

Après avoir activé les journaux pour Aurora MySQL ou Aurora PostgreSQL pour Aurora Serverless v1 votre cluster de bases de données, vous pouvez les consulter. CloudWatch

Afficher Aurora Serverless v1 les journaux avec Amazon CloudWatch

Aurora Serverless v1télécharge (« publie ») automatiquement sur Amazon CloudWatch tous les journaux activés dans votre groupe de paramètres de cluster de bases de données personnalisé. Vous n'avez pas besoin de choisir ou de spécifier les types de journaux. Le chargement des journaux démarre dès que vous activez le paramètre de configuration du journal. Si vous désactivez ultérieurement le paramètre de journal, les chargements supplémentaires s'arrêtent. Cependant, tous les journaux déjà publiés seront CloudWatch conservés jusqu'à ce que vous les supprimiez.

Pour plus d'informations sur l'utilisation CloudWatch des journaux Aurora MySQL, consultezSurveillance des événements du journal sur Amazon CloudWatch.

Pour plus d'informations sur CloudWatch Aurora PostgreSQL, consultez. Publication des journaux Aurora SQL Postgrer sur Amazon CloudWatch Logs

Pour afficher les journaux de votre cluster de bases de données Aurora Serverless v1

1. Ouvrez la CloudWatch console à l'adresse https://console.aws.amazon.com/cloudwatch/.

2. Choisissez votre Région AWS.

3. Choisissez Groupes de journaux.

4. Choisissez votre journal de cluster de bases de données Aurora Serverless v1 dans la liste. Pour les journaux d'erreurs, le modèle d'affectation de noms est le suivant.

   /aws/rds/cluster/cluster-name/error

Par exemple, dans la capture d'écran suivante, vous pouvez trouver des listes pour les journaux publiés pour un cluster de bases de données Aurora PostgreSQL Aurora Serverless v1 nommé western-sles. Vous y trouverez également plusieurs listes pour le cluster de bases de données Aurora MySQL Aurora Serverless v1, west-coast-sles. Choisissez le journal qui vous intéresse pour commencer à explorer son contenu.

Aurora Serverless v1 et maintenance

La maintenance du cluster de base de données Aurora Serverless v1, comme l'application des dernières fonctionnalités, des correctifs et des mises à jour de sécurité, est effectuée automatiquement pour vous. Aurora Serverless v1 dispose d'une fenêtre de maintenance que vous pouvez visualiser dans la AWS Management Console, dans Maintenance et sauvegardes, pour votre cluster de base de données Aurora Serverless v1. Vous pouvez trouver la date et l'heure auxquelles la maintenance peut être effectuée et si une maintenance est en attente pour votre Aurora Serverless v1 cluster de base de données, comme indiqué dans la figure suivante.

Vous pouvez définir la fenêtre de maintenance lorsque vous créez le cluster de base de données Aurora Serverless v1, et vous pouvez modifier cette fenêtre ultérieurement. Pour plus d'informations, consultez Ajustement du créneau de maintenance préféré pour un cluster de base de données.

Les fenêtres de maintenance sont utilisées pour les mises à niveau des versions majeures planifiées. Les mises à niveau des versions mineures et les correctifs sont appliqués immédiatement lors du dimensionnement. La mise à l'échelle s'effectue en fonction de vos paramètres pour TimeoutAction :

• ForceApplyCapacityChange— La modification est appliquée immédiatement.

• RollbackCapacityChange— Aurora met à jour de force le cluster 3 jours après la première tentative de correctif.

Comme pour toute modification forcée sans point de mise à l'échelle approprié, votre charge de travail peut être interrompue.

Dans la mesure du possible, Aurora Serverless v1 effectue la maintenance sans aucune perturbation. Lorsqu'une maintenance est requise, votre cluster de bases de données Aurora Serverless v1 met à l'échelle sa capacité pour gérer les opérations nécessaires. Avant la mise à l'échelle, Aurora Serverless v1 recherche un point de mise à l'échelle. Il le fait pendant trois jours au maximum si nécessaire.

Si, au terme de chaque journée, Aurora Serverless v1 ne trouve pas de point de mise à l'échelle, il crée un événement de cluster. Cet événement vous informe de la maintenance en attente et de la nécessité de procéder à une mise à l'échelle pour l'effectuer. Cette notification inclut la date à laquelle Aurora Serverless v1 peut forcer le cluster de bases de données à procéder à une mise à l'échelle.

Pour plus d'informations, consultez Action de délai d'attente pour les modifications de capacité.

Aurora Serverless v1 et basculement

Si l'instance de base de données pour un cluster de bases de données Aurora Serverless v1 devient indisponible ou si la zone de disponibilité dans laquelle elle se trouve échoue, Aurora recrée l'instance de base de données dans une autre zone de disponibilité. Cependant, le cluster Aurora Serverless v1 n'est pas un cluster multi-AZ. En effet, il comporte une instance de base de données unique dans une seule zone de disponibilité. Le mécanisme de basculement prend donc plus de temps pour un cluster Aurora comportant des instances Aurora Serverless v2 ou approvisionnées. Le délai de basculement d'Aurora Serverless v1 est indéfini, car il dépend de la demande et de la capacité disponible dans les autres zones de disponibilité de la Région AWS.

Étant donné qu'Aurora sépare la capacité de calcul et le stockage, le volume de stockage pour le cluster est réparti entre plusieurs zones de disponibilité. Vos données restent disponibles même si des pannes affectent l'instance de base de données ou la zone de disponibilité associée.

Aurora Serverless v1 et instantanés

Le volume de cluster d'un cluster Aurora Serverless v1 est toujours chiffré. Vous pouvez choisir la clé de chiffrement, mais vous ne pouvez pas désactiver le chiffrement. Pour copier ou partager un instantané d'un cluster Aurora Serverless v1, chiffrez cet instantané à l'aide de votre propre AWS KMS key. Pour plus d'informations, consultez Copie d'instantanés de clusters de bases. Pour en savoir plus sur le chiffrement et sur Amazon Aurora, consultez Chiffrement d'un cluster de base de données Amazon Aurora