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.
Fonctionnement d'Aurora Serverless v2
La présentation suivante décrit le fonctionnement d'Aurora Serverless v2.
Rubriques
Présentation d'Aurora Serverless v2
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 provisionnés, vous choisissez une classe d'instance de base de données dotée d'une quantité prédéfinie de mémoire, de puissance du processeur, de I/O bande passante, 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 assurer le même degré de sécurité et d'isolement que les enregistreurs et les lecteurs approvisionnés. 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.
Aurora Serverless v2 vous permet de créer un cluster de bases de données Aurora sans être limité à une capacité de base de données spécifique pour chaque enregistreur et lecteur. Vous spécifiez la plage de capacité minimale et maximale. Aurora met à l'échelle chaque enregistreur ou lecteur Aurora Serverless v2 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 met automatiquement à l'échelle les ressources de base de données en fonction de vos spécifications minimale et maximale de capacité. 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 enregistreur/lecteur Aurora Serverless v2 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 approvisionnés, la capacité de stockage et la capacité de calcul sont séparées. Lorsqu'il est fait référence à la capacité et à la mise à l’échelle Aurora Serverless v2, il s'agit toujours de 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 la capacité Aurora Serverless v2, consultez Capacité Aurora Serverless v2. La capacité réelle de chaque enregistreur ou lecteur Aurora Serverless v2 varie au fil du temps, en fonction de votre charge de travail. Pour plus de détails sur ce mécanisme, consultez Mise à l'échelle d'Aurora Serverless v2.
Important
Avec Aurora Serverless v1, votre cluster dispose d'une seule mesure de la capacité de calcul qui peut être mise à l'échelle entre les valeurs de capacité minimale et maximale. Avec Aurora Serverless v2, votre cluster peut contenir des lecteurs en plus de l'enregistreur. Chaque enregistreur et lecteur Aurora Serverless v2 peut être mis à l'échelle entre les valeurs de capacité minimale et maximale. Ainsi, la capacité totale de votre cluster Aurora Serverless v2 dépend de la plage de capacité que vous définissez pour votre cluster de bases de données, mais également du nombre d'enregistreurs et de lecteurs dans le cluster. Quelle que soit l'heure, seule la capacité Aurora Serverless v2 qui est activement utilisée dans votre cluster de bases de données Aurora vous est facturée.
Configurations pour les clusters de base de données Aurora
Pour chacun de vos clusters de bases de données Aurora, vous pouvez choisir n'importe quelle combinaison de capacité Aurora Serverless v2 et/ou de capacité approvisionnée.
Vous pouvez configurer un cluster qui contient la capacité Aurora Serverless v2 et la capacité approvisionnée, appelé cluster à configuration mixte. Supposons, par exemple, que vous ayez besoin d'une read/write capacité supérieure à celle disponible pour un Aurora Serverless v2 graveur. 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 enregistreur Aurora Serverless v2 et un ou plusieurs lecteurs approvisionnés.
Vous pouvez également configurer un cluster de bases de données où l'ensemble de la capacité est géré par Aurora Serverless v2. Pour ce faire, vous pouvez créer un cluster et utiliser Aurora Serverless v2 dès le départ. Vous pouvez également remplacer l'ensemble de la capacité approvisionnée d'un cluster existant par Aurora Serverless v2. Par exemple, certains chemins de mise à niveau des anciennes versions du moteur exigent de commencer avec un enregistreur approvisionné et de le remplacer par un enregistreur Aurora Serverless v2. Pour obtenir les procédures de création d'un cluster de bases de données avec Aurora Serverless v2 ou de basculement d'un cluster de bases de données existant vers Aurora Serverless v2, consultez Création d'un Aurora Serverless v2 Cluster DB et Passage d'un cluster provisionné à Aurora Serverless v2.
Si vous n'utilisez pas du tout Aurora Serverless v2 dans un cluster de bases de données, tous les enregistreurs et lecteurs du cluster de bases de données sont approvisionné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, ce type de cluster de bases de données Aurora ne portait pas de nom spécifique. 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).
Capacité Aurora Serverless v2
L'unité de mesure pour Aurora Serverless v2 est l'unité de capacité Aurora (ACU). La capacité Aurora Serverless v2 n'est pas liée aux classes d'instance de base de données que vous utilisez pour les clusters approvisionné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.
À un moment donné, chaque enregistreur ou lecteur de base de données Aurora Serverless v2 possède 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 bases de données sur lequel vous prévoyez d'utiliser Aurora Serverless v2, vous définissez une plage de capacité : il s'agit des valeurs de capacité minimale et maximale entre lesquelles chaque enregistreur ou lecteur Aurora Serverless v2 peut être mis à l'échelle. La plage de capacité est identique pour chaque enregistreur ou lecteur Aurora Serverless v2 dans un cluster de bases de données. Chaque enregistreur ou lecteur Aurora Serverless v2 possède sa propre capacité, qui se situe quelque part dans cette plage.
Le tableau suivant indique les plages de Aurora Serverless v2 capacité et la prise en charge des versions de moteur pour Aurora MySQL et Aurora PostgreSQL.
Plage de capacité (ACUs) | Versions prises en charge par Aurora MySQL | Versions prises en charge par Aurora PostgreSQL |
---|---|---|
0,5 à 128 | 3.02.0 et versions ultérieures | 13,6 et supérieur, 14,3 et supérieur, 15,2 et supérieur, 16,1 et supérieur |
0,5 à 256 | 3.06.0 et versions supérieures | 13,13 et supérieur, 14,10 et supérieur, 15,5 et supérieur, 16,1 et supérieur |
0 à 256 | 3.08.0 et versions ultérieures | 13,15 et plus, 14,12 et plus, 15,7 et plus, 16,3 et plus |
Le tableau suivant présente les versions de la Aurora Serverless v2 plate-forme avec leurs gammes ACU et leurs caractéristiques de performance.
Version de plateforme Aurora Serverless v2 | Gamme ACU | Performances |
---|---|---|
1 | 0 à 128 | Performances de référence |
2 | 0 à 256 | Performances de référence |
3 | 0 à 256 | Performances améliorées jusqu'à 30 % par rapport à la version 2 de la plateforme |
Note
La plage de mise à l'échelle disponible pour un cluster donné est déterminée à la fois par la version du moteur et par la version de la plate-forme. Il est possible qu'une version de moteur plus performante fonctionne sur une version de plate-forme moins performante et vice-versa. La plage de mise à l'échelle est déterminée par la version du moteur ou de la plate-forme la moins performante.
Vous pouvez déterminer la version de plate-forme sur laquelle votre cluster s'exécute dans la section Configuration de l'instance de l'API AWS Management Console ou via l'API en consultant le ServerlessV2PlatformVersion
pour un DBCluster.
La Aurora Serverless v2 capacité minimale que vous pouvez définir est 0 ACUs, pour les 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 Mise à l'échelle d'Aurora Serverless v2.
La surveillance d'Aurora Serverless v2 implique de mesurer les valeurs de capacité de l'enregistreur 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 associés à la capacité Aurora Serverless v2 sont mesurés en termes d'heures ACU. Pour plus d'informations sur la procédure de calcul des frais associés à Aurora Serverless v2, consultez la page de tarification 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
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 minimum ACUs
n x
lorsque la base de données est exécutée à pleine capacité.maximum ACUs
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 d'ACU minimale et maximale que vous spécifiez affectent également la façon dont certains paramètres de configuration Aurora fonctionnent pour Aurora Serverless v2. Pour plus de détails sur l'interaction entre la plage de capacité et les paramètres de configuration, consultez Utilisation des groupes de paramètres pour Aurora Serverless v2.
Mise à l'échelle d'Aurora Serverless v2
Pour chaque enregistreur ou lecteur Aurora Serverless v2, 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 fait l'objet d'une augmentation d'échelle. Aurora Serverless v2 fait également l'objet d'une augmentation d'échelle lorsqu'il détecte des problèmes de performances qu'il peut résoudre en procédant ainsi. Vous pouvez surveiller l'utilisation des ressources et son impact sur la mise à l'échelle d'Aurora Serverless v2 en utilisant les procédures décrites aux rubriques Statistiques Amazon CloudWatch importantes pour Aurora Serverless v2 et Surveillance 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 la capacité Aurora Serverless v2 de votre base de données. AvecAurora Serverless v2, chaque écrivain et lecteur a sa propre valeur de capacité actuelle, mesurée en ACUs. Aurora Serverless v2augmente 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, dont la mise à l'échelle double la capacité chaque fois que le cluster de bases de données atteint un certain seuil, Aurora Serverless v2 peut augmenter la capacité de manière incrémentielle. Lorsque votre charge de travail commence à atteindre la capacité actuelle de la base de données d'un rédacteur ou d'un lecteur, le nombre de ACUs pages pour ce rédacteur ou lecteur Aurora Serverless v2 augmente. Aurora Serverless v2adapte 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.
La Aurora Serverless v2 mise à l'échelle étant si fréquente, granulaire et non perturbatrice, elle ne provoque pas d'événements discrets comme c'Aurora Serverless v1est AWS Management Console le cas. 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 d'Aurora Serverless v2, consultez 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.
-
Les lecteurs aux niveaux de promotion 0 et 1 sont mis à l'échelle en même temps que l'enregistreur. Ce comportement de mise à l'échelle rend les lecteurs aux niveaux de priorité 0 et 1 parfaitement adaptés à la disponibilité. En effet, ils sont toujours dimensionnés à la bonne capacité pour prendre en charge la charge de travail de l'enregistreur en cas de basculement.
-
Les lecteurs aux niveaux de promotion 2 à 15 sont mis à l'échelle indépendamment de l'enregistreur. Chaque lecteur reste dans les valeurs d'ACU minimale et maximale que vous avez spécifiées pour votre cluster. Lorsqu'un lecteur est mis à l'échelle indépendamment de la base de données d'enregistreur associée, il peut devenir inactif et faire l'objet d'une réduction d'échelle pendant que l'enregistreur continue à traiter un volume élevé de transactions. Il est toujours disponible en tant que cible de basculement, si aucun autre lecteur n'est disponible aux niveaux de promotion inférieurs. Toutefois, s'il est promu en enregistreur, il devra peut-être faire l'objet d'une augmentation d'échelle pour gérer l'ensemble de la charge de travail de l'enregistreur.
Pour plus de détails sur les niveaux de promotion, consultez Choix du niveau de promotion pour un lecteur Aurora Serverless v2.
Les notions Aurora Serverless v1 de points de mise à l'échelle et de délais d'expiration associés ne s'appliquent pas dans Aurora Serverless v2. La mise à l'échelle d'Aurora Serverless v2 peut intervenir lorsque les connexions à la base de données sont ouvertes, alors que les transactions SQL sont en cours de traitement, que les tables sont verrouillées et que les tables temporaires sont en cours d'utilisation. Aurora Serverless v2 n'attend pas de point silencieux 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 exige une capacité de lecture supérieure à celle disponible avec un seul enregistreur et un seul lecteur, vous pouvez ajouter plusieurs lecteurs Aurora Serverless v2 au cluster. Chaque lecteur Aurora Serverless v2 peut être mis à l'échelle dans la plage de valeurs d'ACU minimale et maximale que vous avez spécifiée 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.
Les valeurs d'ACU minimale et maximale du cluster ont également un impact sur le fait qu'Aurora Serverless v2 effectue une mise à l'échelle ou non, et sur la rapidité de la mise à l'échelle une fois qu'elle démarre. 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 affectent la mise à l’échelle d'Aurora Serverless v2, consultez Performances 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 PostgreSQLAurora Serverless v2, les rédacteurs et les lecteurs peuvent effectuer une mise à l'échelle jusqu'à 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 qu'une Aurora Serverless v2 instance ne soit mise en pause. Pour plus d'informations sur les versions dotées de cette fonctionnalité, consultezCapacité Aurora Serverless v2. 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, les programmes Aurora Serverless v2 d'écriture et de lecture inactifs pouvaient être réduits à 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 d'Aurora Serverless v1, qui peut faire une pause après une période d'inactivité, mais qui prend ensuite un certain temps pour reprendre lorsque vous ouvrez une nouvelle connexion.
Lorsque votre cluster de base de données doté de Aurora Serverless v2 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 fonctionnalité de stop/start cluster est disponible pour toutes les 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 définir que la capacité de calcul de secours fasse l'objet d'une augmentation et d'une réduction d'échelle en même temps que la capacité de l'enregistreur. 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.
La fonctionnalité multi-AZ d'Aurora Serverless v2 utilise des lecteurs en plus de l'enregistreur. La prise en charge des lecteurs est une nouveauté d'Aurora Serverless v2 par rapport à Aurora Serverless v1. Vous pouvez ajouter jusqu'à 15 Aurora Serverless v2 lecteurs répartis sur 3 AZs à 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 la capacité Aurora Serverless v2 dans les clusters secondaires afin qu'ils soient prêts à prendre le relais pendant 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 en mode approvisionné pour le basculement et d'autres fonctionnalités de haute disponibilité. Pour de plus amples informations, veuillez consulter Haute disponibilité pour Amazon Aurora.
Supposons que vous souhaitiez garantir la disponibilité maximale de votre cluster Aurora Serverless v2. 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 lecteur Aurora Serverless v2 au cluster et lui attribuez 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 stockage
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.
Le stockage Aurora Serverless v2 présente les mêmes caractéristiques de fiabilité et de durabilité que celles décrites à la rubrique Stockage Amazon Aurora. En effet, le stockage des clusters de bases de données Aurora fonctionne de la même manière, que la capacité de calcul utilise Aurora Serverless v2 ou le mode approvisionné.
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 la capacité Aurora Serverless v2 que pour les clusters de bases de données approvisionnés. Cependant, certains paramètres de capacité sont traités différemment pour Aurora Serverless v2. Dans un cluster à configuration mixte, les valeurs que vous spécifiez pour ces paramètres de capacité s'appliquent toujours à tous les enregistreurs et lecteurs approvisionnés.
Presque tous les paramètres fonctionnent de la même manière pour les enregistreurs et les lecteurs Aurora Serverless v2 que pour ceux en mode approvisionné. 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 si Aurora Serverless v2 fait l'objet d'une réduction d'échelle. Pour obtenir des informations sur la façon dont Aurora Serverless v2 gère certains paramètres, consultez Utilisation des groupes de paramètres pour Aurora Serverless v2.