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

Avec Aurora Serverless v2, vos clusters sont interchangeables avec les clusters approvisionnés. Les Aurora Serverless v2 propriétés 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 base de données Amazon Aurora.

Dans les rubriques suivantes, vous pouvez en savoir plus sur les considérations relatives à la gestion des clusters contenant des Aurora Serverless v2 instances de base de données.

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 :

• Minimum ACUs — L'Aurora Serverless v2instance de base de données peut réduire sa capacité jusqu'à ce nombre de ACUs.

• Maximum ACUs — L'Aurora Serverless v2instance de base de données peut augmenter sa capacité jusqu'à ce nombre de ACUs.

La plage de capacité disponible pour dépend Aurora Serverless v2 à la fois de la version du moteur de base de données et de la version de la plate-forme. Les nouvelles versions du moteur de base de données autorisent une capacité maximale de 256 ACUs, une capacité minimale de 0 ACUs, ou les deux. Pour les plages de capacité des différentes versions du moteur de base de données, voirCapacité Aurora Serverless v2.

Pour la fonctionnalité de pause et de reprise automatiques activée en définissant la capacité minimale sur 0 ACUs, voirMise à l'échelle jusqu'à zéro ACUs avec pause et reprise automatiques pour Aurora Serverless v2.

Pour plus d'informations sur la manière de garantir que vos clusters de Aurora Serverless v2 base de données peuvent être redimensionnés jusqu'à 256 ACUs, consultezMise à niveau de votre Aurora Serverless v2 cluster de base de données pour permettre le dimensionnement à 256 ACUs.

Note

Lorsque vous modifiez la plage de capacité d'un cluster de bases de données Aurora Serverless v2, la modification intervient immédiatement, que vous choisissiez de l'appliquer immédiatement ou lors du prochain créneau de maintenance planifié.

DansAurora 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. Cependant, vous pouvez influencer la capacité indirectement 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 le dimensionnement : pour fixer la capacité à une valeur spécifique, réglez les capacités minimale et maximale au même niveau.

• Évoluez 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 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 à l' ACUs 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 v2 dans le cluster.

Supposons, par exemple, que votre cluster ait une plage de capacité comprise entre 1 ACUs et 16 et qu'il contienne deux Aurora Serverless v2 instances de base de données. Ensuite, le cluster dans son ensemble consomme entre 2 ACUs (lorsqu'il est inactif) et 32 ACUs (lorsqu'il est pleinement utilisé). Si vous modifiez la plage de capacité de 8 à 40,5 ACUs, l'ensemble du cluster en consomme désormais 16 ACUs lorsqu'il est inactif et jusqu'à 81 ACUs lorsqu'il est pleinement 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.

console

Vous pouvez définir la plage de capacité d'un cluster qui contient des instances de base de données Aurora Serverless v2 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 v2 à ce cluster. Vous pouvez le faire lorsque vous choisissez la classe d'instance de base de données Serverless 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 Serverless (Sans serveur) au moment d'ajouter une instance de base de données de lecteur Aurora Serverless v2 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 Serverless (Sans serveur). Pour les versions complètes de ces procédures, voir Création d'un Aurora Serverless v2 instance de base de données d'écritureAjout d'un lecteur Aurora Serverless v2, etConversion d'un lecteur ou d'un enregistreur approvisionné en Aurora Serverless v2.

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 de lecteur Aurora Serverless v2. Chacune a une plage de capacité identique de 2 à 64 ACUs.

Pour modifier la plage de capacité d'un cluster Aurora Serverless v2

1. Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

2. Dans le panneau de navigation, choisissez Databases (Bases de données).

3. Choisissez le cluster contenant vos instances de base de données Aurora Serverless v2 dans la liste. Le cluster doit déjà contenir au moins une instance de base de données Aurora Serverless v2. Sinon, Aurora n'affiche pas la section Capacity range (Plage de capacité).

4. Pour Actions, choisissez Modify (Modifier).

5. Dans la section Capacity range (Plage de capacité), choisissez les valeurs suivantes :

   1. Entrez une valeur pour Minimum ACUs. La console affiche la plage de valeurs autorisée. Vous pouvez choisir une capacité minimale comprise entre 0 et 256 ACUs. Vous pouvez choisir une capacité maximale comprise entre 1 et 256 ACUs. 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 la plate-forme.

   2. Entrez une valeur pour Maximum ACUs. Cette valeur doit être supérieure ou égale à Minimum ACUs. La console affiche la plage de valeurs autorisée. La figure suivante illustre ce choix.

      

6. Choisissez Continuer. La page Récapitulatif des modifications s'affiche.

7. 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é.

8. 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 v2 instances de base de données à l'aide de AWS CLI, exécutez la modify-db-cluster AWS CLI commande. 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 v2. 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, et ainsi de suite, par étapes de 0,5, jusqu'à un maximum de 256. La valeur ACU minimale de 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 plate-forme.

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é.

Ensuite, vous pouvez ajouter des instances de Aurora Serverless v2 base de données au cluster et chaque nouvelle instance de base de données peut évoluer entre 48,5 et 64 ACUs. La nouvelle plage de capacité s'applique également à toutes les instances de base de données Aurora Serverless v2 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 v2 pour un cluster Aurora.

Pour modifier la configuration de dimensionnement d'un Aurora Serverless cluster de base de données à l'aide de AWS CLI, exécutez la modify-db-cluster AWS CLI commande. 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 : 00.5,1,1.5,2,,, etc., par incréments de 0,5 ACUs jusqu'à un maximum de256.

• Aurora PostgreSQL 0 :0.5,,,,1,1.5, etc.2, par incréments de ACUs 0,5 jusqu'à un maximum de. 256

• La valeur ACU minimale de 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 v2 nommée sample-instance qui fait partie d'un cluster nommé sample-cluster.

Pour LinuxmacOS, ou Unix :

aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64

Dans 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 à l'aide de l'opération Modify DBCluster API. 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, et ainsi de suite, par étapes de 0,5, jusqu'à un maximum de 256. La valeur ACU minimale de 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 dimensionnement d'un Aurora Serverless v2 cluster contenant des instances de base de données à l'aide de l'opération Modify DBCluster API. 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 : 00.5,1,1.5,2,,, etc., par incréments de 0,5 ACUs jusqu'à un maximum de256.

• Aurora PostgreSQL 0 :0.5,,,,1,1.5, etc.2, par incréments de ACUs 0,5 jusqu'à un maximum de. 256

• La valeur ACU minimale de 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 plate-forme.

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 Aurora Serverless v2 cluster de base de données pour permettre le dimensionnement à 256 ACUs

Dans certains cas, lorsque vous essayez de dimensionner votre Aurora Serverless v2 cluster de base de données à des capacités supérieures à 128 ACUs, 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és, la version du moteur de base de données et la version de la plate-forme.

L'impossibilité d'effectuer une mise à l'échelle supérieure à 128 ACUs 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 qui prend en charge 256 ACUs. Pour de plus amples informations, veuillez consulter Capacité Aurora Serverless v2.

• Ancienne version de plate-forme : mettez à niveau la plate-forme pour votre Aurora Serverless v2 cluster de base de données. Vous pouvez effectuer cette opération de différentes manières :

  • Arrêtez et redémarrez le cluster de base de données. Lorsque le cluster redémarrera, il utilisera la dernière version compatible de la plate-forme, qui peut être capable d'un maximum d'ACU plus élevé.

    Cependant, l'arrêt et le démarrage d'un cluster de base de données entraînent des temps d'arrêt, 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.

  • Utilisez un blue/green déploiement. Pour de plus amples informations, veuillez consulter Présentation des (Amazon Aurora Blue/Green ).

    1. Créez un blue/green déploiement. Pour de plus amples informations, veuillez consulter Création d'un déploiement bleu/vert dans Amazon ).

    2. Vérifiez que vous pouvez définir la capacité maximale de l'environnement intermédiaire (vert) sur 256 ACUs.

    3. Passez à l'environnement vert. Pour de plus amples informations, veuillez consulter Passer d'un déploiement bleu/vert dans Amazon ).

    4. Supprimez le cluster de base 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.

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' AWS CLI exemple suivant montre un cluster d'une capacité minimale de 0,5 unité de capacité Aurora (ACUs) et d'une capacité maximale de 16 ACUs.

$ 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 Serverless 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 Aurora Serverless v2 instances existent 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 montre le rapport sur 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 de plus amples informations, veuillez consulter 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 pour 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 les temps d'arrêt en convertissant une instance de base de données en Aurora Serverless v2 dans le cadre de la première étape du processus de basculement. Pour obtenir la procédure complète, consultez Passage d'un cluster provisionné à 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 montre la page dans laquelle vous spécifiez les unités de capacité minimale et maximale d'Aurora (ACUs).

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 Serverless (Sans serveur).

Vous pouvez convertir une Aurora Serverless v2 instance de base de données en instance provisionnée si elle a besoin d'une capacité supérieure à celle disponible avec les unités de capacité Aurora maximales (ACUs) d'une Aurora Serverless v2 instance de base de données. 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.

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 v2. 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 v2 en mode approvisionné, consultez Moteurs de base de données pris en charge pour les classes d'instance de base de données.

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 Passage d'un cluster provisionné à 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.

Suspension des Aurora Serverless v2 instances de base de données

Vous pouvez configurer les clusters Aurora pour suspendre et reprendre automatiquement leurs Aurora Serverless v2 instances de base de données. Pour de plus amples informations, veuillez consulter Mise à l'échelle jusqu'à zéro ACUs 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 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 Priority tier (Niveau de priorité) sur la page Databases (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' 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 v2.

Utilisation TLS/SSL avec Aurora Serverless v2

Aurora Serverless v2peut utiliser le protocole TLS/SSL (Transport Security/Secure Layer Sockets Layer) pour chiffrer les communications entre les clients et vos Aurora Serverless v2 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, consultezConnexions 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 v2prend 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
Se connecte 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)
Imposer à l'aide de TLS/SSL.	REQUIRED	require
Appliquez TLS/SSL et vérifiez l'autorité de certification (CA).	VERIFY_CA	verify-ca
Impose TLS/SSL, vérifie l'autorité de certification et son nom d'hôte.	VERIFY_IDENTITY	verify-full

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 LinuxmacOS, 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 base 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 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 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 base 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 Serverless (Sans serveur) et celles qui sont de type Instance. Vous pouvez également afficher les unités de capacité Aurora minimales et maximales (ACUs) que l'Aurora Serverless v2instance de base de données 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 le AWS Management Console, les Aurora Serverless v2 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 Serverless (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, vous pouvez voir Serverless v2 (4—64 ACUs) ou Serverless v2 (1—40). ACUs

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 du type d'instance est Serverless v2, la valeur de capacité minimale est 2 ACUs (4 GiB) et la valeur de capacité maximale est ACUs 64 (128 GiB).

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 la ACUs consommation minimale, maximale et moyenne 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 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.

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 de plus amples informations, veuillez consulter Utilisation de l'audit avancé avec un cluster Amazon Aurora My SQL DB.

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

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.

Rubriques

• Se connecter avec Amazon CloudWatch

• Afficher Aurora Serverless v2 les journaux sur Amazon CloudWatch

• Surveillance de la capacité avec Amazon CloudWatch

• Surveillance des activités de Aurora Serverless v2 pause et de reprise

Se connecter avec Amazon CloudWatch

Après avoir suivi la procédure décrite Journalisation pour Aurora Serverless v2 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 v2 sont activés et automatiquement téléchargés vers CloudWatch. Vous pouvez également télécharger d'autres journaux depuis des Aurora Serverless v2 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-exportsoption dans le AWS CLI.

Vous pouvez choisir dans lequel de vos Aurora Serverless v2 journaux vous souhaitez les télécharger CloudWatch. Pour de plus amples informations, veuillez consulter Utilisation de l'audit avancé avec un cluster Amazon Aurora My SQL DB.

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.

Note

Pour Aurora Serverless v2, vous pouvez créer un cluster de bases de données et des groupes de paramètres de base de données. Cela contraste avec Aurora Serverless v1, où vous ne pouvez créer que des groupes de paramètres de cluster de bases de données.

Afficher Aurora Serverless v2 les journaux sur Amazon CloudWatch

Après avoir utilisé la procédure de la rubrique Se connecter 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 CloudWatch des journaux Aurora MySQL et Aurora PostgreSQL, consultez et. Surveillance des événements du journal sur Amazon CloudWatch Publication des journaux Aurora PostgreSQL sur Amazon Logs CloudWatch

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

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

2. Choisissez votre Région AWS.

3. Choisissez Groupes de journaux.

4. Choisissez votre journal de cluster de bases de données Aurora Serverless v2 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 v2 compatibles MySQL, le journal des erreurs inclut les événements de mise à l'échelle du pool de mémoire tampon même en l'absence d'erreurs.

Surveillance de la capacité avec Amazon CloudWatch

AvecAurora Serverless v2, vous pouvez l'utiliser CloudWatch pour surveiller la capacité et l'utilisation de toutes les instances de Aurora Serverless v2 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 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 Statistiques Amazon CloudWatch importantes pour Aurora Serverless v2.

Pour surveiller la capacité de votre cluster de bases de données Aurora Serverless v2

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

2. Choisissez Métriques. Dans la console, toutes les métriques disponibles apparaissent sous forme de cartes regroupées par nom de service.

3. Choisissez RDS.

4. (Facultatif) Utilisez la zone Search (Recherche) pour trouver les métriques qui sont particulièrement importantes pour Aurora Serverless v2 : ServerlessDatabaseCapacity, ACUUtilization, CPUUtilization et FreeableMemory.

Nous vous recommandons de configurer un CloudWatch tableau de bord pour surveiller la capacité de votre Aurora Serverless v2 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.

Pour en savoir plus sur l'utilisation d'Amazon CloudWatch avec Amazon Aurora, consultezPublication des journaux Amazon Aurora MySQL sur Amazon CloudWatch Logs.

Surveillance des activités de Aurora Serverless v2 pause et de reprise

Aurora écrit un fichier journal distinct pour les Aurora Serverless v2 instances de base de données 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 suspendue. 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èleinstance.YYYY-MM-DD.N.log.

Ce journal est activé par défaut pour les Aurora Serverless v2 instances de base de données 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 fournissent une vue d'ensemble détaillée 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 faire une pause, mais certaines conditions l'en ont empêchée.

instance.logfournit des informations plus détaillées sur les raisons pour lesquelles une Aurora Serverless v2 instance peut ou non être en mesure de faire une pause.

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 depuis 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 de rédacteur, le journal du lecteur indique l'activité de l'utilisateur, tandis que le journal du rédacteur classe cette demande de reprise comme une activité d'arrière-plan. Pour connaître les raisons pour lesquelles Aurora peut reprendre une instance autre qu'une demande de connexion utilisateur, consultezReprise d'une pause automatique Aurora Serverless v2 instance.

Lorsqu'Aurora n'a connaissance d'aucune condition susceptible d'empêcher l'instance de se suspendre à l'expiration de l'intervalle de pause automatique, elle écrit régulièrement un message d'information 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 rédacteur peut être incapable de faire une 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 le rédacteur, celui-ci peut faire une 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 s'arrêter, le journal contient le message suivant qui répertorie toutes ces conditions :

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

Ainsi, Aurora ne vous empêche pas d'activer la réplication, l'intégration zéro ETL, la base de données globale Aurora, 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 Aurora Serverless v2 instance peut dépasser le délai d'expiration de la pause automatique, mais être empêchée de procéder à une pause :

• activité de la 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 base de données fait partie d'une base de données globale Aurora, les Aurora Serverless v2 instances du cluster ne s'interrompent pas. Un cluster peut passer d'un cluster autonome à un cluster de base de données global. Ainsi, les instances précédemment mises en pause automatique peuvent arrêter de le faire et signaler 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 Writer, qu'il s'agisse de la réplication binlog pour MySQL ou de la réplication logique pour PostgreSQL. Cette condition peut également être due à l'utilisation d'une autre fonctionnalité d'Aurora nécessitant l'activation de la réplication, telle que les intégrations sans ETL ou les flux d'activité de base de données (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 du rédacteur ne s'arrête pas tant qu'elle n'a pas rattrapé son retard. Cette condition n'affecte que l'instance du rédacteur 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 s'interrompra pas à 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 à niveau, 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 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 la configuration de dimensionnement possède actuellement un paramètre de capacité minimale de zéro ACUs, elle ne met pas l'instance en pause. Cela devrait être très rare.