Gestion Aurora Serverless v2 Clusters de bases de données

Avec Aurora Serverless v2, vos clusters sont interchangeables avec les clusters provisionnés. Le Aurora Serverless v2 les propriétés s'appliquent à une ou plusieurs instances de base de données au sein d'un cluster de base 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 Aurora Serverless v2 Instances de base de données.

Réglage du Aurora Serverless v2 plage de capacité pour un cluster

Pour modifier les paramètres de configuration ou d'autres paramètres pour les clusters contenant Aurora Serverless v2 Les instances de base de données, ou les instances de base de données elles-mêmes, suivent les mêmes procédures générales que pour les clusters provisionnés. Pour plus de détails, 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 minimales et maximales des unités de capacité Aurora (ACU) pour un cluster Aurora, vous n'avez pas besoin d'ajuster activement la capacité du Aurora Serverless v2 Instances de base de données dans le cluster. Aurora le fait pour vous. Ce paramètre est géré au niveau du cluster. Les mêmes ACU valeurs minimales et maximales s'appliquent à chaque Aurora Serverless v2 Instance de base de données dans le cluster.

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

• Minimum ACUs — Le Aurora Serverless v2 L'instance de base de données peut réduire la capacité jusqu'à ce nombre deACUs.

• Maximum ACUs — Le Aurora Serverless v2 L'instance de base de données peut augmenter la capacité jusqu'à ce nombre deACUs.

Les nouvelles versions du moteur de base de données autorisent une capacité maximale de 256ACUs. Pour les plages de capacité des différentes versions du moteur de base de données, voirAurora Serverless v2 capacity.

Pour plus d'informations sur la manière de vous assurer que votre Aurora Serverless v2 Les clusters de base de données peuvent être étendus jusqu'à 256ACUs, voirMise à niveau de votre Aurora Serverless v2 Cluster de base de données pour permettre le dimensionnement jusqu'à 256 ACUs.

Note

Lorsque vous modifiez la plage de capacité d'un Aurora Serverless v2 Cluster de bases de données, la modification a lieu immédiatement, que vous choisissiez de l'appliquer immédiatement ou lors de la prochaine fenêtre de maintenance planifiée.

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 évolutivité 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, sur la base de votre surveillance, que la ACU plage du cluster doit être supérieure, inférieure, large ou étroite. Vous pouvez définir la capacité d'un cluster Aurora sur une plage spécifique ACUs de AWS Management Console, de AWS CLI, ou d'Amazon RDSAPI. Cette plage de capacité s'applique à tous Aurora Serverless v2 Instance de base de données 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 à 20,5ACUs, le cluster en consomme désormais 16 ACUs lorsqu'il est inactif et jusqu'à 41 ACUs lorsqu'il est pleinement utilisé.

Aurora définit automatiquement certains paramètres pour Aurora Serverless v2 Instances de base de données dont les valeurs dépendent de la ACU valeur maximale dans la plage de capacité. Pour obtenir la liste de ces paramètres, consultez Nombre maximum 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 Aurora Serverless v2 Instances de base de données avec AWS Management Console.

Lorsque vous utilisez la console, vous définissez la plage de capacité du cluster au moment où vous ajoutez le premier Aurora Serverless v2 instance de base de données de 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 sans serveur lorsque vous ajoutez un Aurora Serverless v2 instance de base de données du lecteur vers le 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'écritureAjouter un Aurora Serverless v2 lecteur, etConversion d'un rédacteur ou d'un lecteur provisionné en Aurora Serverless v2.

Quelle que soit la plage de capacité que vous définissez au niveau du cluster, elle s'applique à tous Aurora Serverless v2 Instances de base de données de votre cluster. L'image suivante montre un cluster avec plusieurs Aurora Serverless v2 instances de base de données de lecteur. Chacune a une plage de capacité identique de 2 à 64ACUs.

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

1. Ouvrez la RDS console Amazon à 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 votre Aurora Serverless v2 Instances de base de données figurant dans la liste. Le cluster doit déjà contenir au moins un Aurora Serverless v2 Instance de base de données. 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,5 et 256ACUs. Vous pouvez choisir une capacité maximale comprise entre 1 et 256ACUs. Vous pouvez ajuster les valeurs de capacité par incréments de 0,5ACU.

   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 Aurora Serverless v2 Les instances de base de données utilisant la commande AWS CLI, exécutez la modify-db-cluster AWS CLI commande. Spécifiez l'option --serverless-v2-scaling-configuration. Le cluster contient peut-être déjà un ou plusieurs Aurora Serverless v2 Instances de base de données, ou vous pouvez ajouter les instances de base de données ultérieurement. Les valeurs valides pour les champs MinCapacity et MaxCapacity sont les suivantes :

• 0.5,1,1.5,2, et ainsi de suite, par étapes de 0,5, jusqu'à un maximum de 256.

Dans cet exemple, vous définissez la ACU plage d'un cluster de base de données Aurora nommé sample-cluster sur un minimum de 64 48.5 et un maximum 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é.

Après cela, vous pouvez ajouter Aurora Serverless v2 Les instances de base de données du cluster et de chaque nouvelle instance de base de données peuvent évoluer entre 48,5 et 64ACUs. La nouvelle gamme de capacités s'applique également à tous Aurora Serverless v2 Instances de base de données déjà présentes 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 d'autres exemples de définition de la plage de capacité à l'aide duCLI, voirChoisir le Aurora Serverless v2 plage de capacité pour un cluster Aurora.

Pour modifier la configuration de mise à l'échelle 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 My SQL :0.5,1,1.5,2, etc., par incréments de 0,5 ACUs jusqu'à un maximum de256.

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

Dans l'exemple suivant, vous modifiez la configuration de mise à l'échelle d'un Aurora Serverless v2 Instance de base de données nommée sample-instance qui fait partie d'un cluster nommésample-cluster.

Dans Linux, macOS, 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

RDS API

Vous pouvez définir la capacité d'une instance de base de données Aurora à l'aide de l'odifyDBClusterAPIopération M. Spécifiez le paramètre ServerlessV2ScalingConfiguration. Les valeurs valides pour les champs MinCapacity et MaxCapacity sont les suivantes :

• 0.5,1,1.5,2, et ainsi de suite, par étapes de 0,5, jusqu'à un maximum de 256.

Vous pouvez modifier la configuration de dimensionnement d'un cluster contenant Aurora Serverless v2 Instances de base de données avec odifyDBCluster API l'opération M. 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 My SQL :0.5,1,1.5,2, etc., par incréments de 0,5 ACUs jusqu'à un maximum de256.

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

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 jusqu'à 256 ACUs

Dans certains cas, lorsque vous essayez de redimensionner votre Aurora Serverless v2 Cluster de base de données dont les capacités sont supérieures à 128ACUs, vous recevez un message d'erreur. Le message d'erreur vous indique quelles instances sont incompatibles avec la nouvelle plage de mise à l'échelle.

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 256ACUs. Pour de plus amples informations, veuillez consulter Aurora Serverless v2 capacity.

• Ancienne plateforme — Améliorez la plateforme sous-jacente pour votre Aurora Serverless v2 Cluster de bases 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. Cela mettra fin à la plate-forme sous-jacente existante et en fournira une nouvelle capable de 256 bitsACUs.

    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.

  • Remplacez les anciennes instances et basculez vers l'une des nouvelles instances.

    1. Ajoutez des instances de base de données de lecteur. Les nouvelles instances de lecteur fonctionneront sur du matériel mis à jour capable de 256ACUs. Pour de plus amples informations, veuillez consulter Ajouter un Aurora Serverless v2 lecteur.

    2. Basculez vers l'une des nouvelles instances de lecteur. Pour de plus amples informations, veuillez consulter Défaillance d'un cluster de base de données Amazon Aurora.

    3. Après le basculement, vous pouvez supprimer les anciennes instances, y compris l'ancienne instance Writer.

  • Utilisez un déploiement bleu/vert. Pour de plus amples informations, veuillez consulter Présentation des déploiements Amazon RDS Blue/Green pour Aurora.

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

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

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

    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 les déploiements bleu/vert.

    La base de données globale Aurora ne prend pas en charge les déploiements bleu/vert.

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

La procédure pour vérifier la plage de capacité de votre Aurora Serverless v2 le cluster nécessite que vous définissiez d'abord une plage de capacités. Si vous ne l'avez pas fait, suivez la procédure de la rubrique Réglage du Aurora Serverless v2 plage de capacité pour un cluster.

Quelle que soit la plage de capacité que vous définissez au niveau du cluster, elle s'applique à tous Aurora Serverless v2 Instances de base de données de votre cluster. L'image suivante montre un cluster avec plusieurs Aurora Serverless v2 Instances de base de données. Chacune possède une plage de capacité identique.

Vous pouvez également consulter la page de détails de n'importe quel Aurora Serverless v2 Instance de base de données dans le 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. L'image suivante vous montre comment le faire. À 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 Réglage du Aurora Serverless v2 plage de capacité pour 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 Aurora Serverless v2 Instances de base de données dans un cluster en examinant l'ServerlessV2ScalingConfigurationattribut 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 16ACUs.

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

Ajouter un Aurora Serverless v2 lecteur

Pour ajouter un Aurora Serverless v2 lecteur d'instance de base de données vers votre cluster, vous suivez la même procédure générale que dansAjout 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 du lecteur est la première Aurora Serverless v2 Instance de base de données dans le cluster, vous choisissez également la plage de capacité. L'image suivante montre les commandes que vous utilisez pour spécifier les unités de capacité minimale et maximale d'Aurora (ACUs). Ce paramètre s'applique à cette instance de base de données de lecteur et à toute autre Aurora Serverless v2 Instances de base de données que vous ajoutez au cluster. Chaque Aurora Serverless v2 L'instance de base de données peut évoluer entre les ACU valeurs minimale et maximale.

Si vous en avez déjà ajouté Aurora Serverless v2 Instances de base de données au cluster, ajout d'une autre Aurora Serverless v2 L'instance de base de données Reader vous indique 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 Réglage du Aurora Serverless v2 plage de capacité pour un cluster.

Pour les clusters contenant plusieurs instances de base de données de lecteur, la priorité de basculement de chaque Aurora Serverless v2 L'instance de base de données du lecteur joue un rôle important dans la façon dont cette instance de base de données augmente et diminue. 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 Aurora Serverless v2 lecteur.

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 rédacteur ou d'un lecteur provisionné en Aurora Serverless v2

Vous pouvez convertir une instance de base de données provisionnée pour utiliser Aurora Serverless v2. Pour ce faire, vous devez suivre la procédure décrite dansModification 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, Aurora Serverless v2 Les instances de base de données nécessitent que le cluster exécute certaines versions minimales du moteur.

Supposons que vous convertissiez un cluster provisionné en cours d'exécution pour tirer parti de Aurora Serverless v2. Dans ce cas, vous pouvez minimiser les temps d'arrêt en convertissant une instance de base de données en Aurora Serverless v2 comme première étape du processus de transition. 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 Aurora Serverless v2 Instance de base de données dans le cluster, vous choisissez la plage de capacité du cluster dans le cadre de l'opération de modification. Cette plage de capacité s'applique à chaque Aurora Serverless v2 Instance de base de données 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 Aurora Serverless v2 capacity.

Si le cluster contient déjà un ou plusieurs Aurora Serverless v2 Instances de base de données, vous pouvez voir la plage de capacité existante lors de l'opération de modification. L'image suivante illustre un exemple de ce panneau d'informations.

Si vous souhaitez modifier la plage de capacité du cluster après en avoir ajouté d'autres Aurora Serverless v2 Instances de base de données, suivez la procédure décrite dansRéglage du Aurora Serverless v2 plage de capacité pour un cluster.

Conversion d'un Aurora Serverless v2 écrivain ou lecteur à approvisionner

Vous pouvez convertir un Aurora Serverless v2 Instance de base de données vers une instance de base de données provisionné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 un Aurora Serverless v2 L'instance de base de données doit être provisionnée si elle a besoin d'une capacité supérieure à celle disponible avec les unités de capacité Aurora maximales (ACUs) d'un Aurora Serverless v2 Instance de base de données. Par exemple, les plus grandes classes d'instance de base de données db.r5 et db.r6g ont une capacité de mémoire supérieure à celle d'un Aurora Serverless v2 L'instance de base de données peut évoluer jusqu'à.

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 voir quelles classes d'instance de base de données vous pouvez utiliser lors de la conversion d'un Aurora Serverless v2 Instance de base de données vers une instance provisionnée, voirMoteurs 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 Writer de votre cluster à partir de Aurora Serverless v2 pour provisionner, vous pouvez suivre la procédure en Passage d'un cluster provisionné à Aurora Serverless v2 sens inverse. Basculez l'une des instances de base de données du lecteur du cluster depuis Aurora Serverless v2 à provisionné. 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 Aurora Serverless v2 Les instances de base de données sont supprimées du cluster. Si vous souhaitez modifier la plage de capacité, vous pouvez modifier le cluster, comme expliqué à la rubrique Réglage du Aurora Serverless v2 plage de capacité pour un cluster.

Choix du niveau de promotion pour un Aurora Serverless v2 lecteur

Pour les clusters contenant plusieurs Aurora Serverless v2 Instances de base de données ou une combinaison d'instances provisionnées et Aurora Serverless v2 Instances de base de données, faites attention au paramètre du niveau de promotion pour chacune Aurora Serverless v2 Instance de base de données. Ce paramètre contrôle davantage le comportement de Aurora Serverless v2 Instances de base de données plutôt que pour les instances de base de données provisionné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. Dans Aurora Serverless v2 instances de base de données de lecture, le numéro de niveau détermine également si l'instance de base de données augmente pour correspondre à la capacité de l'instance de base de données d'écriture ou si elle évolue indépendamment en fonction de sa propre charge de travail. Aurora Serverless v2 les instances de base de données de lecteur de niveau 0 ou 1 sont maintenues à une capacité minimale au moins aussi élevée que celle de l'instance de base de données d'écriture. 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 du rédacteur est une instance de base de données provisionnée, Aurora estime l'équivalent Aurora Serverless v2 capacité. Il utilise cette estimation comme capacité minimale pour Aurora Serverless v2 instance de base de données du lecteur.

Aurora Serverless v2 les instances de base de données de lecture des niveaux 2 à 15 ne sont pas soumises à la même contrainte quant à leur capacité minimale. Lorsqu'ils sont inactifs, ils peuvent être réduits à la valeur minimale de l'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 Aurora Serverless v2 mise à l'échelle.

TLSSSLUtiliser/avec Aurora Serverless v2

Aurora Serverless v2 peut utiliser le protocole Transport Layer Security/Secure Sockets Layer (TLS/SSL) pour chiffrer les communications entre les clients et votre Aurora Serverless v2 Instances de base de données. Il prend TLS en charge SSL les versions 1.0, 1.1 et 1.2. Pour obtenir des informations générales sur l'utilisation deTLS/SSLavec Aurora, consultezTLSconnexions aux clusters Aurora My SQL DB.

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

Aurora Serverless v2 prend en charge tous les SSL modesTLS/disponibles pour My SQL client (mysql) et Postgre SQL (psql), y compris ceux répertoriés dans le tableau suivant.

Description du SSL modeTLS/	mysql	psql
Connect sans utiliserTLS/SSL.	DISABLED	désactiver
Essayez d'SSLabord la connexion en utilisantTLS/, mais revenez à non- SSL si nécessaire.	PREFERRED	prefer (par défaut)
Appliquer à l'aide deTLS/SSL.	REQUIRED	require
AppliquezTLS/SSLet vérifiez l'autorité de certification (CA).	VERIFY_CA	verify-ca
AppliquezTLS/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 v2 utilise des certificats 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 » lorsque vous utilisezTLS/SSL, téléchargez d'abord le magasin racine Amazon CA 1 trust depuis Amazon Trust Services. Ensuite, vous pouvez identifier ce fichier PEM formaté dans votre commande client. Pour ce faire, utilisez le SQL client Postgre, procédez comme suit.

Dans 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 SQL base de données Aurora Postgre à l'aide du client Postgres, consultez Connexion à une instance de base de données exécutant le moteur de base de données Postgre SQL.

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 à Aurora Serverless v2 Clusters de bases de données

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 SSL connexions client-client TLS à 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.

Aurora Serverless v2 Les clusters de base de données basés sur Aurora My SQL prennent en charge les mêmes suites de chiffrement que les clusters de base de données SQL provisionnés par Aurora My. Pour plus d'informations sur ces suites de chiffrement, consultez Configuration de suites de chiffrement pour les connexions aux clusters Aurora My SQL DB.

Aurora Serverless v2 Les clusters de base de données basés sur Aurora Postgre SQL prennent en charge les mêmes suites de chiffrement que les clusters de base de données SQL provisionnés par Aurora Postgre. 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 Postgre SQL.

Visualisation Aurora Serverless v2 écrivains et lecteurs

Vous pouvez consulter les détails de Aurora Serverless v2 Instances de base de données de la même manière que pour les instances de base de données provisionné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 tous Aurora Serverless v2 Instances de base de données, toutes les instances de base de données provisionnées ou certaines d'entre elles.

Après avoir créé un ou plusieurs Aurora Serverless v2 Instances de base de données, vous pouvez voir quelles instances de base de données sont de type Serverless et lesquelles sont de type Instance. Vous pouvez également consulter les unités de capacité minimale et maximale d'Aurora (ACUs) que le Aurora Serverless v2 L'instance de base de données peut utiliser. Chacune ACU est une combinaison de capacité de traitement (CPU) et de capacité de mémoire (RAM). Cette plage de capacité s'applique à chaque Aurora Serverless v2 Instance de base de données dans le cluster. Pour la procédure de vérification de la plage de capacité d'un cluster ou de tout autre Aurora Serverless v2 Instance de base de données dans le cluster, voirVérification de la plage de capacité pour Aurora Serverless v2.

Dans le AWS Management Console, Aurora Serverless v2 Les 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. Le Aurora Serverless Les instances de base de données affichent Serverless pour la classe d'instance de base de données, ainsi que la capacité minimale et maximale de l'instance de base de données. Par exemple, vous pouvez voir Serverless v2 (4—64ACUs) ou Serverless v2 (1—40). ACUs

Vous trouverez les mêmes informations dans l'onglet Configuration pour chaque Aurora Serverless v2 Instance de base de données 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 contrôler la capacité de chacun Aurora Serverless v2 Instance de base de données au fil du temps. Ainsi, 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.

Logging 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 My SQL	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 votre Aurora Serverless v2 Instances de base de données.

Poster Aurora SQL	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 SQL instructions spécifiques qui sont enregistré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
• Visualisation Aurora Serverless v2 se connecte à Amazon CloudWatch
• Surveillance de la capacité avec Amazon CloudWatch

Se connecter avec Amazon CloudWatch

Après avoir suivi la procédure décrite Logging 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 Aurora Serverless v2 Instances de base de données pour 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 lequel de vos Aurora Serverless v2 journaux vers lesquels 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 base de données personnalisé avant de créer votre Aurora Serverless v2 Cluster de base de données, afin que vous puissiez choisir lorsque vous créez une base de données sur la console.

Note

Dans Aurora Serverless v2, vous pouvez créer à la fois un cluster de base 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 base de données.

Visualisation Aurora Serverless v2 se connecte à 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 SQL journaux Aurora My SQL et Aurora Postgre, reportez-vous aux sections Surveillance des événements du journal sur Amazon CloudWatch etPublication des journaux Aurora SQL Postgrer sur Amazon CloudWatch Logs.

Pour consulter les journaux de votre Aurora Serverless v2 Cluster DB

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 Aurora Serverless v2 Journal du cluster de base de données depuis la liste. Le modèle de nommage des journaux est le suivant.

   /aws/rds/cluster/cluster-name/log_type

Note

Compatible avec Aurora SQL My Aurora Serverless v2 Clusters de bases de données, le journal des erreurs inclut les événements de dimensionnement du pool de mémoire tampon, même en l'absence d'erreur.

Surveillance de la capacité avec Amazon CloudWatch

Avec Aurora Serverless v2, vous pouvez l'utiliser CloudWatch pour surveiller la capacité et l'utilisation de tous les Aurora Serverless v2 Instances de base de données de votre cluster. Vous pouvez consulter les métriques au niveau de l'instance pour vérifier la capacité de chaque instance Aurora Serverless v2 Instance de base de données à mesure qu'elle augmente ou diminue. 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 mesures liées à la capacité qui s'appliquent à Aurora Serverless v2, voir Statistiques Amazon CloudWatch importantes pour Aurora Serverless v2.

Pour surveiller votre Aurora Serverless v2 Capacité du cluster de base de données

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 le champ de recherche pour trouver les indicateurs particulièrement importants pour Aurora Serverless v2: ServerlessDatabaseCapacityACUUtilization,CPUUtilization, etFreeableMemory.

Nous vous recommandons de configurer un CloudWatch tableau de bord pour surveiller votre Aurora Serverless v2 Capacité du cluster de base 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 de journaux Amazon Aurora MySQL sur Amazon CloudWatch Logs.