Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Exigences et limites relatives à Aurora serverless

Lorsque vous créez un cluster dans lequel vous prévoyez d’utiliser des instances de base de données Aurora serverless, prêtez une attention particulière aux exigences et limites suivantes.

Disponibilité des régions et des versions

La disponibilité et la prise en charge des fonctions varient selon les versions spécifiques de chaque moteur de base de données Aurora, et selon les Régions AWS. Pour en savoir plus sur les versions et la disponibilité des régions avec Aurora et Aurora serverless, consultez Régions et moteurs de base de données Aurora pris en charge pour Aurora sans serveur.

L'exemple suivant montre les AWS CLI commandes permettant de confirmer les valeurs exactes du moteur de base de données que vous pouvez utiliser Aurora serverless pour un domaine spécifique Région AWS. Le paramètre --db-instance-class pour Aurora serverless est toujours db.serverless. Le paramètre --engine peut être aurora-mysql ou aurora-postgresql. Remplacez les valeurs --region et --engine appropriées pour confirmer les valeurs --engine-version que vous pouvez utiliser. Si la commande ne produit aucune sortie, elle Aurora serverless n'est pas disponible pour cette combinaison de moteur Région AWS de base de données.

aws rds describe-orderable-db-instance-options --engine aurora-mysql --db-instance-class db.serverless \
  --region my_region --query 'OrderableDBInstanceOptions[].[EngineVersion]' --output text

aws rds describe-orderable-db-instance-options --engine aurora-postgresql --db-instance-class db.serverless \
  --region my_region --query 'OrderableDBInstanceOptions[].[EngineVersion]' --output text

Les clusters qui utilisent Aurora serverless doivent avoir une plage de capacité spécifiée

Un cluster Aurora doit avoir un attribut ServerlessV2ScalingConfiguration avant de pouvoir ajouter des instances de base de données qui utilisent la classe d’instance de base de données db.serverless. Cet attribut spécifie la plage de capacité La capacité d’Aurora serverless est comprise entre 0 unité de capacité Aurora (ACU) minimum et un maximum de 256 ACU, par incréments de 0,5 ACU. La valeur minimale autorisée dépend de la version d’Aurora. Chaque ACU fournit l’équivalent d’environ 2 gibioctets (Gio) de RAM, ainsi que d’UC et de mise en réseau associées. Pour plus de détails sur la façon dont Aurora serverless utilise les paramètres de plage de capacité, consultez Fonctionnement d’Aurora serverless.

Pour connaître les plages de capacité autorisées pour les différentes versions du moteur de base de données et versions de plateforme, consultez Capacité Aurora serverless. La plage de mise à l’échelle disponible pour un cluster donné dépend à la fois de la version du moteur et du matériel (version de plateforme).

Vous pouvez spécifier les valeurs ACU minimales et maximales AWS Management Console lorsque vous créez un cluster et une Aurora serverless instance de base de données associée. Vous pouvez également spécifier l’option --serverless-v2-scaling-configuration dans AWS CLI. Sinon, vous pouvez spécifier le paramètre ServerlessV2ScalingConfiguration avec l’API Amazon RDS. Vous pouvez spécifier cet attribut lorsque vous créez un cluster ou modifiez un cluster existant. Pour connaître les procédures de définition de la plage de capacité, consultez Définition de la plage de capacité Aurora serverless d’un cluster. Pour obtenir la procédure détaillée de sélection des valeurs de capacité minimale et maximale et pour savoir comment ces paramètres affectent certains paramètres de base de données, consultez Choix de la plage de capacité Aurora serverless pour un cluster Aurora.

Configuration de mise à l'échelle incompatible

Lorsque vous modifiez votre cluster Aurora PostgreSQL avec une capacité maximale inférieure, chaque instance est réduite pour correspondre à la nouvelle configuration. Si Aurora détecte que l'une de vos instances ne parvient pas à réduire sa taille, elle peut annuler et annuler la mise à jour de la configuration de dimensionnement. Par conséquent, les instances reprendront leur configuration précédente. Ce problème peut se produire si la nouvelle capacité maximale est insuffisante pour gérer la charge de travail actuelle ou si les paramètres personnalisés appliqués au groupe de paramètres de base de données du cluster ou des instances sont définis trop haut.

Lorsque le rollback commence, vous serez averti par le biais d'un événement Amazon RDS contenant des informations sur les instances qui n'ont pas pu appliquer la configuration de dimensionnement souhaitée. Une fois la restauration terminée, la capacité maximale de la configuration de dimensionnement reviendra à sa valeur supérieure d'origine. En raison de la rétrogradation, vous constaterez peut-être que la capacité Aurora Serverless de la base de données de toutes les instances de votre cluster peut également augmenter, ce qui entraînera une hausse des coûts.

Par exemple, vous avez un cluster Aurora Aurora Serverless PostgreSQL avec une seule instance et la configuration de dimensionnement est définie minCapacity=0.5 sur, et. maxCapacity=128 secondsUntilAutopause=null En outre, le paramètre de base de données track_activity_query_size est défini sur une valeur personnalisée de 40960. Si vous modifiez ensuite la configuration de dimensionnement du cluster pour qu'il ait une capacité maximale de 1 ACU, vous remarquerez peut-être qu'au bout de quelques heures, la modification n'est pas terminée. La valeur élevée du track_activity_query_size paramètre nécessite plus de ressources que ne peut en fournir la nouvelle capacité maximale. Par conséquent, même en l'absence de charge de travail, l'instance ServerlessDatabaseCapacity ne peut pas être réduite pour correspondre à la nouvelle capacité maximale de 1 ACU. Aurora serverlessannulera alors la modification de la configuration de dimensionnement et réappliquera la configuration de dimensionnement précédente deminCapacity=0.5,maxCapacity=128,secondsUntilAutopause=null. L'instance augmentera ensuite pour correspondre à la configuration de dimensionnement précédente, mettant fin à la modification du cluster. Un événement Amazon RDS est publié pour vous informer qu'une mise à jour de configuration de dimensionnement incompatible a été détectée, annulée et rétablie à la configuration précédente.

Problèmes et mesures correctives

Certaines fonctionnalités approvisionnées ne sont pas prises en charge dans Aurora serverless

Les fonctionnalités suivantes des instances de base de données approvisionnées Aurora ne sont actuellement pas disponibles pour Amazon Aurora serverless :

Certaines fonctionnalités Aurora fonctionnent avec Aurora serverless, mais cela peut poser problème si votre plage de capacité est inférieure à celle nécessaire pour les besoins en mémoire de ces fonctionnalités avec votre charge de travail spécifique. Dans ce cas, votre base de données risque de ne pas fonctionner aussi bien que d’habitude ou de rencontrer des erreurs de mémoire insuffisante. Pour obtenir des recommandations sur la définition de la plage de capacité appropriée, consultez Choix de la plage de capacité Aurora serverless pour un cluster Aurora. Pour obtenir des informations de dépannage si votre base de données rencontre des erreurs de mémoire insuffisante dues à une mauvaise configuration de la plage de capacité, consultez Éviter les erreurs de mémoire insuffisante.

Aurora Auto Scaling n’est pas pris en charge. Ce type de mise à l’échelle ajoute de nouveaux lecteurs pour gérer une charge de travail supplémentaire exigeante en lecture, basée sur l’utilisation du processeur. Toutefois, la mise à l’échelle basée sur l’utilisation du processeur n’est pas significative pour Aurora serverless. En guise d’alternative, vous pouvez créer des instances de base de données de lecteur Aurora serverless à l’avance et conserver leur réduction d’échelle à faible capacité. Il s’agit d’une méthode plus rapide et moins perturbatrice pour mettre à l’échelle la capacité de lecture d’un cluster plutôt que d’ajouter dynamiquement de nouvelles instances de base de données.