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.

Gestion des clusters de bases de données Aurora Serverless v2

Avec Aurora Serverless v2, vos clusters sont interchangeables avec les clusters provisionnés. Les propriétés Aurora Serverless v2 s’appliquent à une ou plusieurs instances de base de données au sein d’un cluster de bases de données. Ainsi, les procédures de création de clusters, de modification de clusters, de création et de restauration d’instantanés, etc., sont essentiellement les mêmes que pour les autres types de clusters Aurora. Pour obtenir les procédures générales de gestion des clusters et des instances de base de données Aurora, consultez Gestion d’un cluster de bases de données Amazon Aurora.

Dans les rubriques suivantes, vous vous familiariserez avec les considérations relatives à la gestion des clusters contenant des instances de base de données Aurora Serverless v2.

Définition de la plage de capacité Aurora Serverless v2 d’un cluster

Pour modifier les paramètres de configuration ou d’autres paramètres pour les clusters contenant des instances de base de données Aurora Serverless v2, ou pour les instances de base de données elles-mêmes, suivez les mêmes procédures générales que pour les clusters approvisionnés. Pour en savoir plus, consultez Modification d’un cluster de bases de données Amazon Aurora.

Le paramètre le plus important propre à Aurora Serverless v2 est la plage de capacité. Après avoir défini les valeurs minimale et maximale d’unité de capacité Aurora (ACU) pour un cluster Aurora, vous n’avez pas besoin d’ajuster activement la capacité des instances de base de données Aurora Serverless v2 dans le cluster. Aurora le fait pour vous. Ce paramètre est géré au niveau du cluster. Les mêmes valeurs minimale et maximale d’ACU s’appliquent à chaque instance de base de données Aurora Serverless v2 dans le cluster.

Vous pouvez définir les valeurs spécifiques suivantes :

La plage de capacité disponible pour Aurora Serverless v2 dépend à la fois de la version du moteur de base de données et de la version de plateforme. Les nouvelles versions du moteur de base de données autorisent une capacité maximale de 256 ACU, une capacité minimale de 0 ACU ou les deux. Pour connaître les plages de capacité des différentes versions du moteur de base de données, consultez Capacité Aurora Serverless v2.

Pour la fonctionnalité de pause et de reprise automatiques activée en définissant la capacité minimale sur 0 ACU, consultez Réduction verticale à zéro ACU avec pause et reprise automatiques pour Aurora Serverless v2.

Pour déterminer comment garantir que vos clusters de bases de données Aurora Serverless v2 peuvent être augmentés verticalement jusqu’à atteindre 256 ACU, consultez Mise à niveau de votre cluster de bases de données Aurora Serverless v2 pour permettre une mise à l’échelle atteignant jusqu’à 256 ACU.

Dans Aurora Serverless v2, vous ne pouvez pas définir directement la capacité actuelle sans modifier la plage de capacité, car la capacité s’ajuste dynamiquement en fonction de la charge de travail dans la plage spécifiée. Toutefois, vous pouvez indirectement influencer la capacité de la manière suivante :

Pour plus de détails sur les effets de la plage de capacité et sur la procédure de surveillance et d’ajustement de cette dernière, consultez Métriques Amazon CloudWatch importantes pour Aurora Serverless v2 et Performances et mise à l’échelle pour Aurora Serverless v2. Votre objectif est de garantir que la capacité maximale du cluster est suffisamment élevée pour gérer les pics de charge de travail et que sa capacité minimale est suffisamment faible pour réduire les coûts lorsque le cluster n’est pas occupé.

Supposons que vous déterminiez, en fonction de votre surveillance, que la plage d’ACU du cluster doit être supérieure, inférieure, plus large ou plus étroite. Vous pouvez définir la capacité d’un cluster Aurora sur une plage spécifique d’ACU avec AWS Management Console, AWS CLI ou l’API Amazon RDS. Cette plage de capacité s’applique à chaque instance de base de données Aurora Serverless v2 dans le cluster.

Supposons par exemple que votre cluster ait une plage de capacité comprise entre 1 et 16 ACU et qu’il contienne deux instances de base de données Aurora Serverless v2. Le cluster dans son ensemble consomme entre 2 ACU (lorsqu’il est inactif) et 32 ACU (lorsqu’il est entièrement utilisé). Si vous modifiez la plage de capacité en passant de 8 à 40,5 ACU, le cluster consomme désormais 16 ACU lorsqu’il est inactif et jusqu’à 81 ACU lorsqu’il est entièrement utilisé.

Aurora définit automatiquement certains paramètres pour les instances de base de données Aurora Serverless v2 sur des valeurs qui dépendent de la valeur maximale d’ACU dans la plage de capacité. Pour obtenir la liste de ces paramètres, consultez Nombre maximal de connexions pour Aurora Serverless v2. Pour les paramètres statiques qui reposent sur ce type de calcul, la valeur est à nouveau évaluée lorsque vous redémarrez l’instance de base de données. Vous pouvez ainsi mettre à jour la valeur de ces paramètres en redémarrant l’instance de base de données après avoir modifié la plage de capacité. Pour vérifier si vous devez redémarrer votre instance de base de données afin d’appliquer les modifications apportées aux paramètres, vérifiez l’attribut ParameterApplyStatus de l’instance de base de données. La valeur pending-reboot indique que le redémarrage appliquera les modifications à certaines valeurs de paramètres.

Mise à niveau de votre cluster de bases de données Aurora Serverless v2 pour permettre une mise à l’échelle atteignant jusqu’à 256 ACU

Dans certains cas, lorsque vous essayez de mettre à l’échelle votre cluster de bases de données Aurora Serverless v2 afin d’atteindre des capacités supérieures à 128 ACU, vous recevez un message d’erreur. Le message d’erreur vous indique quelles instances sont incompatibles avec la nouvelle plage de mise à l’échelle. Cela met en évidence la relation importante entre votre plage de capacité, la version du moteur de base de données et la version de plateforme.

L’impossibilité d’aller au-delà de 128 ACU peut se produire pour l’une des deux raisons suivantes :

Vérification de la plage de capacité pour Aurora Serverless v2

La procédure de vérification de la plage de capacité de votre cluster Aurora Serverless v2 exige de commencer par définir une plage de capacité. Si vous ne l’avez pas fait, suivez la procédure de la rubrique Définition de la plage de capacité Aurora Serverless v2 d’un cluster.

Quelle que soit la plage de capacité que vous définissez au niveau du cluster, elle s’applique à toutes les instances de base de données Aurora Serverless v2 de votre cluster. L’image suivante représente un cluster contenant plusieurs instances de base de données Aurora Serverless v2. Chacune possède une plage de capacité identique.

Vous pouvez également afficher la page de détails de n’importe quelle instance de base de données Aurora Serverless v2 du cluster. La plage de capacité des instances de base de données s’affiche dans l’onglet Configuration.

Vous pouvez également consulter la plage de capacité actuelle du cluster sur la page Modify (Modifier) du cluster. À ce stade, vous pouvez modifier la plage de capacité. Pour connaître toutes les façons de définir ou modifier la plage de capacité, consultez Définition de la plage de capacité Aurora Serverless v2 d’un cluster.

Vérification de la plage de capacité actuelle d’un cluster Aurora

Vous pouvez vérifier la plage de capacité configurée pour les instances de base de données Aurora Serverless v2 d’un cluster en examinant l’attribut ServerlessV2ScalingConfiguration du cluster. L’exemple d’AWS CLI suivant illustre un cluster dont la capacité minimale est de 0,5 unités de capacité Aurora (ACU) et la capacité maximale est de 16 ACU.

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-64-acu-cluster \
  --query 'DBClusters[*].[ServerlessV2ScalingConfiguration]'
[
    [
        {
            "MinCapacity": 0.5,
            "MaxCapacity": 16.0
        }
    ]
]

Ajout d’un lecteur Aurora Serverless v2

Pour ajouter une instance de base de données de lecteur Aurora Serverless v2 à votre cluster, suivez la même procédure générale que celle de la rubrique Ajout de réplicas Aurora à un cluster de bases de données. Choisissez la classe d’instance Sans serveur v2 pour la nouvelle instance de base de données.

Si l’instance de base de données de lecteur est la première instance de base de données Aurora Serverless v2 du cluster, vous choisissez également la plage de capacité. Ce paramètre s’applique à cette instance de base de données de lecteur et à toutes les autres instances de base de données Aurora Serverless v2 que vous ajoutez au cluster. Chaque instance de base de données Aurora Serverless v2 peut être mise à l’échelle entre les valeurs minimale et maximale d’ACU.

Si d’autres instances Aurora Serverless v2 se trouvent déjà dans le cluster, la boîte de dialogue Ajouter un lecteur indique la plage de capacité actuelle du cluster. Dans ce cas, vous ne pouvez pas modifier la capacité. L’image suivante présente le rapport de la capacité actuelle du cluster.

Si vous avez déjà ajouté des instances de base de données Aurora Serverless v2 au cluster, l’ajout d’une autre instance de base de données de lecteur Aurora Serverless v2 affiche la plage de capacité actuelle. L’image suivante illustre ces paramètres en lecture seule.

Si vous souhaitez modifier la plage de capacité du cluster, suivez la procédure de la rubrique Définition de la plage de capacité Aurora Serverless v2 d’un cluster.

Pour les clusters contenant plusieurs instances de base de données de lecteur, la priorité de basculement de chaque instance de base de données de lecteur Aurora Serverless v2 joue un rôle important dans l’augmentation et la réduction d’échelle de cette instance de base de données. Vous ne pouvez pas spécifier la priorité lors de la création initiale du cluster. Gardez cette propriété à l’esprit lorsque vous ajoutez une deuxième instance de base de données de lecteur à votre cluster. Pour plus d’informations, consultez Choix du niveau de promotion pour un lecteur Aurora Serverless v2.

Pour savoir comment afficher la plage de capacité actuelle d’un cluster, consultez Vérification de la plage de capacité pour Aurora Serverless v2.

Conversion d’un lecteur ou d’un enregistreur approvisionné en Aurora Serverless v2

Vous pouvez convertir une instance de base de données approvisionnée de sorte qu’elle utilise Aurora Serverless v2. Pour ce faire, suivez la procédure décrite à la rubrique Modification d’une instance de base de données dans un cluster de bases de données. Le cluster doit satisfaire aux Exigences et limites relatives à Aurora Serverless v2. Par exemple, les instances de base de données Aurora Serverless v2 exigent que le cluster exécute certaines versions minimales du moteur.

Supposons que vous convertissiez un cluster approvisionné en cours d’exécution pour tirer parti d’Aurora Serverless v2. Dans ce cas, vous pouvez réduire la durée d’indisponibilité en convertissant une instance de base de données en Aurora Serverless v2 dans le cadre de la première étape du processus de bascule. Pour obtenir la procédure complète, consultez Basculement d’un cluster approvisionné vers Aurora Serverless v2.

Si l’instance de base de données que vous convertissez est la première instance de base de données Aurora Serverless v2 du cluster, vous choisissez la plage de capacité du cluster dans le cadre de l’opération Modify (Modifier). Cette plage de capacité s’applique à chaque instance de base de données Aurora Serverless v2 que vous ajoutez au cluster. L’image suivante illustre la page sur laquelle vous spécifiez les nombres minimal et maximal d’unités de capacité Aurora (ACU).

Pour plus de détails sur l’importance de la plage de capacité, consultez Capacité Aurora Serverless v2.

Si le cluster contient déjà une ou plusieurs instances de base de données Aurora Serverless v2, la plage de capacité existante s’affiche pendant l’opération Modify (Modifier). L’image suivante illustre un exemple de ce panneau d’informations.

Si vous souhaitez modifier la plage de capacité du cluster après avoir ajouté plusieurs instances de base de données Aurora Serverless v2, suivez la procédure de la rubrique Définition de la plage de capacité Aurora Serverless v2 d’un cluster.

Conversion d’un lecteur ou d’un enregistreur Aurora Serverless v2 en mode approvisionné

Vous pouvez convertir une instance de base de données Aurora Serverless v2 en instance de base de données approvisionnée. Pour ce faire, suivez la procédure décrite à la rubrique Modification d’une instance de base de données dans un cluster de bases de données. Choisissez une classe d’instance de base de données autre que Sans serveur.

Vous pouvez convertir une instance de base de données Aurora Serverless v2 en mode approvisionné si elle a besoin d’une capacité supérieure à celle disponible avec le nombre maximal d’unités de capacité Aurora (ACU) d’une instance de base de données Aurora Serverless v2. Par exemple, les classes d’instance de base de données db.r5 et db.r6g les plus grandes ont une capacité de mémoire supérieure à celle à laquelle une instance de base de données Aurora Serverless v2 peut être mise à l’échelle.

Si vous convertissez l’instance de base de données d’enregistreur de votre cluster d’Aurora Serverless v2 en mode approvisionné, vous pouvez suivre la procédure de la rubrique Basculement d’un cluster approvisionné vers Aurora Serverless v2, mais en sens inverse. Basculez l’une des instances de base de données de lecteur du cluster d’Aurora Serverless v2 vers le mode approvisionné. Effectuez ensuite un basculement pour intégrer cette instance de base de données approvisionnée dans l’enregistreur.

Toute plage de capacité que vous avez précédemment spécifiée pour le cluster reste en place, même si toutes les instances de base de données Aurora Serverless v2 sont retirées du cluster. Si vous souhaitez modifier la plage de capacité, vous pouvez modifier le cluster, comme expliqué à la rubrique Définition de la plage de capacité Aurora Serverless v2 d’un cluster.

Mise en pause des instances de base de données Aurora Serverless v2

Vous pouvez configurer les clusters Aurora pour mettre en pause et reprendre automatiquement leurs instances de base de données Aurora Serverless v2. Pour plus d’informations, consultez Réduction verticale à zéro ACU avec pause et reprise automatiques pour Aurora Serverless v2.

Choix du niveau de promotion pour un lecteur Aurora Serverless v2

Pour les clusters contenant plusieurs instances de base de données Aurora Serverless v2 ou un mélange d’instances de base de données approvisionnées et Aurora Serverless v2, prêtez attention au paramètre de niveau de promotion pour chaque instance de base de données Aurora Serverless v2. Ce paramètre contrôle davantage le comportement des instances de base de données Aurora Serverless v2 que celui des instances de base de données approvisionnées.

Dans AWS Management Console, vous spécifiez cette valeur à l’aide du paramètre Failover priority (Priorité de basculement) sous Additional configuration (Configuration supplémentaire) pour les pages Create database (Créer une base de données), Modify instance (Modifier une instance) et Add reader (Ajouter un lecteur). Cette propriété s’affiche pour les instances de base de données existantes dans la colonne facultative Niveau de priorité sur la page Bases de données. Cette propriété est également disponible sur la page de détails d’un cluster de bases de données ou d’une instance de base de données.

Pour les instances de base de données approvisionnées, le choix du niveau 0–15 détermine uniquement l’ordre dans lequel Aurora choisit l’instance de base de données de lecteur à promouvoir en enregistreur lors d’une opération de basculement. Pour les instances de base de données de lecteur Aurora Serverless v2, le numéro de niveau détermine également si l’instance de base de données fait l’objet d’une augmentation d’échelle pour correspondre à la capacité de l’instance de base de données d’enregistreur ou si elle est mise à l’échelle indépendamment en fonction de sa propre charge de travail. Les instances de base de données de lecteur Aurora Serverless v2 de niveau 0 ou 1 restent à une capacité minimale au moins égale à celle de l’instance de base de données d’enregistreur. De cette façon, elles sont prêtes à prendre le relais de l’instance de base de données d’enregistreur en cas de basculement. Si l’instance de base de données d’enregistreur est une instance de base de données approvisionnée, Aurora estime la capacité Aurora Serverless v2 équivalente. Il utilise cette estimation comme capacité minimale pour l’instance de base de données de lecteur Aurora Serverless v2.

Les instances de base de données de lecteur Aurora Serverless v2 des niveaux 2 à 15 n’ont pas la même contrainte de capacité minimale. Lorsqu’elles sont inactives, elles peuvent faire l’objet d’une réduction d’échelle à la valeur minimale d’unité de capacité Aurora (ACU) spécifiée dans la plage de capacité du cluster.

L’exemple d’AWS CLI suivant sous Linux montre comment examiner les niveaux de promotion de toutes les instances de base de données de votre cluster. Le dernier champ comporte la valeur True pour l’instance de base de données d’enregistreur et la valeur False pour toutes les instances de base de données de lecteur.

$ aws rds describe-db-clusters --db-cluster-identifier promotion-tier-demo \
  --query 'DBClusters[*].DBClusterMembers[*].[PromotionTier,DBInstanceIdentifier,IsClusterWriter]' \
  --output text

1   instance-192  True
1   tier-01-4840  False
10  tier-10-7425  False
15  tier-15-6694  False

L’exemple d’AWS CLI suivant sous Linux montre comment modifier le niveau de promotion d’une instance de base de données spécifique de votre cluster. Les commandes commencent par modifier l’instance de base de données avec un nouveau niveau de promotion. Elles attendent ensuite que l’instance de base de données soit à nouveau disponible et confirment le nouveau niveau de promotion pour l’instance de base de données.

$ aws rds modify-db-instance --db-instance-identifier instance-192 --promotion-tier 0
$ aws rds wait db-instance-available --db-instance-identifier instance-192
$ aws rds describe-db-instances --db-instance-identifier instance-192 \
  --query '*[].[PromotionTier]' --output text
0

Pour plus d’informations sur la spécification de niveaux de promotion pour différents cas d’utilisation, consultez Mise à l’échelle d’Aurora Serverless v2.

Utilisation de TLS/SSL avec Aurora Serverless v2

Aurora Serverless v2 peut utiliser le protocole TLS/SSL (Transport Layer Security/Secure Sockets Layer) pour chiffrer les communications entre les clients et vos instances de base de données Aurora Serverless v2. Il prend en charge les versions TLS/SSL 1.0, 1.1 et 1.2. Pour obtenir des informations générales sur l’utilisation de TLS/SSL avec Aurora, consultez Connexions TLS aux clusters de bases de données Aurora MySQL.

Pour en savoir plus sur la connexion à la base de données Aurora MySQL avec le client MySQL, consultez Connexion à une instance de base de données exécutant le moteur de base de données MySQL.

Aurora Serverless v2 prend en charge tous les modes TLS/SSL disponibles pour le client MySQL (mysql) et le client PostgreSQL (psql), y compris les modes répertoriés dans le tableau suivant.

Aurora Serverless v2 utilise des certificats à caractères génériques. Si vous spécifiez l’option « Vérifier l’autorité de certification » ou « Vérifier l’autorité de certification et son nom d’hôte » lors de l’utilisation de TLS/SSL, commencez par télécharger le référentiel d’approbations Amazon Root CA 1 à partir d’Amazon Trust Services. Vous pouvez ensuite identifier ce fichier au format PEM dans votre commande client. Pour ce faire à l’aide du client PostgreSQL, procédez comme suit.

Pour Linux, macOS ou Unix :

psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'

Pour en savoir plus sur l’utilisation de la base de données Aurora PostgreSQL à l’aide du client Postgres, consultez Connexion à une instance de base de données exécutant le moteur de base de données PostgreSQL.

Pour plus d’informations sur la connexion aux clusters de bases de données Aurora, consultez Connexion à un cluster de bases de données Amazon Aurora.

Suites de chiffrement prises en charge pour les connexions aux clusters de bases de données Aurora Serverless v2

L’utilisation de suites de chiffrement configurables vous permet d’avoir plus de contrôle sur la sécurité des connexions de vos bases de données. Vous pouvez spécifier une liste de suites de chiffrement que vous souhaitez autoriser pour la sécurisation des connexions TLS/SSL client à votre base de données. Avec les suites de chiffrement configurables, vous pouvez contrôler le chiffrement de connexion accepté par votre serveur de base de données. Cela évite d’utiliser des chiffrements qui ne sont pas sécurisés ou qui ne sont plus utilisés.

Les clusters de bases de données Aurora Serverless v2 basés sur Aurora MySQL prennent en charge les mêmes suites de chiffrement que les clusters de bases de données provisionnés Aurora MySQL. Pour plus d’informations sur ces suites de chiffrement, consultez Configuration de suites de chiffrement pour les connexions aux clusters de bases de données Aurora MySQL.

Les clusters de bases de données Aurora Serverless v2 basés sur Aurora PostgreSQL prennent en charge les mêmes suites de chiffrement que les clusters de bases de données provisionnés Aurora PostgreSQL. Pour plus d’informations sur ces suites de chiffrement, consultez Configuration de suites de chiffrement pour les connexions aux clusters de bases de données Aurora PostgreSQL.

Affichage d’enregistreurs et de lecteurs Aurora Serverless v2

Vous pouvez afficher les détails des instances de base de données Aurora Serverless v2 de la même manière que pour les instances de base de données approvisionnées. Pour ce faire, suivez la procédure générale de la rubrique Affichage d’un cluster de bases de données Amazon Aurora. Un cluster peut contenir toutes les instances de base de données Aurora Serverless v2, toutes les instances de base de données approvisionnées ou quelques-unes de chaque type.

Après avoir créé une ou plusieurs instances de base de données Aurora Serverless v2, vous pouvez voir les instances de base de données qui sont de type Sans serveur et celles qui sont de type Instance. Vous pouvez également afficher les nombres minimal et maximal d’unités de capacité Aurora (ACU) que l’instance de base de données Aurora Serverless v2 peut utiliser. Chaque unité de capacité est une combinaison de traitement (UC) et de capacité mémoire (RAM). Cette plage de capacité s’applique à chaque instance de base de données Aurora Serverless v2 dans le cluster. Pour obtenir la procédure de vérification de la plage de capacité d’un cluster ou d’une instance de base de données Aurora Serverless v2 dans le cluster, consultez Vérification de la plage de capacité pour Aurora Serverless v2.

Dans AWS Management Console, les instances de base de données Aurora Serverless v2 sont marquées sous la colonne Size (Taille) sur la page Databases (Bases de données). Les instances de base de données approvisionnées affichent le nom d’une classe d’instance de base de données telle que r6g.xlarge. Les instances de base de données Aurora Serverless indiquent Sans serveur pour la classe d’instance de base de données, ainsi que les capacités minimale et maximale de l’instance de base de données. Par exemple, Sans serveur v2 (4–64 ACUs) ou Sans serveur v2 (1–40 ACUs) peuvent s’afficher.

Vous trouverez les mêmes informations dans l’onglet Configuration de chaque instance de base de données Aurora Serverless v2 dans la console. Par exemple, une section Instance type (Type d’instance) qui ressemble à ce qui suit peut s’afficher. Ici, la valeur de Type d’instance est Sans serveur v2, la valeur de Capacité minimale est 2 ACU (4 Gio) et la valeur de Capacité maximale est 64 ACU (128 Gio).

Vous pouvez surveiller la capacité de chaque instance de base de données Aurora Serverless v2 au fil du temps. De cette façon, vous pouvez vérifier les nombres minimal, maximal et moyen d’ACU consommées par chaque instance de base de données. Vous pouvez également vérifier à quel point l’instance de base de données s’est rapprochée de sa capacité minimale ou maximale. Pour afficher ces détails dans AWS Management Console, examinez les graphiques des métriques Amazon CloudWatch dans l’onglet Monitoring (Surveillance) de l’instance de base de données. Pour plus d’informations sur les métriques à surveiller et comment les interpréter, consultez Métriques Amazon CloudWatch importantes pour Aurora Serverless v2.

Journalisation pour Aurora Serverless v2

Pour activer la journalisation de la base de données, spécifiez les journaux à activer à l’aide des paramètres de configuration dans votre groupe de paramètres personnalisé.

Pour Aurora MySQL, vous pouvez activer les journaux suivants.

Pour plus d’informations, consultez Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL.

Pour Aurora PostgreSQL, vous pouvez activer les journaux suivants sur vos instances de base de données Aurora Serverless v2.

Journalisation avec Amazon CloudWatch

Après avoir utilisé la procédure de Journalisation pour Aurora Serverless v2 pour choisir les journaux de base de données à activer, vous pouvez choisir les journaux à charger (« publier ») sur Amazon CloudWatch.

Vous pouvez utiliser Amazon CloudWatch pour analyser les données des journaux, créer des alarmes et afficher des métriques. Par défaut, les journaux d’erreurs pour Aurora Serverless v2 sont activés et automatiquement chargés sur CloudWatch. Vous pouvez également charger d’autres journaux depuis les instances de base de données Aurora Serverless v2 sur CloudWatch.

Vous choisissez ensuite les journaux à charger sur CloudWatch, en utilisant les paramètres Log exports (Exportations de journaux) dans AWS Management Console ou l’option --enable-cloudwatch-logs-exports dans AWS CLI.

Vous pouvez choisir les journaux Aurora Serverless v2 à charger sur CloudWatch. Pour plus d’informations, consultez Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL.

Comme n’importe quel autre type de cluster de bases de données Aurora, vous ne pouvez pas modifier le groupe de paramètres de cluster de bases de données par défaut. Créez votre propre groupe de paramètres de cluster de bases de données basé sur un paramètre par défaut pour votre cluster de bases de données et votre type de moteur. Nous vous recommandons de créer votre groupe de paramètres de cluster de bases de données personnalisé avant de créer votre cluster de bases de données Aurora Serverless v2 et ce, de sorte qu’il soit disponible lorsque vous créez une base de données sur la console.

Affichage de journaux Aurora Serverless v2 dans Amazon CloudWatch

Après avoir utilisé la procédure de la rubrique Journalisation avec Amazon CloudWatch pour choisir les journaux de base de données à activer, vous pouvez afficher le contenu des journaux.

Pour plus d’informations sur l’utilisation de CloudWatch avec les journaux Aurora MySQL et Aurora PostgreSQL, consultez Surveillance des événements de journaux dans Amazon CloudWatch et Publication de journaux Aurora PostgreSQL sur Amazon CloudWatch Logs.

Capacité de surveillance avec Amazon CloudWatch

Avec Aurora Serverless v2, vous pouvez utiliser CloudWatch pour surveiller la capacité et l’utilisation de l’ensemble des instances de base de données Aurora Serverless v2 de votre cluster. Vous pouvez afficher les métriques au niveau de l’instance pour vérifier la capacité de chaque instance de base de données Aurora Serverless v2 en fonction de leur augmentation/réduction d’échelle. Vous pouvez également comparer les métriques de capacité avec d’autres métriques pour voir comment les modifications apportées aux charges de travail affectent la consommation des ressources. Par exemple, vous pouvez comparer ServerlessDatabaseCapacity avec DatabaseUsedMemory, DatabaseConnections et DMLThroughput pour évaluer la manière dont votre cluster de bases de données répond lors des opérations. Pour plus de détails sur les métriques de capacité qui s’appliquent à Aurora Serverless v2, consultez Métriques Amazon CloudWatch importantes pour Aurora Serverless v2.

Nous vous recommandons de configurer un tableau de bord CloudWatch pour surveiller la capacité de votre cluster de bases de données Aurora Serverless v2 à l’aide des métriques de capacité. Pour en savoir plus, consultez Création de tableaux de bord avec CloudWatch.

Pour en savoir plus sur l’utilisation d’Amazon CloudWatch avec Amazon Aurora, consultez Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs.

Surveillance de l’activité de mise en pause et de reprise d’Aurora Serverless v2

Aurora écrit un fichier journal distinct pour les instances de base de données Aurora Serverless v2 pour lesquelles la pause automatique est activée. Aurora écrit dans le journal pour chaque intervalle de 10 minutes pendant lequel l’instance n’est pas mise en pause. Aurora conserve jusqu’à sept de ces journaux, qui font l’objet d’une rotation quotidienne. Le fichier journal actuel est nommé instance.log, et les anciens journaux sont nommés selon le modèle instance.YYYY-MM-DD.N.log.

Ce journal est activé par défaut pour les instances de base de données Aurora Serverless v2 pour lesquelles la pause automatique est activée. Vous pouvez consulter le contenu de ce journal dans la AWS Management Console ou en utilisant l’AWS CLI ou l’API RDSP. Actuellement, vous ne pouvez pas charger ce journal sur CloudWatch.

Les événements répertoriés dans Événements d’instance de base de données fournissent une vue d’ensemble globale des activités de pause et de reprise, tels que les suivants :

instance.log fournit des informations plus détaillées sur les raisons pour lesquelles une instance Aurora Serverless v2 a pu être mise en pause ou non.

Le journal peut indiquer qu’une instance a repris pour différentes raisons :

Lorsqu’Aurora n’a connaissance d’aucune condition susceptible d’empêcher l’instance de se mettre en pause à l’expiration de l’intervalle de pause automatique, un message d’information est régulièrement écrit dans le journal. Pour les clusters dotés d’une seule instance de base de données, le journal contient le message suivant :

[INFO] No auto-pause blockers registered since time

Pour les clusters comportant plusieurs instances de base de données, le message est légèrement différent. Cela est dû au fait qu’un enregistreur peut être incapable de se mettre en pause en raison de l’activité sur l’une des instances du lecteur. Si l’activité du lecteur se termine avant l’expiration de l’intervalle de pause automatique pour l’enregistreur, ce dernier pourra se mettre en pause à l’heure prévue.

[INFO] No auto-pause blockers registered since time.
Database might be required to maintain compute capacity for high availability.

Si une opération de pause démarre, mais qu’une nouvelle demande de connexion à la base de données arrive avant la fin de la pause de l’instance, le journal contient le message suivant :

[INFO] Unable to pause database due to a new database activity

Si Aurora découvre des conditions qui empêchent définitivement l’instance de se mettre en pause, le journal contient le message suivant qui répertorie toutes ces conditions :

[INFO] Auto-pause blockers registered since time: list_of_conditions

De cette façon, Aurora ne vous empêche pas d’activer la réplication, l’intégration zéro ETL, Aurora Global Database, etc. en combinaison avec la fonction de pause automatique. Le journal vous informe lorsque l’utilisation de telles fonctionnalités peut empêcher la mise en pause automatique de prendre effet.

Les raisons suivantes peuvent expliquer pourquoi une instance Aurora Serverless v2 peut dépasser le délai d’expiration de la pause automatique, sans toutefois pouvoir se mettre en pause :