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.

Comment ? Aurora Serverless v2 fonctionnement

L'aperçu suivant décrit comment Aurora Serverless v2 œuvres.

Aurora Serverless v2 vue d'ensemble

Amazon Aurora Serverless v2 convient aux charges de travail hautement variables les plus exigeantes. Par exemple, l'utilisation de votre base de données peut être intensive pendant une courte période, suivie de longues périodes avec une activité légère, voire pas d'activité. On peut citer, par exemple, les sites Web de vente au détail, de jeux ou de sport proposant des événements promotionnels périodiques, ainsi que les bases de données qui produisent des rapports selon les besoins. On peut également citer les environnements de développement et de test, ainsi que les nouvelles applications où l'utilisation peut rapidement augmenter. Dans de tels cas et bien d'autres, la configuration à l'avance d'une capacité adaptée n'est pas toujours possible avec le modèle provisionné. Cela peut également entraîner des coûts plus élevés en cas de sur-approvisionnement et de capacité non utilisée.

En revanche, les clusters approvisionnés Aurora sont adaptés aux charges de travail stables. Avec les clusters approvisionnés, vous choisissez une classe d'instance de base de données qui possède un volume prédéfini de mémoire, de puissance du processeur, de bande passante d'E/S, etc. Si votre charge de travail change, vous modifiez manuellement la classe d'instance de votre enregistreur et de vos lecteurs. Le modèle approvisionné fonctionne bien lorsque vous pouvez ajuster la capacité avant les modèles de consommation attendus et il est acceptable que de brèves pannes se produisent lorsque vous modifiez la classe d'instance de l'enregistreur et des lecteurs de votre cluster.

Aurora Serverless v2 est entièrement conçu pour prendre en charge les clusters de bases de données sans serveur qui sont instantanément évolutifs. Aurora Serverless v2 est conçu pour fournir le même degré de sécurité et d'isolation qu'avec les graveurs et lecteurs fournis. Ces aspects sont essentiels dans les environnements cloud multilocataires sans serveur. Le mécanisme de mise à l'échelle dynamique n'engendre que très peu de frais généraux, ce qui lui permet de réagir rapidement aux modifications de la charge de travail de la base de données. En outre, elle est suffisamment puissante pour répondre à d'importantes augmentations en termes de demande de traitement.

En utilisant Aurora Serverless v2, vous pouvez créer un cluster de base de données Aurora sans être limité à une capacité de base de données spécifique pour chaque rédacteur et lecteur. Vous spécifiez la plage de capacité minimale et maximale. Aurora escalade chacune d'elles Aurora Serverless v2 enregistreur ou lecteur du cluster dans cette plage de capacité. En utilisant un cluster multi-AZ où chaque enregistreur ou lecteur peut faire l'objet d'une mise à l'échelle dynamique, vous pouvez tirer parti de la mise à l'échelle dynamique et de la haute disponibilité.

Aurora Serverless v2 redimensionne automatiquement les ressources de la base de données en fonction de vos spécifications de capacité minimale et maximale. La mise à l'échelle est rapide car la plupart des opérations sur les événements de mise à l'échelle maintiennent l'enregistreur ou le lecteur sur le même hôte. Dans les rares cas où un Aurora Serverless v2 l'écrivain ou le lecteur est déplacé d'un hôte à un autre, Aurora Serverless v2 gère automatiquement les connexions. Vous n'avez pas besoin de modifier le code d'application cliente de votre base de données ou les chaînes de connexion à la base de données.

Avec Aurora Serverless v2, comme pour les clusters provisionnés, la capacité de stockage et la capacité de calcul sont distinctes. Lorsque nous nous référons à Aurora Serverless v2 capacité et évolutivité, c'est toujours la capacité de calcul qui augmente ou diminue. Ainsi, votre cluster peut contenir un grand nombre de téraoctets de données, même lorsque la capacité du processeur et de la mémoire fait l'objet d'une réduction d'échelle à de faibles niveaux.

Au lieu d'approvisionner et de gérer les serveurs de base de données, vous spécifiez la capacité de base de données. Pour plus de détails sur Aurora Serverless v2 capacité, voirAurora Serverless v2 capacity. La capacité réelle de chacun Aurora Serverless v2 le rédacteur ou le lecteur varie au fil du temps, en fonction de votre charge de travail. Pour plus de détails sur ce mécanisme, consultez Aurora Serverless v2 mise à l'échelle.

Configurations pour les clusters de base de données Aurora

Pour chacun de vos clusters de base de données Aurora, vous pouvez choisir n'importe quelle combinaison de Aurora Serverless v2 capacité, capacité provisionnée, ou les deux.

Vous pouvez configurer un cluster contenant les deux Aurora Serverless v2 et de la capacité provisionnée, appelée cluster à configuration mixte. Supposons, par exemple, que vous ayez besoin d'une capacité de lecture/écriture supérieure à celle disponible pour un Aurora Serverless v2 écrivain. Dans ce cas, vous pouvez configurer le cluster avec un enregistreur approvisionné très volumineux. Dans ce cas, vous pouvez toujours utiliser Aurora Serverless v2 pour les lecteurs. Supposons également que la charge de travail d'écriture de votre cluster varie mais que la charge de travail de lecture est stable. Dans ce cas, vous pouvez configurer votre cluster avec un Aurora Serverless v2 écrivain et un ou plusieurs lecteurs approvisionnés.

Vous pouvez également configurer un cluster de base de données dont toute la capacité est gérée par Aurora Serverless v2. Pour ce faire, vous pouvez créer un nouveau cluster et utiliser Aurora Serverless v2 dès le départ. Vous pouvez également remplacer toute la capacité allouée dans un cluster existant par Aurora Serverless v2. Par exemple, certains des chemins de mise à niveau des anciennes versions du moteur nécessitent de commencer par un rédacteur provisionné et de le remplacer par un Aurora Serverless v2 écrivain. Pour les procédures de création d'un nouveau cluster de base de données avec Aurora Serverless v2 ou pour passer d'un cluster de base de données existant à Aurora Serverless v2, voir Création d'un Aurora Serverless v2 Cluster DB etPassage d'un cluster provisionné à Aurora Serverless v2.

Si vous n'utilisez pas Aurora Serverless v2 dans un cluster de base de données, tous les rédacteurs et lecteurs du cluster de base de données sont provisionnés. Il s'agit du type de cluster de bases de données le plus ancien et le plus courant que la plupart des utilisateurs connaissent. En fait, avant Aurora Serverless, il n'y avait pas de nom spécial pour ce type de cluster de base de données Aurora. La capacité approvisionnée est constante. Les frais sont relativement faciles à prévoir. Cependant, vous devez prévoir à l'avance la capacité dont vous avez besoin. Dans certains cas, vos prévisions peuvent être inexactes ou vos besoins en capacité peuvent évoluer. Dans ces cas, votre cluster de bases de données peut devenir sous-approvisionné (plus lent que vous le souhaitez) ou surapprovisionné (plus cher que vous le souhaitez).

Aurora Serverless v2 capacity

L'unité de mesure pour Aurora Serverless v2 est l'unité de capacité Aurora (ACU). Aurora Serverless v2 la capacité n'est pas liée aux classes d'instances de base de données que vous utilisez pour les clusters provisionnés.

Chaque ACU combine environ 2 gibioctets (Gio) de mémoire, avec une UC et une mise en réseau correspondantes. Vous spécifiez la plage de capacité de la base de données à l'aide de cette unité de mesure. Les métriques ServerlessDatabaseCapacity et ACUUtilization vous permettent de déterminer le volume de capacité que votre base de données utilise réellement et où se situe cette capacité dans la plage spécifiée.

À tout moment, chaque Aurora Serverless v2 Le rédacteur ou le lecteur de base de données a une capacité. La capacité est représentée par un nombre à virgule flottante représentant. ACUs La capacité augmente ou diminue chaque fois que l'enregistreur ou le lecteur est mis à l'échelle. Cette valeur est mesurée toutes les secondes. Pour chaque cluster de base de données où vous avez l'intention d'utiliser Aurora Serverless v2, vous définissez une plage de capacité : les valeurs de capacité minimale et maximale que chaque Aurora Serverless v2 l'écrivain ou le lecteur peuvent passer de l'un à l'autre. La plage de capacité est la même pour chacun Aurora Serverless v2 rédacteur ou lecteur dans un cluster de bases de données. Chaque Aurora Serverless v2 l'écrivain ou le lecteur a ses propres capacités, qui se situent quelque part dans cette fourchette.

Le tableau suivant montre Aurora Serverless v2 plages de capacité prises en charge pour Aurora MySQL et Aurora PostgreSQL.

Le plus petit Aurora Serverless v2 la capacité que vous pouvez définir est 0 ACUs, pour Aurora Serverless v2 versions qui prennent en charge la fonctionnalité de pause automatique. Vous pouvez spécifier un nombre plus élevé s'il reste inférieur ou égal à la valeur de capacité maximale. La définition de la capacité minimale sur une faible valeur permet aux clusters de bases de données à faible charge de consommer des ressources de calcul minimales. En même temps, ils restent prêts à accepter des connexions immédiatement et font l'objet d'une augmentation d'échelle lorsqu'ils deviennent occupés.

Nous vous recommandons de définir la capacité minimale sur une valeur qui permet à chaque enregistreur ou lecteur de base de données de conserver l'ensemble de travail de l'application dans le pool de mémoires tampons. De cette façon, le contenu du pool de mémoires tampons n'est pas ignoré pendant les périodes d'inactivité. Pour connaître tous les éléments à prendre en compte lors du choix de la valeur de capacité minimale, consultez Choix de la valeur minimale de capacité Aurora Serverless v2 pour un cluster. Pour connaître tous les éléments à prendre en compte lors du choix de la valeur de capacité maximale, consultez Choix de la valeur maximale de capacité Aurora Serverless v2 pour un cluster.

Selon la façon dont vous configurez les lecteurs dans un déploiement multi-AZ, leurs capacités peuvent être liées à celles du rédacteur ou indépendamment. Pour savoir comment procéder, consultez Aurora Serverless v2 mise à l'échelle.

Surveillance Aurora Serverless v2 implique de mesurer les valeurs de capacité du rédacteur et des lecteurs de votre cluster de bases de données au fil du temps. Si votre base de données ne fait pas l'objet d'une réduction d'échelle à la capacité minimale, vous pouvez prendre des mesures telles que l'ajustement de la capacité minimale et l'optimisation de votre application de base de données. Si votre base de données atteint systématiquement sa capacité maximale, vous pouvez prendre des mesures telles que l'augmentation de la capacité maximale. Vous pouvez également optimiser votre application de base de données et répartir la charge de requête sur un plus grand nombre de lecteurs.

Les frais pour Aurora Serverless v2 les capacités sont mesurées en termes d'heures ACU. Pour plus d'informations sur la façon dont Aurora Serverless v2 les frais sont calculés, consultez la page de tarification d'Aurora.

Supposons que le nombre total de rédacteurs et de lecteurs de votre cluster soit den. Dans ce cas, le cluster consomme environ n x minimum ACUs lorsque vous n'exécutez aucune opération de base de données. Il est possible qu'Aurora exécute des opérations de surveillance ou de maintenance qui entraînent une faible charge. Ce cluster ne consomme pas plus de n x maximum ACUs lorsque la base de données est exécutée à pleine capacité.

Pour plus de détails sur le choix des valeurs d'ACU minimale et maximale appropriées, consultez Choix de la plage de capacité Aurora Serverless v2 pour un cluster Aurora. Les valeurs ACU minimale et maximale que vous spécifiez affectent également le fonctionnement de certains paramètres de configuration Aurora pour Aurora Serverless v2. Pour plus de détails sur l'interaction entre la plage de capacités et les paramètres de configuration, consultezUtilisation des groupes de paramètres pour Aurora Serverless v2.

Aurora Serverless v2 mise à l'échelle

Pour chacun Aurora Serverless v2 enregistreur ou lecteur, Aurora suit en permanence l'utilisation des ressources telles que le processeur, la mémoire et le réseau. L'ensemble de ces mesures est appelé la charge. La charge inclut les opérations de base de données effectuées par votre application. Elle inclut également le traitement en arrière-plan pour le serveur de base de données et les tâches administratives Aurora. Lorsque la capacité est limitée par l'un de ces facteurs, Aurora Serverless v2 augmente. Aurora Serverless v2 prend également de l'ampleur lorsqu'il détecte des problèmes de performances qu'il peut résoudre de cette manière. Vous pouvez surveiller l'utilisation des ressources et son impact Aurora Serverless v2 mise à l'échelle en utilisant les procédures contenues dans Statistiques Amazon CloudWatch importantes pour Aurora Serverless v2 etSurveillance des performances d'Aurora Serverless v2 avec Performance Insights.

La charge peut varier selon l'enregistreur et les lecteurs de votre cluster de bases de données. L'enregistreur gère l'ensemble des instructions de langage de définition de données (DDL), telles que CREATE TABLE, ALTER TABLE et DROP TABLE. Il gère également l'ensemble des instructions de langage de manipulation de données (DML), telles que INSERT et UPDATE. Les lecteurs peuvent traiter les instructions en lecture seule, telles que les requêtes SELECT.

La mise à l'échelle est l'opération qui augmente ou diminue Aurora Serverless v2 capacité de votre base de données. Avec Aurora Serverless v2, chaque enregistreur et lecteur possède sa propre valeur de capacité actuelle, mesurée en ACUs. Aurora Serverless v2 augmente la capacité d'un graveur ou d'un lecteur lorsque sa capacité actuelle est trop faible pour supporter la charge. Il procède à une réduction d'échelle pour l'enregistreur ou le lecteur jusqu'à une capacité inférieure lorsque sa capacité actuelle est supérieure à celle nécessaire.

Contrairement à Aurora Serverless v1, qui évolue en doublant la capacité chaque fois que le cluster de base de données atteint un seuil, Aurora Serverless v2 peut augmenter progressivement la capacité. Lorsque votre charge de travail commence à atteindre la capacité de base de données actuelle d'un rédacteur ou d'un lecteur, Aurora Serverless v2 augmente le nombre de ACUs pour cet écrivain ou lecteur. Aurora Serverless v2 adapte la capacité par incréments nécessaires pour fournir les meilleures performances en fonction des ressources consommées. La mise à l'échelle se fait par incréments aussi petits que 0,5 ACUs. Plus la capacité actuelle est grande, plus l'incrément de mise à l'échelle est important et plus la mise à l'échelle peut être rapide.

Parce que Aurora Serverless v2 la mise à l'échelle est si fréquente, granulaire et non perturbatrice qu'elle ne provoque pas d'événements discrets tels AWS Management Console que Aurora Serverless v1 fait. Au lieu de cela, vous pouvez mesurer les CloudWatch indicateurs Amazon tels que ServerlessDatabaseCapacity ACUUtilization et et suivre leurs valeurs minimales, maximales et moyennes au fil du temps. Pour en savoir plus sur les métriques Aurora, consultez Surveillance des métriques d'un cluster de bases de données Amazon Aurora. Pour obtenir des conseils sur la surveillance Aurora Serverless v2, voir Statistiques Amazon CloudWatch importantes pour Aurora Serverless v2.

Vous pouvez choisir de mettre à l'échelle un lecteur en même temps que l'enregistreur associé, ou indépendamment de l'enregistreur. Pour ce faire, spécifiez le niveau de promotion pour ce lecteur.

Pour plus de détails sur les niveaux de promotion, consultez Choix du niveau de promotion pour un Aurora Serverless v2 lecteur.

Les notions de points d'échelle et de délais d'attente associés à partir de Aurora Serverless v1 ne postulez pas dans Aurora Serverless v2. Aurora Serverless v2 le dimensionnement peut se produire lorsque les connexions à la base de données sont ouvertes, lorsque les transactions SQL sont en cours, lorsque les tables sont verrouillées et lorsque les tables temporaires sont utilisées. Aurora Serverless v2 n'attend pas un moment de calme pour commencer la mise à l'échelle. La mise à l'échelle ne perturbe pas les opérations de base de données en cours.

Si votre charge de travail nécessite une capacité de lecture supérieure à celle disponible avec un seul enregistreur et un seul lecteur, vous pouvez en ajouter plusieurs Aurora Serverless v2 lecteurs du cluster. Chaque Aurora Serverless v2 le lecteur peut évoluer dans la plage des valeurs de capacité minimale et maximale que vous avez spécifiées pour votre cluster de bases de données. Vous pouvez utiliser le point de terminaison du lecteur du cluster pour diriger les séances en lecture seule vers les lecteurs et réduire la charge sur l'enregistreur.

Que Aurora Serverless v2 effectue le dimensionnement, et la rapidité avec laquelle le dimensionnement est effectué une fois qu'il démarre dépend également des paramètres ACU minimum et maximum du cluster. Cela dépend également du fait qu'un lecteur soit configuré pour être mis à l'échelle en même temps que l'enregistreur ou indépendamment de celui-ci. Pour plus de détails sur les facteurs qui influent Aurora Serverless v2 mise à l'échelle, voirPerformances et mise à l'échelle pour Aurora Serverless v2.

Mise à l'échelle jusqu'à zéro

Dans les versions récentes d'Aurora MySQL et d'Aurora PostgreSQL, Aurora Serverless v2 les écrivains et les lecteurs peuvent réduire leur taille à zéro ACUs. Nous appelons cette fonctionnalité une pause et une reprise automatiques, ou une pause automatique. Vous pouvez choisir d'autoriser ce comportement en spécifiant une valeur nulle ou différente de zéro pour la capacité minimale. Vous pouvez également choisir le temps d'attente avant un Aurora Serverless v2 l'instance s'arrête. Pour plus d'informations sur les versions dotées de cette fonctionnalité, consultezAurora Serverless v2 capacity. Pour plus d'informations sur la manière de l'utiliser efficacement, consultezMise à l'échelle jusqu'à zéro ACUs avec pause et reprise automatiques pour Aurora Serverless v2.

Dans les anciennes versions d'Aurora MySQL et d'Aurora PostgreSQL, inactif Aurora Serverless v2 les rédacteurs et les lecteurs peuvent réduire leur taille à la valeur ACU minimale que vous avez spécifiée pour le cluster, mais pas jusqu'à zéro ACUs. Dans ce cas, le zéro ACUs n'est pas disponible comme option lorsque vous définissez la plage de capacité. Ce comportement est différent de Aurora Serverless v1, qui peut s'interrompre après une période d'inactivité, mais qui met ensuite un certain temps à reprendre lorsque vous ouvrez une nouvelle connexion.

Lorsque votre cluster de base de données avec Aurora Serverless v2 la capacité n'est pas nécessaire pendant un certain temps, vous pouvez également arrêter et démarrer l'ensemble du cluster, comme pour les clusters de base de données provisionnés. Cette technique est particulièrement adaptée aux systèmes de développement et de test, où ils peuvent ne pas être nécessaires pendant de nombreuses heures d'affilée et où la rapidité de reprise du cluster n'est pas cruciale. La fonction de cluster arrêt/démarrage est disponible pour tous Aurora Serverless v2 versions. Pour plus d'informations sur cette fonctionnalité, consultezArrêt et démarrage d'un cluster de bases de données Amazon Aurora.

Aurora Serverless v2 et haute disponibilité

Pour établir une haute disponibilité pour un cluster de bases de données Aurora, il convient d'en faire un cluster de bases de données multi-AZ. Un cluster de bases de données Aurora multi-AZ possède une capacité de calcul disponible à tout moment dans plusieurs zones de disponibilité. Cette configuration permet de maintenir votre base de données opérationnelle même en cas de panne importante. Aurora effectue un basculement automatique en cas de problème affectant l'enregistreur ou même l'intégralité de la zone de disponibilité. Avec Aurora Serverless v2, vous pouvez choisir que la capacité de calcul en veille augmente ou diminue en fonction de la capacité du graveur. De cette façon, la capacité de calcul de la deuxième zone de disponibilité est prête à prendre en charge la charge de travail actuelle à tout moment. Dans le même temps, la capacité de calcul globale AZs peut être réduite lorsque la base de données est inactive. Pour plus de détails sur le fonctionnement d'Aurora Régions AWS et les zones de disponibilité, consultezHaute disponibilité pour les instances de base de données Aurora.

Le Aurora Serverless v2 La fonctionnalité Multi-AZ utilise des lecteurs en plus du graveur. Support aux lecteurs est une nouveauté pour Aurora Serverless v2 par rapport à Aurora Serverless v1. Vous pouvez en ajouter jusqu'à 15 Aurora Serverless v2 lecteurs répartis sur 3 AZs vers un cluster de base de données Aurora.

Pour les applications critiques qui doivent rester disponibles même en cas de problème affectant l'ensemble de votre cluster ou de la AWS région, vous pouvez configurer une base de données globale Aurora. Vous pouvez utiliser … Aurora Serverless v2 capacité des clusters secondaires afin qu'ils soient prêts à prendre le relais lors de la reprise après sinistre. Ils peuvent également faire l'objet d'une réduction d'échelle lorsque la base de données n'est pas occupée. Pour plus de détails sur les bases de données globales Aurora, consultez Utilisation de la base de données mondiale Amazon Aurora.

Aurora Serverless v2 fonctionne comme prévu pour le basculement et les autres fonctionnalités de haute disponibilité. Pour de plus amples informations, veuillez consulter Haute disponibilité pour Amazon Aurora.

Supposons que vous souhaitiez garantir une disponibilité maximale pour votre Aurora Serverless v2 cluster. Vous pouvez créer un lecteur en plus de l'enregistreur. Si vous affectez le lecteur au niveau de promotion 0 ou 1, la mise à l'échelle appliquée à l'enregistreur est également appliquée au lecteur. De cette façon, un lecteur ayant une capacité identique est toujours prêt à prendre le relais de l'enregistreur en cas de basculement.

Supposons que vous souhaitiez exécuter des rapports trimestriels pour votre entreprise pendant que votre cluster continue de traiter les transactions. Si vous ajoutez un Aurora Serverless v2 lecteur au cluster et attribuez-le à un niveau de promotion compris entre 2 et 15, vous pouvez vous connecter directement à ce lecteur pour exécuter les rapports. Selon la quantité de mémoire et de processeur exigée par les requêtes de rapport, ce lecteur peut faire l'objet d'une augmentation d'échelle en fonction de la charge de travail. Il peut ensuite faire l'objet d'une réduction d'échelle une fois les rapports terminés.

Aurora Serverless v2 et rangement

Le stockage de chaque cluster de base de données Aurora se compose de six copies de toutes vos données, réparties sur trois AZs. Cette réplication de données intégrée s'applique, que votre cluster de bases de données comporte ou non des lecteurs en plus de l'enregistreur. De cette façon, vos données sont sécurisées, même contre les problèmes qui affectent la capacité de calcul du cluster.

Aurora Serverless v2 le stockage présente les mêmes caractéristiques de fiabilité et de durabilité que celles décrites dansStockage Amazon Aurora. En effet, le stockage des clusters de base de données Aurora fonctionne de la même manière, que la capacité de calcul utilise Aurora Serverless v2 ou provisionné.

Paramètres de configuration des clusters Aurora

Vous pouvez ajuster les mêmes paramètres de configuration de cluster et de base de données pour les clusters avec Aurora Serverless v2 capacité comme pour les clusters de base de données provisionnés. Cependant, certains paramètres liés à la capacité sont traités différemment pour Aurora Serverless v2. Dans un cluster à configuration mixte, les valeurs de paramètres que vous spécifiez pour les paramètres liés à la capacité s'appliquent toujours à tous les rédacteurs et lecteurs provisionnés.

Presque tous les paramètres fonctionnent de la même manière pour Aurora Serverless v2 écrivains et lecteurs comme pour les rédacteurs approvisionnés. Les exceptions concernent certains paramètres ajustés automatiquement par Aurora pendant la mise à l'échelle, et certains paramètres qu'Aurora conserve à des valeurs fixes qui dépendent de la valeur de la capacité maximale.

Par exemple, la quantité de mémoire réservée au cache de la mémoire tampon augmente à mesure de l'augmentation d'échelle d'un enregistreur ou d'un lecteur, et diminue à mesure de sa réduction d'échelle. De cette façon, la mémoire peut être libérée lorsque votre base de données n'est pas occupée. À l'inverse, Aurora définit automatiquement le nombre maximal de connexions sur une valeur appropriée en fonction de la valeur de la capacité maximale. De cette façon, les connexions actives ne sont pas interrompues si la charge diminue et Aurora Serverless v2 réduit. Pour plus d'informations sur la façon dont Aurora Serverless v2 gère des paramètres spécifiques, voirUtilisation des groupes de paramètres pour Aurora Serverless v2.