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
Avec Aurora serverless, vos clusters sont interchangeables avec les clusters provisionnés. Les propriétés Aurora serverless 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](CHAP_Aurora.md).
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.
**Topics**
+ [Définition de la plage de capacité Aurora serverless d’un cluster](#aurora-serverless-v2-setting-acus)
+ [Vérification de la plage de capacité pour Aurora serverless](#aurora-serverless-v2-checking-capacity)
+ [Vérifier la version de la plateforme pour un Aurora serverless cluster existant](#aurora-serverless-v2-checking-platform-version)
+ [Ajout d’un lecteur Aurora serverless](#aurora-serverless-v2-adding-reader)
+ [Conversion d’un lecteur ou d’un enregistreur approvisionné en Aurora serverless](#aurora-serverless-v2-converting-from-provisioned)
+ [Conversion d’un lecteur ou d’un enregistreur Aurora serverless en mode approvisionné](#aurora-serverless-v2-converting-to-provisioned)
+ [Mise en pause des instances de base de données Aurora serverless](#pause-when-inactive)
+ [Choix du niveau de promotion pour un lecteur Aurora serverless](#aurora-serverless-v2-choosing-promotion-tier)
+ [Utilisation TLS/SSL avec Aurora serverless](#aurora-serverless-v2.tls)
+ [Affichage d’enregistreurs et de lecteurs Aurora serverless](#aurora-serverless-v2.viewing)
+ [Journalisation pour Aurora serverless](#aurora-serverless-v2.logging)
## Définition de la plage de capacité Aurora serverless 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, 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](Aurora.Modifying.md).
Le paramètre le plus important propre à Aurora serverless 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 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 dans le cluster.
Vous pouvez définir les valeurs spécifiques suivantes :
+ **Minimum ACUs** (Nombre minimal d’ACU) : l’instance de base de données Aurora serverless peut réduire la capacité à ce nombre d’ACU.
+ **Nombre maximal d’ACU** : l’instance de base de données Aurora serverless peut augmenter la capacité à ce nombre d’ACU.
La plage de capacité disponible pour Aurora serverless 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](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
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](aurora-serverless-v2-auto-pause.md).
Pour déterminer comment garantir que vos clusters de bases de données Aurora serverless peuvent être augmentés verticalement jusqu’à atteindre 256 ACU, consultez [Mise à niveau de votre cluster de bases de données Aurora serverless pour permettre une mise à l’échelle atteignant jusqu’à 256 ACU](#setting-256-acus).
**Note**
Lorsque vous modifiez la plage de capacité d’un cluster de bases de données Aurora serverless, la modification intervient immédiatement, que vous choisissiez de l’appliquer immédiatement ou lors du prochain créneau de maintenance planifié.
Dans Aurora serverless, 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 :
+ **Ajuster la capacité minimale** : réduisez temporairement la capacité minimale pour réduire la capacité de base lorsque les charges de travail sont faibles.
+ **Interrompre temporairement la mise à l’échelle** : pour fixer la capacité sur une valeur spécifique, réglez les capacités minimale et maximale au même niveau.
+ **Mettre à l’échelle de manière proactive en cas d’utilisation intensive** : si vous prévoyez des charges de travail élevées, augmentez au préalable la capacité minimale afin de maintenir une base de référence plus élevée pendant les périodes de forte activité.
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 [Statistiques Amazon CloudWatch importantes pour Aurora serverless](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring) et [Performances et mise à l’échelle pour Aurora serverless](aurora-serverless-v2.setting-capacity.md). 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 à l'aide de l' AWS Management Console API Amazon RDS ou de l'API Amazon RDS. AWS CLI Cette plage de capacité s’applique à chaque instance de base de données Aurora serverless 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. 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 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](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections). 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.
### Console
Vous pouvez définir la plage de capacité d’un cluster qui contient des instances de base de données Aurora serverless avec AWS Management Console.
Lorsque vous utilisez la console, vous définissez la plage de capacité du cluster au moment d’ajouter la première instance de base de données Aurora serverless à ce cluster. Vous pouvez le faire lorsque vous choisissez la classe d’instance de base de données **sans serveur v2** pour l’instance de base de données d’enregistreur lorsque vous créez le cluster. Vous pouvez également le faire lorsque vous choisissez la classe d’instance de base de données **Sans serveur** au moment d’ajouter une instance de base de données de lecteur Aurora serverless au cluster. Vous pouvez aussi le faire lorsque vous convertissez une instance de base de données approvisionnée existante dans le cluster en classe d’instance de base de données **Sans serveur**. Pour en savoir plus sur les versions complètes de ces procédures, consultez [Création d’une instance de base de données d’enregistreur Aurora serverless](aurora-serverless-v2.create.md#aurora-serverless-v2-adding-writer), [Ajout d’un lecteur Aurora serverless](#aurora-serverless-v2-adding-reader) et [Conversion d’un lecteur ou d’un enregistreur approvisionné en Aurora serverless](#aurora-serverless-v2-converting-from-provisioned).
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 de votre cluster. L’image suivante représente un cluster contenant plusieurs instances de base de données de lecteur Aurora serverless. Chacune possède une plage de capacité identique de 2 à 64 ACU.
**Pour modifier la plage de capacité d’un cluster Aurora serverless**
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Databases** (Bases de données).
1. Choisissez le cluster contenant vos instances de base de données Aurora serverless dans la liste. Le cluster doit déjà contenir au moins une instance de base de données Aurora serverless. Sinon, Aurora n’affiche pas la section **Capacity range** (Plage de capacité).
1. Pour **Actions**, choisissez **Modify** (Modifier).
1. Dans la section **Capacity range** (Plage de capacité), choisissez les valeurs suivantes :
1. Saisissez une valeur pour **Minimum ACUs** (Nombre minimal d’ACU). La console affiche la plage de valeurs autorisée. Vous pouvez choisir une capacité minimale comprise entre 0 et 256 ACU. Vous pouvez choisir une capacité maximale comprise entre 1 et 256 ACU. Vous pouvez ajuster les valeurs de capacité par incréments de 0,5 ACU. La plage de capacité disponible dépend à la fois de la version de votre moteur de base de données et de la version de plateforme.
1. Saisissez une valeur pour **Maximum ACUs** (Nombre maximal d’ACU). Cette valeur doit être supérieure ou égale à la valeur de **Minimum ACUs** (Nombre minimal d’ACU). La console affiche la plage de valeurs autorisée. La figure suivante illustre ce choix.
1. Choisissez **Continuer**. La page **Récapitulatif des modifications** s’affiche.
1. Choisissez **Apply immediately (Appliquer immédiatement)**.
La modification de la capacité a lieu immédiatement, que vous choisissiez de l’appliquer immédiatement ou au cours du prochain créneau de maintenance planifié.
1. Choisissez **Modifier le cluster** pour accepter le récapitulatif des modifications. Vous pouvez également choisir **Précédent** pour modifier vos modifications ou **Annuler** pour les ignorer.
### AWS CLI
Pour définir la capacité d'un cluster dans lequel vous souhaitez utiliser des Aurora serverless instances de base de données à l'aide de AWS CLI, exécutez la commande [AWS CLI modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Spécifiez l’option `--serverless-v2-scaling-configuration`. Il est possible que le cluster contienne déjà une ou plusieurs instances de base de données Aurora serverless. Vous pouvez également ajouter les instances de base de données ultérieurement. Les valeurs valides pour les champs `MinCapacity` et `MaxCapacity` sont les suivantes :
+ `0`, `0.5`, `1`, `1.5`, `2`, etc. par paliers de 0,5, jusqu’à un maximum de 256. La valeur d’ACU minimale 0 n’est disponible que pour les versions d’Aurora qui prennent en charge la fonctionnalité de pause automatique.
La capacité maximale disponible dépend à la fois de la version de votre moteur de base de données et de la version de la plateforme.
Dans cet exemple, vous définissez la plage d’ACU d’un cluster de bases de données Aurora nommé`sample-cluster` sur une valeur minimale de `48.5` et une valeur maximale de 64.
```
aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=48.5,MaxCapacity=64
```
La modification de la capacité a lieu immédiatement, que vous choisissiez de l’appliquer immédiatement ou au cours du prochain créneau de maintenance planifié.
Vous pouvez ensuite ajouter les instances de base de données Aurora serverless au cluster et chaque nouvelle instance de base de données peut être mise à l’échelle entre 48,5 et 64 ACU. La nouvelle plage de capacité s’applique également à toutes les instances de base de données Aurora serverless qui se trouvaient déjà dans le cluster. Les instances de base de données font l’objet d’une augmentation ou d’une réduction d’échelle si nécessaire pour se situer dans la nouvelle plage de capacité.
Pour obtenir d’autres exemples de définition de la plage de capacité à l’aide de l’interface de ligne de commande, consultez [Choix de la plage de capacité Aurora serverless pour un cluster Aurora](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster).
Pour modifier la configuration de dimensionnement d'un Aurora Serverless cluster de base de données à l'aide de AWS CLI, exécutez la commande [AWS CLI modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Spécifiez l’option `--serverless-v2-scaling-configuration` pour configurer la capacité minimale et la capacité maximale. Les valeurs de capacité valides sont notamment les suivantes :
+ Aurora MySQL : `0`, `0.5`, `1`, `1.5`, `2`, etc. par incréments de 0,5 ACU jusqu’à un maximum de `256`.
+ Aurora PostgreSQL : `0`, `0.5`, `1`, `1.5`, `2`, etc. par incréments de 0,5 ACU jusqu’à un maximum de `256`.
+ La valeur d’ACU minimale 0 n’est disponible que pour les versions d’Aurora qui prennent en charge la fonctionnalité de pause automatique.
Dans l’exemple suivant, vous modifiez la configuration de mise à l’échelle d’une instance de base de données Aurora serverless nommée `sample-instance` qui fait partie d’un cluster nommé `sample-cluster`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64
```
Pour Windows :
```
aws rds modify-db-cluster --db-cluster-identifier sample-cluster ^
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64
```
### API RDS
Vous pouvez définir la capacité d’une instance de base de données Aurora avec l’opération d’API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Spécifiez le paramètre `ServerlessV2ScalingConfiguration`. Les valeurs valides pour les champs `MinCapacity` et `MaxCapacity` sont les suivantes :
+ `0`, `0.5`, `1`, `1.5`, `2`, etc. par paliers de 0,5, jusqu’à un maximum de 256. La valeur d’ACU minimale 0 n’est disponible que pour les versions d’Aurora qui prennent en charge la fonctionnalité de pause automatique.
Vous pouvez modifier la configuration de mise à l’échelle d’un cluster contenant des instances de base de données Aurora serverless avec l’opération d’API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Spécifiez le paramètre `ServerlessV2ScalingConfiguration` pour configurer la capacité minimale et la capacité maximale. Les valeurs de capacité valides sont notamment les suivantes :
+ Aurora MySQL : `0`, `0.5`, `1`, `1.5`, `2`, etc. par incréments de 0,5 ACU jusqu’à un maximum de `256`.
+ Aurora PostgreSQL : `0`, `0.5`, `1`, `1.5`, `2`, etc. par incréments de 0,5 ACU jusqu’à un maximum de `256`.
+ La valeur d’ACU minimale 0 n’est disponible que pour les versions d’Aurora qui prennent en charge la fonctionnalité de pause automatique.
La capacité maximale disponible dépend à la fois de la version de votre moteur de base de données et de la version de la plateforme.
La modification de la capacité a lieu immédiatement, que vous choisissiez de l’appliquer immédiatement ou au cours du prochain créneau de maintenance planifié.
### Mise à niveau de votre cluster de bases de données Aurora serverless 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 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 :
+ Ancienne version du moteur de base de données : mettez à niveau la version du moteur de base de données vers une version prenant en charge 256 ACU. Pour plus d’informations, consultez [Capacité Aurora serverless](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
+ Ancienne version de plateforme : mettez à niveau la plateforme pour votre cluster de bases de données Aurora serverless. Vous pouvez effectuer cette opération de différentes manières :
+ Arrêtez et redémarrez le cluster de bases de données. Lorsque le cluster redémarrera, il utilisera la dernière version de plateforme compatible, qui peut autoriser un nombre maximum d’ACU plus élevé.
Cependant, l’arrêt et le démarrage d’un cluster de bases de données entraînent une durée d’indisponibilité, généralement de plusieurs minutes. Pour de plus amples informations, veuillez consulter [Arrêt et démarrage d’un cluster de bases de données Amazon Aurora](aurora-cluster-stop-start.md).
+ Utilisez un blue/green déploiement. Pour de plus amples informations, veuillez consulter [Présentation des (Amazon Aurora Blue/Green )](blue-green-deployments-overview.md).
1. Créez un blue/green déploiement. Pour de plus amples informations, veuillez consulter [Création d'un blue/green déploiement dans )](blue-green-deployments-creating.md).
1. Vérifiez que vous pouvez définir la capacité maximale de l’environnement intermédiaire (vert) sur 256 ACU.
1. Passez à l’environnement vert. Pour plus d’informations, consultez [Changer de blue/green déploiement dans )](blue-green-deployments-switching.md).
1. Supprimez le cluster de bases de données d’origine.
**Note**
Si vous conservez les informations d'identification de votre base de données dans AWS Secrets Manager, vous ne pouvez pas utiliser blue/green les déploiements.
Aurora Global Database ne prend pas en charge les blue/green déploiements.
**Important :** une fois que vous avez effectué la mise à niveau vers une version plus récente de la plateforme, vous ne pouvez pas revenir à une version précédente.
## Vérification de la plage de capacité pour Aurora serverless
La procédure de vérification de la plage de capacité de votre cluster Aurora serverless 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 d’un cluster](#aurora-serverless-v2-setting-acus).
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 de votre cluster. L’image suivante représente un cluster contenant plusieurs instances de base de données Aurora serverless. 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 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 d’un cluster](#aurora-serverless-v2-setting-acus).
### 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 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
}
]
]
```
## Vérifier la version de la plateforme pour un Aurora serverless cluster existant
### Console
La version de la plateforme est affichée dans la section Configuration de l'instance.
### AWS CLI
Vous pouvez utiliser la `describe-db-clusters` commande pour vérifier la version de la plate-forme pour les clusters existants.
**Example**
```
1. aws rds describe-db-clusters \
2. --db-cluster-identifier {{mydbcluster}}
```
### Vérifier la version par défaut de la plateforme
#### AWS CLI
Vous pouvez utiliser la `describe-serverless-v2-platform-versions` commande pour vérifier les détails d'une version de plate-forme ou pour vérifier la version de plate-forme par défaut que vous obtiendrez lorsque vous créerez un nouveau cluster.
**Example**
```
1. $ aws rds describe-serverless-v2-platform-versions
2. {
3. "ServerlessV2PlatformVersions": [
4. {
5. "Engine": "aurora-postgresql",
6. "ServerlessV2PlatformVersion": "3",
7. "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2"
8. "ServerlessV2FeatureSupport": {
9. "MinCapacity": 0
10. "MaxCapacity": 256
11. },
12. "Status": "available",
13. "IsDefault": True
14. },
15. ...
16. ]
17. }
18.
19. # describing the default platform version for an engine
20. $ aws rds describe-serverless-v2-platform-versions --engine aurora-postgresql --default-only
21. {
22. "ServerlessV2PlatformVersions": [
23. {
24. "Engine": "aurora-postgresql",
25. "ServerlessV2PlatformVersion": "3",
26. "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2"
27. "ServerlessV2FeatureSupport": {
28. "MinCapacity": 0
29. "MaxCapacity": 256
30. },
31. "Status": "available",
32. "IsDefault": True
33. }
34. ]
35. }
```
### Vérification des mises à niveau des versions de plate-forme en attente
Vous pouvez utiliser la `describe-pending-maintenance-actions` commande pour vérifier s'il existe des mises à niveau de version de plate-forme en attente pour vos clusters de Aurora serverless base de données.
Pour vérifier les mises à niveau en attente sur un cluster spécifique, utilisez le `--resource-identifier` paramètre pour spécifier le nom de ressource Amazon (ARN) de votre cluster de base de données :
**Example**
```
1. aws rds describe-pending-maintenance-actions \
2. --resource-identifier arn:aws:rds:{{us-east-1}}:{{123456789012}}
3. :cluster:{{my-serverless-cluster}}
```
#### Planification d'une mise à niveau de version de plateforme
Après avoir identifié une mise à niveau de version de plate-forme en attente, vous pouvez utiliser la `apply-pending-maintenance-action` commande pour planifier le moment où la mise à niveau aura lieu.
Pour planifier une mise à niveau de version de plate-forme, spécifiez les paramètres suivants :
+ `--resource-identifier`— L'ARN de votre Aurora serverless cluster de base de données
+ `--apply-action`— `serverless-platform-version-update` À utiliser pour spécifier une mise à niveau de version de plate-forme
+ `--opt-in-type`— Choisissez quand appliquer la mise à niveau :
+ `immediate`— Appliquez la mise à niveau immédiatement
+ `next-maintenance`— Appliquez la mise à niveau lors de votre prochain calendrier
## Ajout d’un lecteur Aurora serverless
Pour ajouter une instance de base de données de lecteur Aurora serverless à 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](aurora-replicas-adding.md). 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 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 que vous ajoutez au cluster. Chaque instance de base de données Aurora serverless peut être mise à l’échelle entre les valeurs minimale et maximale d’ACU.
Si d’autres instances Aurora serverless 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 au cluster, l’ajout d’une autre instance de base de données de lecteur Aurora serverless 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 d’un cluster](#aurora-serverless-v2-setting-acus).
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 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](#aurora-serverless-v2-choosing-promotion-tier).
Pour savoir comment afficher la plage de capacité actuelle d’un cluster, consultez [Vérification de la plage de capacité pour Aurora serverless](#aurora-serverless-v2-checking-capacity).
## Conversion d’un lecteur ou d’un enregistreur approvisionné en Aurora serverless
Vous pouvez convertir une instance de base de données approvisionnée de sorte qu’elle utilise Aurora serverless. 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](Aurora.Modifying.md#Aurora.Modifying.Instance). Le cluster doit satisfaire aux [Exigences et limites relatives à Aurora serverless](aurora-serverless-v2.requirements.md). Par exemple, les instances de base de données Aurora serverless 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. Dans ce cas, vous pouvez réduire la durée d’indisponibilité en convertissant une instance de base de données en Aurora serverless dans le cadre de la première étape du processus de bascule. Pour obtenir la procédure complète, consultez [Conversion d’un lecteur ou d’un enregistreur approvisionné en Aurora serverless](#aurora-serverless-v2-converting-from-provisioned).
Si l’instance de base de données que vous convertissez est la première instance de base de données Aurora serverless 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 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](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
Si le cluster contient déjà une ou plusieurs instances de base de données Aurora serverless, 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, suivez la procédure de la rubrique [Définition de la plage de capacité Aurora serverless d’un cluster](#aurora-serverless-v2-setting-acus).
## Conversion d’un lecteur ou d’un enregistreur Aurora serverless en mode approvisionné
Vous pouvez convertir une instance de base de données Aurora serverless 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](Aurora.Modifying.md#Aurora.Modifying.Instance). 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 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. 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 peut être mise à l’échelle.
**Astuce**
Certaines des anciennes classes d’instance de base de données telles que db.r3 et db.t2 ne sont pas disponibles pour les versions d’Aurora que vous utilisez avec Aurora serverless. Pour savoir quelles classes d’instance de base de données vous pouvez utiliser lors de la conversion d’une instance de base de données Aurora serverless en mode approvisionné, consultez [Moteurs de base de données pris en charge pour les classes d’instance de base de données](Concepts.DBInstanceClass.SupportAurora.md).
Si vous convertissez l’instance de base de données d’enregistreur de votre cluster d’Aurora serverless en mode approvisionné, vous pouvez suivre la procédure de la rubrique [Conversion d’un lecteur ou d’un enregistreur approvisionné en Aurora serverless](#aurora-serverless-v2-converting-from-provisioned), mais en sens inverse. Basculez l’une des instances de base de données de lecteur du cluster d’Aurora serverless 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 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 d’un cluster](#aurora-serverless-v2-setting-acus).
## Mise en pause des instances de base de données Aurora serverless
Vous pouvez configurer les clusters Aurora pour mettre en pause et reprendre automatiquement leurs instances de base de données Aurora serverless. Pour plus d’informations, consultez [Réduction verticale à zéro ACU avec pause et reprise automatiques pour Aurora serverless](aurora-serverless-v2-auto-pause.md).
## Choix du niveau de promotion pour un lecteur Aurora serverless
Pour les clusters contenant plusieurs instances de base de données Aurora serverless ou un mélange d’instances de base de données approvisionnées et Aurora serverless, prêtez attention au paramètre de niveau de promotion pour chaque instance de base de données Aurora serverless. Ce paramètre contrôle davantage le comportement des instances de base de données Aurora serverless que celui des instances de base de données approvisionnées.
Dans le AWS Management Console, vous spécifiez ce paramètre à l'aide du choix de **priorité de basculement** sous **Configuration supplémentaire** pour les pages **Créer une base de données**, **Modifier une instance** et **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, 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 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 équivalente. Il utilise cette estimation comme capacité minimale pour l’instance de base de données de lecteur Aurora serverless.
Les instances de base de données de lecteur Aurora serverless 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' AWS CLI exemple Linux suivant 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' AWS CLI exemple Linux suivant montre comment modifier le niveau de promotion d'une instance de base de données spécifique dans 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](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.scaling).
## Utilisation TLS/SSL avec Aurora serverless
Aurora serverlesspeut utiliser le protocole Transport Security/Secure Layer Sockets Layer (TLS/SSL) pour chiffrer les communications entre les clients et vos Aurora serverless instances de base de données. Il prend en charge TLS/SSL les versions 1.0, 1.1 et 1.2. Pour obtenir des informations générales sur l'utilisation TLS/SSL d'Aurora, consultez[Connexions TLS aux clusters de bases de données Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html).
Aurora serverlessprend en charge tous les TLS/SSL modes disponibles pour le client MySQL (`mysql`) et le client PostgreSQL `psql` (), y compris ceux répertoriés dans le tableau suivant.
| Description du TLS/SSL mode | mysql | psql |
| --- | --- | --- |
| Connect sans utiliser TLS/SSL. | DISABLED | désactiver |
| Essayez d' TLS/SSL abord la connexion, mais revenez à une connexion non SSL si nécessaire. | PREFERRED | prefer (par défaut) |
| Faites appliquer l'utilisation TLS/SSL. | REQUIRED | require |
| Appliquez TLS/SSL et vérifiez l'autorité de certification (CA). | VERIFY\_CA | verify-ca |
| Appliquez TLS/SSL, vérifiez l'autorité de certification et vérifiez le nom d'hôte de l'autorité de certification. | VERIFY\_IDENTITY | verify-full |
Aurora serverless 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 le nom d'hôte de l'autorité de certification » lors de l'utilisation TLS/SSL, téléchargez d'abord le [magasin racine Amazon CA 1 Trust](https://www.amazontrust.com/repository/AmazonRootCA1.pem) depuis Amazon Trust Services. Ensuite, vous pouvez identifier ce PEM-formatted fichier 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html).
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](Aurora.Connecting.md).
### Suites de chiffrement prises en charge pour les connexions aux clusters de bases de données Aurora serverless
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 sécuriser les TLS/SSL connexions 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 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](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.ConfiguringCipherSuites).
Les clusters de bases de données Aurora serverless 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](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL.ConfiguringCipherSuites).
## Affichage d’enregistreurs et de lecteurs Aurora serverless
Vous pouvez afficher les détails des instances de base de données Aurora serverless 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](accessing-monitoring.md#Aurora.Viewing). Un cluster peut contenir toutes les instances de base de données Aurora serverless, 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, 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 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 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 dans le cluster, consultez [Vérification de la plage de capacité pour Aurora serverless](#aurora-serverless-v2-checking-capacity).
Dans le AWS Management Console, les Aurora serverless instances de base de données sont marquées sous la colonne **Taille** de la page **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 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 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 voir ces détails dans le AWS Management Console, examinez les graphiques des CloudWatch métriques Amazon dans l'onglet **Monitoring de** l'instance de base de données. Pour plus d’informations sur les métriques à surveiller et comment les interpréter, consultez [Statistiques Amazon CloudWatch importantes pour Aurora serverless](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).
## Journalisation pour Aurora serverless
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.
| 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 réglé sur une rangée 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 de bases de données Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
Pour Aurora PostgreSQL, vous pouvez activer les journaux suivants sur vos instances de base de données Aurora serverless.
| Aurora PostgreSQL | Description |
| --- | --- |
| `log_connections` | Enregistre toutes les connexions réussies. |
| `log_disconnections` | Journalise la fin d’une session, y compris sa durée. |
| `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`. |
**Topics**
+ [Se connecter avec Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging)
+ [Afficher Aurora serverless les journaux sur Amazon CloudWatch](#aurora-serverless-v2.logging.monitoring)
+ [Surveillance de la capacité avec Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging.monitoring)
+ [Surveillance de l’activité de mise en pause et de reprise d’Aurora serverless](#autopause-logging-instance-log)
### Se connecter avec Amazon CloudWatch
Après avoir suivi la procédure décrite [Journalisation pour Aurora serverless](#aurora-serverless-v2.logging) pour choisir les journaux de base de données à activer, vous pouvez choisir les journaux à télécharger (« publier ») sur Amazon CloudWatch.
Vous pouvez utiliser Amazon CloudWatch pour analyser les données des journaux, créer des alarmes et consulter les métriques. Par défaut, les journaux d'erreurs pour Aurora serverless sont activés et automatiquement téléchargés vers CloudWatch. Vous pouvez également télécharger d'autres journaux depuis des Aurora serverless instances de base de données vers CloudWatch.
Vous choisissez ensuite dans lequel de ces journaux vous souhaitez les télécharger CloudWatch, en utilisant les paramètres d'**exportation des journaux** dans le AWS Management Console ou l'`--enable-cloudwatch-logs-exports`option dans le AWS CLI.
Vous pouvez choisir dans lequel de vos Aurora serverless journaux vous souhaitez les télécharger CloudWatch. Pour de plus amples informations, veuillez consulter [Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
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 et ce, de sorte qu’il soit disponible lorsque vous créez une base de données sur la console.
**Note**
Pour Aurora serverless, vous pouvez créer un cluster de bases de données et des groupes de paramètres de base de données.
### Afficher Aurora serverless les journaux sur Amazon CloudWatch
Après avoir utilisé la procédure de la rubrique [Se connecter avec Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging) pour choisir les journaux de base de données à activer, vous pouvez afficher le contenu des journaux.
Pour plus d'informations sur l'utilisation CloudWatch des journaux Aurora MySQL et Aurora PostgreSQL, consultez et. [Surveillance des événements du journal sur Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor) [Publication des journaux Aurora PostgreSQL sur Amazon Logs CloudWatch](AuroraPostgreSQL.CloudWatch.md)
**Pour afficher les journaux de votre cluster de bases de données Aurora serverless**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Choisissez votre Région AWS.
1. Choisissez **Groupes de journaux**.
1. Choisissez votre journal de cluster de bases de données Aurora serverless dans la liste. Le modèle de nommage des journaux est le suivant.
```
/aws/rds/cluster/{{cluster-name}}/{{log_type}}
```
**Note**
Pour les clusters de bases de données Aurora Aurora serverless compatibles MySQL, le journal des erreurs inclut les événements de mise à l’échelle du groupe de mémoires tampons même en l’absence d’erreurs.
### Surveillance de la capacité avec Amazon CloudWatch
AvecAurora serverless, vous pouvez l'utiliser CloudWatch pour surveiller la capacité et l'utilisation de toutes les instances de Aurora serverless base de données 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 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, consultez [Statistiques Amazon CloudWatch importantes pour Aurora serverless](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).
**Pour surveiller la capacité de votre cluster de bases de données Aurora serverless**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Choisissez **Métriques**. Dans la console, toutes les métriques disponibles apparaissent sous forme de cartes regroupées par nom de service.
1. Choisissez **RDS**.
1. (Facultatif) Utilisez la zone **Search** (Recherche) pour trouver les métriques qui sont particulièrement importantes pour Aurora serverless : `ServerlessDatabaseCapacity`, `ACUUtilization`, `CPUUtilization` et `FreeableMemory`.
Nous vous recommandons de configurer un CloudWatch tableau de bord pour surveiller la capacité de votre Aurora serverless cluster de bases de données à l'aide des métriques liées à la capacité. Pour savoir comment procéder, consultez la section [Création de tableaux de bord avec CloudWatch](https://docs.aws.amazon.com/autoscaling/application/userguide/monitoring-cloudwatch.html).
Pour en savoir plus sur l'utilisation d'Amazon CloudWatch avec Amazon Aurora, consultez[Publication de journaux Amazon Aurora MySQL sur Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md).
### Surveillance de l’activité de mise en pause et de reprise d’Aurora serverless
Aurora écrit un fichier journal distinct pour les instances de base de données Aurora serverless 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 pour lesquelles la pause automatique est activée. Vous pouvez consulter le contenu de ce journal dans le AWS Management Console ou en utilisant l'API AWS CLI ou RDSP. Actuellement, vous ne pouvez pas télécharger ce journal sur CloudWatch.
Les événements répertoriés dans [Événements d’instance de base de données](USER_Events.Messages.md#USER_Events.Messages.instance) fournissent une vue d’ensemble globale des activités de pause et de reprise, tels que les suivants :
+ Quand l’instance commence à se mettre en pause et quand elle finit de le faire.
+ Quand l’instance commence à reprendre et quand elle finit de reprendre.
+ Cas où l’instance a tenté de se mettre en pause, mais certaines conditions l’en ont empêchée.
`instance.log` fournit des informations plus détaillées sur les raisons pour lesquelles une instance Aurora serverless a pu être mise en pause ou non.
Le journal peut indiquer qu’une instance a repris pour différentes raisons :
+ **activité utilisateur** : demande de connexion à une base de données. Cela peut provenir d’une session client interactive, d’un appel d’API RDS Data ou d’une demande de téléchargement de journaux à partir de l’instance.
+ **activité en arrière-plan** : catégorie générale qui inclut toutes les raisons pour lesquelles Aurora reprend une instance. Par exemple, lorsqu’une demande de connexion à une instance de lecteur entraîne la reprise de l’instance d’enregistreur, le journal du lecteur indique l’activité de l’utilisateur, tandis que le journal de l’enregistreur classe cette demande de reprise comme activité en arrière-plan. Pour connaître les raisons pour lesquelles Aurora peut reprendre une instance autre qu’une demande de connexion utilisateur, consultez [Reprise d’une instance Aurora serverless mise en pause automatique](aurora-serverless-v2-auto-pause.md#auto-pause-waking).
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 peut dépasser le délai d’expiration de la pause automatique, sans toutefois pouvoir se mettre en pause :
+ **activité de base de données avant l’expiration du délai de pause automatique** : l’instance de base de données a reçu une demande de connexion avant l’expiration du délai d’expiration.
+ **membre de la base de données globale** : si le cluster de bases de données fait partie d’une base de données globale Aurora, les instances Aurora serverless de ce cluster ne sont pas mises en pause. Un cluster peut passer d’un cluster autonome à un cluster de bases de données global. Ainsi, des instances précédemment mises en pause automatique peuvent arrêter de le faire et indiquer cette raison dans le journal. Une fois qu’un cluster devient membre d’une base de données globale, il ne redevient un cluster autonome que lorsque vous le détachez explicitement. Le cluster principal est toujours considéré comme faisant partie de la base de données globale même si vous détachez tous les clusters secondaires.
+ **capacité de réplication configurée** : la réplication spécifique au moteur est activée sur l’instance de base de données de l’enregistreur, qu’il s’agisse de la réplication du journal binaire pour MySQL ou de la réplication logique pour PostgreSQL. Cette condition peut également être due à l’utilisation d’une autre fonctionnalité Aurora nécessitant l’activation de la réplication, telle que les intégrations zéro ETL ou Database Activity Streams (DAS).
+ **délai de sauvegarde continu** : si le système de stockage Aurora n’a pas fini d’appliquer les modifications de stockage jusqu’à la date actuelle, l’instance de l’enregistreur ne s’arrête pas tant qu’elle n’a pas rattrapé son retard. Cette condition n’affecte que l’instance de l’enregistreur et devrait être relativement brève.
+ **action de maintenance du service ou du client** : si une opération de maintenance démarre, l’instance de base de données ne se mettra pas en pause à nouveau tant que cette opération ne sera pas terminée. Cette condition inclut une grande variété d’opérations qui peuvent être lancées par vous ou par Aurora, telles que les mises à jour, le clonage, la modification des paramètres de configuration, les mises à niveau, le téléchargement de fichiers journaux, etc. Cet événement se produit également lorsque vous demandez la suppression d’une instance et qu’Aurora reprend brièvement l’instance dans le cadre du mécanisme de suppression.
+ **problème de communication transitoire** : si Aurora ne parvient pas à déterminer si le paramètre de capacité minimale correspond à 0 ACU dans la configuration de la mise à l’échelle, il ne met pas l’instance en pause. Ce type de scénario est sensé être très rare.