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.
# Utilisation d'Amazon DocumentDB sans serveur
Amazon DocumentDB serverless est une configuration de dimensionnement automatique à la demande qui automatise les processus d'ajustement dynamique de la capacité de votre base de données Amazon DocumentDB en fonction de la demande de l'application. Vous êtes facturé uniquement pour les ressources consommées par vos clusters. Ainsi, DocumentDB sans serveur peut vous aider à respecter votre budget et à éviter de payer pour des ressources informatiques que vous n'utilisez pas.
Ce type d'automatisation est particulièrement utile pour les environnements soumis à des charges de travail très variables et imprévisibles, tels que les bases de données mutualisées, les bases de données distribuées et les systèmes de développement et de test.
**Topics**
+ [Cas d'utilisation du mode sans serveur](#docdb-serverless-use-cases)
+ [Avantages d'Amazon DocumentDB sans serveur](#docdb-serverless-advantages)
+ [Comment fonctionne le sans serveur](docdb-serverless-how-it-works.md)
+ [Exigences et limites de l'environnement sans serveur](docdb-serverless-limitations.md)
+ [Création d'un cluster utilisant le mode sans serveur](docdb-serverless-create-cluster.md)
+ [Migration vers le mode sans serveur](docdb-serverless-migrating.md)
+ [Gestion sans serveur](docdb-serverless-managing.md)
+ [Limites d'instances sans serveur](docdb-serverless-instance-limits.md)
+ [Configuration de dimensionnement sans serveur](docdb-serverless-scaling-config.md)
+ [Surveillance sans serveur](docdb-serverless-monitoring.md)
## Cas d'utilisation de DocumentDB sans serveur
Les clusters provisionnés par Amazon DocumentDB et DocumentDB sans serveur prennent en charge de nombreux types de charges de travail de base de données, des environnements de développement et de test aux applications critiques les plus exigeantes qui nécessitent une évolutivité et une disponibilité élevées. Mais DocumentDB serverless ajoute une autre dimension aux charges de travail des clients, à savoir la capacité de prendre en charge des sites Web et des applications dont les charges de travail sont imprévisibles.
DocumentDB serverless est particulièrement utile dans les cas d'utilisation suivants :
+ **Charges de travail variables** : vous exécutez des charges de travail dont l'activité augmente de manière soudaine et imprévisible. Par exemple, un site d’informations sur la circulation routière qui pourrait connaître un pic d’activité lorsqu’il commence à pleuvoir. Autre exemple, un site de e-commerce dont le trafic augmente lorsque vous proposez des soldes ou des promotions spéciales. Avec DocumentDB serverless, votre base de données adapte automatiquement sa capacité pour répondre aux besoins liés à la charge maximale de l'application et la redimensionne à la baisse lorsque le pic d'activité est terminé. Avec DocumentDB sans serveur, vous n'avez plus besoin de prévoir une capacité maximale ou moyenne. Vous pouvez spécifier une limite de capacité supérieure pour faire face au pire des cas, cette capacité n'étant utilisée que si elle est nécessaire.
+ La granularité du dimensionnement dans DocumentDB sans serveur vous permet d'adapter la capacité au plus près aux besoins de votre base de données. Pour un cluster provisionné, la mise à l'échelle nécessite l'ajout d'une toute nouvelle instance. DocumentDB serverless peut ajouter un demi-DCU lorsque seulement un peu plus de capacité est nécessaire. Il peut en ajouter 0,5, 1, 1,5, 2 ou la moitié en DCUs fonction de la capacité supplémentaire nécessaire pour faire face à une augmentation de la charge de travail. Et il peut en supprimer 0,5, 1, 1,5, 2, ou encore la moitié, DCUs lorsque la charge de travail diminue et que cette capacité n'est plus nécessaire.
+ **Applications mutualisées** : avec DocumentDB sans serveur, vous n'avez pas à gérer individuellement la capacité de la base de données pour chaque application de votre parc. DocumentDB sans serveur gère pour vous la capacité individuelle des bases de données.
+ Vous pouvez créer un cluster pour chaque locataire. Ainsi, vous pouvez utiliser des fonctionnalités telles que le clonage et la restauration instantanée pour améliorer la haute disponibilité et la reprise après sinistre en fonction des besoins de chaque locataire.
+ Chaque locataire peut avoir des périodes de pointe ou d'inactivité spécifiques en fonction de l'heure de la journée, de la période de l'année, des événements promotionnels, etc. Chaque cluster peut avoir une plage de capacité étendue. Ainsi, les clusters à faible activité entraînent des frais d'instance minimes. N'importe quel cluster peut rapidement subir une augmentation d'échelle pour gérer les périodes de forte activité.
+ **Nouvelles applications** : vous déployez une nouvelle application et vous n'êtes pas sûr de la taille d'instance dont vous avez besoin. En utilisant DocumentDB sans serveur, vous pouvez configurer un cluster avec une ou plusieurs instances et adapter automatiquement la base de données aux exigences de capacité de votre application.
+ **Applications à usage mixte** : supposons que vous disposiez d'une application de traitement des transactions en ligne (OLTP), mais que vous subissiez régulièrement des pics de trafic de requêtes. En spécifiant des niveaux de promotion pour les instances sans serveur DocumentDB d'un cluster, vous pouvez configurer votre cluster afin que les instances du lecteur puissent évoluer indépendamment de l'instance du rédacteur afin de gérer la charge supplémentaire. Lorsque le pic d'utilisation diminue, les instances du lecteur sont réduites pour correspondre à la capacité de l'instance du rédacteur.
+ **Planification des capacités** : supposons que vous ajustez généralement la capacité de votre base de données ou que vous vérifiiez la capacité de base de données optimale pour votre charge de travail en modifiant les classes d'instance de toutes les instances d'un cluster. Avec DocumentDB sans serveur, vous pouvez éviter cette surcharge administrative. Vous pouvez déterminer la capacité minimale et maximale appropriée en exécutant la charge de travail et en vérifiant le degré d'évolutivité réel des instances.
+ Vous pouvez modifier les instances existantes de DocumentDB provisionnées vers DocumentDB sans serveur ou de DocumentDB sans serveur vers Provisionnées. Il n'est pas nécessaire de créer un nouveau cluster ou une nouvelle instance dans de tels cas.
+ **Développement et tests** — Outre l'exécution de vos applications les plus exigeantes, vous pouvez également utiliser DocumentDB sans serveur pour les environnements de développement et de test. Avec DocumentDB serverless, vous pouvez créer des instances avec une faible capacité minimale au lieu d'utiliser des classes d'instance db.t\$1 burstables. Vous pouvez définir une capacité maximale suffisamment élevée pour que ces instances puissent continuer à exécuter des charges de travail importantes sans manquer de mémoire. Lorsque la base de données n'est pas utilisée, toutes les instances sont réduites pour éviter des frais inutiles.
### Utilisation d'Amazon DocumentDB sans serveur pour les charges de travail provisionnées existantes
Supposons qu'une application DocumentDB s'exécute déjà sur un cluster provisionné. Vous pouvez vérifier le fonctionnement de l'application avec DocumentDB sans serveur en ajoutant une ou plusieurs instances de DocumentDB sans serveur au cluster existant en tant qu'instances de lecteur. Vous pouvez vérifier la fréquence à laquelle les instances du lecteur augmentent ou diminuent. Vous pouvez utiliser le mécanisme de basculement de DocumentDB pour promouvoir une instance sans serveur DocumentDB en tant que rédactrice et vérifier comment elle gère la charge de travail. read/write De cette façon, vous pouvez basculer avec un temps d'arrêt minimal, sans modifier le point de terminaison utilisé par vos applications clientes. Pour plus de détails sur la procédure de conversion de clusters existants en DocumentDB sans serveur, consultez. [Migration vers Amazon DocumentDB sans serveur](docdb-serverless-migrating.md)
## Avantages d'Amazon DocumentDB sans serveur
DocumentDB sans serveur est destiné aux charges de travail variables ou « pointues ». Avec ces charges de travail imprévisibles, il est possible que vous ayez des difficultés à planifier le moment où modifier la capacité de votre base de données. Vous pouvez également avoir du mal à modifier les capacités assez rapidement en utilisant les mécanismes habituels tels que l'ajout d'instances ou la modification de classes d'instances. DocumentDB serverless offre les avantages suivants pour vous aider dans de tels cas d'utilisation :
+ **Gestion des capacités plus simple que celle allouée** : DocumentDB sans serveur réduit les efforts liés à la planification de la taille des instances et au redimensionnement des instances en fonction de l'évolution de la charge de travail. Cela réduit également les efforts nécessaires pour maintenir une capacité constante pour toutes les instances d'un cluster.
+ **Mise à l'échelle plus rapide et plus facile pendant les périodes de forte activité** : DocumentDB adapte la capacité de calcul et de mémoire en fonction des besoins, sans perturber les transactions clients ni votre charge de travail globale. La possibilité d'utiliser des instances de lecteur avec DocumentDB sans serveur vous permet de tirer parti de la mise à l'échelle horizontale en plus de la mise à l'échelle verticale. La possibilité d'utiliser des clusters globaux DocumentDB signifie que vous pouvez répartir votre charge de travail de lecture sans serveur DocumentDB sur plusieurs. Régions AWS Cette fonctionnalité est plus pratique que les mécanismes de mise à l’échelle des clusters approvisionnés.
+ **Rentable en période de faible activité** : DocumentDB sans serveur vous permet d'éviter de surprovisionner vos instances. DocumentDB sans serveur ajoute des ressources par incréments granulaires lorsque les instances augmentent. Vous ne payez que pour les ressources de base de données que vous consommez. L'utilisation des ressources sans serveur DocumentDB est mesurée par seconde. Ainsi, lorsqu'une instance est réduite, la réduction de l'utilisation des ressources est immédiatement enregistrée.
+ **Parité des fonctionnalités avec les fonctionnalités provisionnées** — Vous pouvez utiliser toutes les fonctionnalités de DocumentDB avec DocumentDB sans serveur. Par exemple, avec DocumentDB serverless, vous pouvez utiliser des instances de lecteur, l'authentification de base de données Gestion des identités et des accès AWS (IAM) et Performance Insights.
Avec DocumentDB serverless, vous pouvez notamment tirer parti des fonctionnalités suivantes à partir de clusters provisionnés :
+ **Instances de lecteur** : DocumentDB sans serveur peut tirer parti des instances de lecteur pour effectuer une mise à l'échelle horizontale. Lorsqu'un cluster contient une ou plusieurs instances de lecteur, le cluster peut basculer immédiatement en cas de problème avec l'instance d'écriture.
+ **Clusters multi-AZ** : vous pouvez distribuer les instances sans serveur DocumentDB d'un cluster sur plusieurs zones de disponibilité (). AZs La configuration d'un cluster multi-AZ permet d'assurer la continuité de l'activité, même dans les rares cas de problèmes qui affectent l'ensemble d'une zone de disponibilité.
+ **Clusters globaux** — Vous pouvez utiliser DocumentDB sans serveur en combinaison avec des clusters globaux DocumentDB pour créer des copies supplémentaires en lecture seule de votre cluster dans d'autres applications à des fins de reprise après sinistre. Régions AWS
# Comment fonctionne Amazon DocumentDB sans serveur
**Topics**
+ [Présentation de](#docdb-serverlerss-overviewn)
+ [Configurations pour les clusters Amazon DocumentDB](#docdb-serverlerss-configuration)
+ [Capacité de mise à l'échelle sans serveur Amazon DocumentDB](#docdb-serverless-scaling-capacity)
+ [Dimensionnement sans serveur Amazon DocumentDB](#docdb-serverless-scaling)
+ [État inactif (0,5 DCUs)](#docdb-serverlerss-idle-state)
## Présentation de
Amazon DocumentDB sans serveur convient aux charges de travail les plus exigeantes et les plus variables. 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 provisionnés DocumentDB sont adaptés aux charges de travail stables. Avec les clusters provisionnés, vous choisissez une classe d'instance 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.
DocumentDB serverless est entièrement conçu pour prendre en charge les clusters sans serveur instantanément évolutifs. DocumentDB serverless est conçu pour fournir le même degré de sécurité et d'isolation que les rédacteurs et lecteurs provisionné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.
En utilisant DocumentDB sans serveur, vous pouvez créer un cluster DocumentDB sans être bloqué dans 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. DocumentDB adapte chaque enregistreur ou lecteur sans serveur DocumentDB 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é.
DocumentDB sans serveur adapte 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 rédacteur ou un lecteur DocumentDB sans serveur est déplacé d'un hôte à un autre, DocumentDB sans serveur 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 DocumentDB sans serveur, comme avec les clusters provisionnés, la capacité de stockage et la capacité de calcul sont distinctes. Lorsque nous parlons de capacité et de dimensionnement sans serveur de DocumentDB, 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. La capacité réelle de chaque rédacteur ou lecteur DocumentDB sans serveur varie dans le temps, en fonction de votre charge de travail. Pour plus de détails sur ce mécanisme, consultez [Dimensionnement sans serveur Amazon DocumentDB](#docdb-serverless-scaling).
## Configurations pour les clusters Amazon DocumentDB
Pour chacun de vos clusters Amazon DocumentDB, vous pouvez choisir n'importe quelle combinaison de capacité sans serveur DocumentDB, de capacité provisionnée, ou les deux.
Vous pouvez configurer un cluster contenant à la fois de la capacité sans serveur et de la capacité provisionnée de DocumentDB, appelé cluster à configuration mixte. Supposons, par exemple, que vous ayez besoin d'une read/write capacité supérieure à celle disponible pour un rédacteur sans serveur DocumentDB. Dans ce cas, vous pouvez configurer le cluster avec un enregistreur approvisionné très volumineux. Dans ce cas, vous pouvez toujours utiliser DocumentDB sans serveur 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 rédacteur sans serveur DocumentDB et un ou plusieurs lecteurs provisionnés.
Vous pouvez également configurer un cluster dont toute la capacité est gérée par DocumentDB sans serveur. Pour ce faire, vous pouvez créer un nouveau cluster et utiliser DocumentDB sans serveur dès le départ. Vous pouvez également remplacer toute la capacité provisionnée d'un cluster existant par DocumentDB sans serveur. Pour les procédures permettant de créer un nouveau cluster avec DocumentDB sans serveur ou de passer d'un cluster existant à DocumentDB sans serveur, voir et. [Création d'un cluster utilisant Amazon DocumentDB sans serveur](docdb-serverless-create-cluster.md) [Migration vers Amazon DocumentDB sans serveur](docdb-serverless-migrating.md)
Si vous n'utilisez pas du tout DocumentDB sans serveur dans un cluster, tous les rédacteurs et lecteurs du cluster sont provisionnés. Il s'agit du type de cluster le plus courant que la plupart des utilisateurs connaissent. 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 peut être sous-provisionné (plus lent que vous ne le souhaitez) ou surapprovisionné (plus cher que vous ne le souhaitez).
## Capacité de mise à l'échelle sans serveur Amazon DocumentDB
L'unité de mesure pour Amazon DocumentDB serverless est l'unité de capacité DocumentDB (DCU). La capacité de dimensionnement sans serveur de DocumentDB n'est pas liée aux classes d'instances que vous utilisez pour les clusters provisionnés.
Chaque DCU est une combinaison d'environ 2 Gibioctets (GiB) de mémoire, du processeur correspondant et du réseau. 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 `DCUUtilization` CloudWatch 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 enregistreur ou lecteur DocumentDB sans serveur dispose d'une capacité. La capacité est un nombre à virgule flottante représentant. DCUs 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 dans lequel vous avez l'intention d'utiliser DocumentDB sans serveur, vous définissez une plage de capacité : les valeurs de capacité minimale et maximale entre lesquelles chaque rédacteur ou lecteur DocumentDB sans serveur peut évoluer. La plage de capacité est la même pour chaque enregistreur ou lecteur DocumentDB sans serveur d'un cluster. Chaque rédacteur ou lecteur DocumentDB sans serveur possède sa propre capacité, qui se situe quelque part dans cette fourchette.
DocumentDB serverless est uniquement pris en charge sur DocumentDB 5.0.0 (non pris en charge sur 8.0) avec une plage de capacité comprise entre 0,5 et 256. DCUs
La plus petite capacité sans serveur de DocumentDB que vous pouvez définir est de 0,5. DCUs Vous pouvez spécifier un nombre supérieur s'il est inférieur ou égal à la valeur de capacité maximale prise en charge. La définition de la capacité minimale sur un petit nombre permet aux clusters légèrement chargés de consommer un minimum de ressources de calcul. 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 recommandons de définir le minimum sur une valeur permettant à chaque rédacteur ou lecteur de conserver l'ensemble de travail de l'application dans le pool de mémoire tampon. De cette façon, le contenu du groupe 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 plage de capacités de mise à l'échelle, voir[Choix de la plage de capacité de dimensionnement pour un cluster sans serveur DocumentDB](docdb-serverless-scaling-config.md#docdb-serverless-scaling-capacity-choosing).
Selon la façon dont vous configurez les lecteurs dans un déploiement multi-AZ, leur capacité peut être liée à la capacité de l’enregistreur ou être indépendante. Pour savoir comment procéder, consultez [Affichage et modification du niveau de promotion des lecteurs sans serveur](docdb-serverless-managing.md#docdb-serverless-promo-tier).
La surveillance de DocumentDB sans serveur implique de mesurer les valeurs de capacité du rédacteur et des lecteurs de votre cluster 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 liés à la capacité sans serveur de DocumentDB sont mesurés en heures de DCU. [Pour plus d'informations sur le mode de calcul des frais sans serveur DocumentDB, consultez la tarification d'Amazon DocumentDB.](https://aws.amazon.com//documentdb/pricing) Supposons que le nombre total d’enregistreurs et de lecteurs de votre cluster soit de n. Dans ce cas, le cluster consomme environ n x minimum DCUs lorsque vous n'exécutez aucune opération de base de données. Amazon DocumentDB lui-même peut exécuter des opérations de surveillance ou de maintenance qui génèrent une faible charge. Ce cluster ne consomme pas plus de n x maximum DCUs lorsque la base de données fonctionne à pleine capacité.
Pour plus de détails sur le choix des valeurs DCU minimales et maximales appropriées, consultez[Choix de la plage de capacité de dimensionnement pour un cluster sans serveur DocumentDB](docdb-serverless-scaling-config.md#docdb-serverless-scaling-capacity-choosing). Les valeurs DCU minimales et maximales que vous spécifiez affectent également certaines limites d'instance Amazon DocumentDB. Pour plus de détails sur l'interaction entre la plage de capacité et les limites d'instance, consultez[Limites des instances sans serveur Amazon DocumentDB](docdb-serverless-instance-limits.md).
## Dimensionnement sans serveur Amazon DocumentDB
Pour chaque rédacteur ou lecteur DocumentDB sans serveur, Amazon DocumentDB 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. Il inclut également le traitement en arrière-plan pour le serveur de base de données et les tâches administratives d'Amazon DocumentDB. Lorsque la capacité est limitée par l'un de ces facteurs, DocumentDB augmente la capacité sans serveur. DocumentDB serverless prend également de l'ampleur lorsqu'il détecte des problèmes de performances qu'il peut ainsi résoudre. Vous pouvez surveiller l'utilisation des ressources et son impact sur le dimensionnement sans serveur de DocumentDB en utilisant les procédures décrites dans. [Surveillance d'Amazon DocumentDB sans serveur](docdb-serverless-monitoring.md)
La charge peut varier selon le rédacteur et les lecteurs de votre cluster. Le rédacteur gère les opérations d'écriture et effectue toutes les modifications de données sur le volume du cluster. Les lecteurs peuvent traiter les demandes en lecture seule.
Le dimensionnement est l'opération qui augmente ou diminue la capacité sans serveur DocumentDB de votre base de données. Avec DocumentDB sans serveur, chaque enregistreur et lecteur possède sa propre valeur de capacité actuelle, mesurée en. DCUs DocumentDB sans serveur 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.
DocumentDB serverless peut augmenter la capacité de manière incrémentielle. Lorsque votre charge de travail commence à atteindre la capacité de base de données actuelle d'un rédacteur ou d'un lecteur, DocumentDB sans serveur augmente le nombre de fichiers DCUs pour ce rédacteur ou lecteur. DocumentDB sans serveur adapte la capacité par incréments nécessaires pour fournir les meilleures performances pour les ressources consommées. La mise à l'échelle se fait par incréments aussi petits que 0,5 DCUs. 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 mise à l'échelle sans serveur de DocumentDB étant si fréquente, granulaire et non perturbatrice, elle ne provoque pas d'événements discrets dans le. AWS Management Console Au lieu de cela, vous pouvez mesurer les CloudWatch métriques Amazon telles que `serverlessDatabaseCapacity` et`DCUUtilization`, et suivre leurs valeurs minimales, maximales et moyennes au fil du temps. Pour en savoir plus sur la surveillance de DocumentDB sans serveur, consultez. [Surveillance d'Amazon DocumentDB sans serveur](docdb-serverless-monitoring.md)
L'augmentation ou la réduction d'échelle peut être causée par les facteurs suivants :
+ Utilisation de la mémoire
+ Utilisation de l’UC
+ Utilisation réseau
+ Utilisation du stockage
Vous pouvez surveiller ces causes de dimensionnement up/down sur les instances sans serveur DocumentDB. Pour de plus amples informations, veuillez consulter [Surveillance d'Amazon DocumentDB sans serveur](docdb-serverless-monitoring.md).
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 sans serveur DocumentDB, dans les niveaux de promotion 0 et 1, évoluent en même temps que le rédacteur. 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 respecte les valeurs DCU minimales et maximales 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 l'affichage et la modification des niveaux de promotion des instances sans serveur, consultez[Affichage et modification du niveau de promotion des lecteurs sans serveur](docdb-serverless-managing.md#docdb-serverless-promo-tier).
Le dimensionnement sans serveur DocumentDB peut se produire lorsque les connexions à la base de données sont ouvertes, lorsque les transactions sont en cours, etc. DocumentDB serverless n'attend pas un moment de calme pour commencer le dimensionnement. 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 ajouter plusieurs lecteurs sans serveur DocumentDB au cluster. Chaque lecteur sans serveur DocumentDB peut évoluer dans la plage des valeurs de capacité minimale et maximale que vous avez spécifiées pour votre cluster. 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.
La question de savoir si DocumentDB effectue le dimensionnement sans serveur et la rapidité avec laquelle le dimensionnement est effectué une fois qu'il démarre dépendent également des paramètres DCU 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 la configuration de dimensionnement, consultez[Configuration du dimensionnement sans serveur Amazon DocumentDB](docdb-serverless-scaling-config.md).
## État inactif (0,5 DCUs)
Lorsque les rédacteurs ou les lecteurs sans serveur Amazon DocumentDB sont inactifs, les instances sans serveur de DocumentDB prennent en charge la réduction jusqu'à un état d'inactivité de 0,5 DCUs si celui du cluster est configuré pour être de MinCapacity 0,5.
À l'état inactif, les instances sans serveur DocumentDB ne disposent pas d'une capacité de calcul CPU suffisante pour prendre en charge la plupart des charges de travail de production, mais sont prêtes à être rapidement mises à l'échelle pour prendre en charge une nouvelle charge de travail. Dans un état non inactif, les instances sans serveur DocumentDB nécessitent généralement au moins 1,0 à 2,5. DCUs Par conséquent, lorsque les instances sans serveur DocumentDB passent d'un état inactif à un état non inactif, elles passent directement à 1,0 à 2,5 DCUs (ou à la valeur de MaxCapacity si elle est inférieure).
Afin de permettre une réduction à 0,5 en DCUs cas d'inactivité, les limites d'instances sont plafonnées si elles MinCapacity sont configurées pour être inférieures ou égales à 1,0 DCUs. Pour plus d'informations sur la manière dont les limites sont affectées par la MinCapacity configuration, consultez[Limites des instances sans serveur Amazon DocumentDB](docdb-serverless-instance-limits.md).
# Exigences et limites de DocumentDB sans serveur
## Exigences relatives aux fonctionnalités
### Disponibilité dans les Régions
Le type d'instance sans serveur Amazon DocumentDB est disponible dans les régions suivantes :
La AWS CLI commande suivante peut être utilisée pour vérifier les options exactes d'instance sans serveur DocumentDB proposées dans une région donnée :
```
aws docdb describe-orderable-db-instance-options \
--region my_region \
--db-instance-class db.serverless \
--engine docdb
```
### Disponibilité des versions du moteur
DocumentDB serverless est uniquement pris en charge par la version 5.0.0 du moteur Amazon DocumentDB. Il n'est pas disponible sur les versions 3.6, 4.0 ou 8.0 du moteur.
**Note**
DocumentDB sans serveur n'est pris en charge que sur les nouvelles versions de correctif de la version 5.0.0. Assurez-vous que votre cluster est mis à jour avec une version récente du correctif moteur. Pour plus d'informations sur la gestion des clusters Amazon DocumentDB, consultez [Gestion d'Amazon DocumentDB](db-instance-maintain.md)
### Configuration du cluster
Avant d'ajouter des instances sans serveur Amazon DocumentDB à un cluster Amazon DocumentDB, les paramètres du cluster doivent également être définis. `ServerlessV2ScalingConfiguration` Cela définit la plage de capacité des instances sans serveur DocumentDB dans le cluster. Pour plus d'informations sur la configuration de dimensionnement, consultez[Configuration du dimensionnement sans serveur Amazon DocumentDB](docdb-serverless-scaling-config.md).
### Paramètres de plage de capacité de mise à l'échelle minimale pour certaines fonctionnalités d'Amazon DocumentDB
Certaines fonctionnalités d'Amazon DocumentDB fonctionnent avec DocumentDB sans serveur, mais peuvent entraîner des problèmes si votre plage de capacité est inférieure à la quantité de mémoire requise pour ces fonctionnalités associées à 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 out-of-memory des erreurs.
Les fonctionnalités suivantes nécessitent une configuration d'une `MinCapacity` and/or `MaxCapacity` valeur supérieure pour un fonctionnement optimal :
+ Performance Insights
+ Clusters globaux (s'applique uniquement au cluster principal Région AWS)
+ Création d'instances sans serveur sur un cluster avec un volume de données important
Cela inclut la création d'instances sans serveur dans le cadre d'une restauration de cluster.
Pour obtenir des recommandations sur le réglage de la plage de capacité appropriée (si vous utilisez cette fonctionnalité), consultez[Choix de la plage de capacité de dimensionnement pour un cluster sans serveur DocumentDB](docdb-serverless-scaling-config.md#docdb-serverless-scaling-capacity-choosing). Pour obtenir des informations de dépannage si votre base de données rencontre out-of-memory des erreurs dues à une plage de capacités mal configurée, consultez[Éviter les out-of-memory erreurs](docdb-serverless-scaling-config.md#docdb-serverless-scaling-mem-errors).
# Création d'un cluster utilisant Amazon DocumentDB sans serveur
## Création d'un cluster sans serveur Amazon DocumentDB
Avec Amazon DocumentDB serverless, vos clusters sont interchangeables avec les clusters provisionnés. Vous pouvez avoir des clusters dans lesquels certaines instances utilisent le mode sans serveur et d'autres sont provisionnées.
Vérifiez que la région et la version du moteur souhaitées prennent en charge DocumentDB sans serveur. Consultez [Exigences et limites de DocumentDB sans serveur](docdb-serverless-limitations.md).
Pour créer un cluster Amazon DocumentDB dans lequel vous pouvez ajouter des instances sans serveur, suivez la même procédure que dans. [Création d'un cluster Amazon DocumentDB](db-cluster-create.md) La seule différence est que l'`ServerlessV2ScalingConfiguration`argument doit également être fourni.
L'`ServerlessV2ScalingConfiguration`argument indique la plage de capacité de dimensionnement de vos instances sans serveur DocumentDB. Il comprend les valeurs minimales et maximales des unités de capacité DocumentDB (DCU) qui s'appliquent à toutes les instances sans serveur DocumentDB du cluster :
+ La `MinCapacity` valeur indique la capacité de mise à l'échelle minimale.
+ La `MaxCapacity` valeur indique la capacité de mise à l'échelle maximale.
Pour plus d’informations sur le dimensionnement, consultez [Configuration du dimensionnement sans serveur Amazon DocumentDB](docdb-serverless-scaling-config.md).
------
#### [ Using the AWS Management Console ]
L'exemple AWS Management Console de configuration suivant montre comment créer un cluster sans serveur DocumentDB.
1. Connectez-vous à la console Amazon DocumentDB [AWS Management Console](https://console.aws.amazon.com/docdb/home?region=us-east-1)et ouvrez-la.
1. Dans le panneau de navigation, choisissez **Clusters**.
**Astuce**
Si vous ne voyez pas le volet de navigation sur le côté gauche de votre écran, choisissez l'icône de menu (![\[Hamburger menu icon with three horizontal lines.\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/docdb-menu-icon.png)) dans le coin supérieur gauche de la page.
Le tableau **Clusters** apparaît.
1. Choisissez **Créer**.
La page **Créer un cluster Amazon DocumentDB** s'affiche.
1. Sur la page Créer un cluster Amazon DocumentDB, dans la section **Type de cluster**, sélectionnez Cluster **basé sur une instance** (il s'agit de l'option par défaut).
1. Dans la section **Configuration du cluster** :
1. Pour **Identifiant du cluster**, entrez un nom unique, tel que**myserverlesscluster**. Notez que la console remplacera tous les noms de clusters en minuscules, quelle que soit la manière dont ils sont saisis.
1. Pour la **version Engine**, choisissez **5.0.0** (il s'agit de l'option par défaut).
1. Dans la section **Configuration du stockage en cluster**, choisissez **Amazon DocumentDB Standard** (il s'agit de l'option par défaut).
**Note**
L'autre option de cette catégorie est **Amazon DocumentDB** I/O-Optimized. Pour en savoir plus sur l'une ou l'autre option, voir [Configurations de stockage en cluster Amazon DocumentDB](db-cluster-storage-configs.md)
1. Dans la section **Configuration de l'instance** :
1. Pour **Classe d'instance de base de données**, choisissez **Sans serveur**.
1. Pour **Nombre d'instances de répliques régulières**, choisissez **3** (il s'agit de l'option par défaut).
1. Dans la section **Plage de capacité**, laissez les valeurs par défaut pour **Minimum DCUs** et **Maximum DCUs**. Pour plus d'informations sur le réglage de ces paramètres, reportez-vous à[Limites des instances sans serveur Amazon DocumentDB](docdb-serverless-instance-limits.md).
![\[Formulaire de configuration pour un cluster de base de données sans serveur avec des champs pour la classe d'instance, les instances de réplication et la plage de capacité.\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/instance-config-serverless.png)
1. Dans la section **Connectivité**, laissez le paramètre par défaut **Ne pas se connecter à une ressource de calcul EC2**.
1. Dans la section **Authentification**, entrez un nom d'utilisateur pour l'utilisateur principal, puis choisissez **Autogéré**. Saisissez un mot de passe, puis confirmez-le.
Si vous avez plutôt choisi **Managed in AWS Secrets Manager**, consultez [Gestion des mots de passe avec Amazon DocumentDB et AWS Secrets Manager](docdb-secrets-manager.md) pour plus d'informations.
1. Conservez toutes les autres options par défaut et choisissez **Create cluster**.
------
#### [ Using the AWS CLI ]
Dans l'exemple suivant, remplacez chacun *user input placeholder* par vos propres informations ou paramètres de configuration.
Pour créer un cluster compatible avec les instances sans serveur DocumentDB à l'aide du AWS CLI, voir. [Création d'un cluster à l'aide du AWS CLI](db-cluster-create.md#db-cluster-create-cli)
Incluez les paramètres supplémentaires suivants dans votre `create-db-cluster` commande :
```
--serverless-v2-scaling-configuration
MinCapacity=minimum_capacity,MaxCapacity=maximum_capacity
```
Exemple :
```
aws docdb create-db-cluster \
--db-cluster-identifier sample-cluster \
--engine docdb \
--engine-version 5.0.0 \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 \
--master-username user-name \
--master-user-password password
```
------
## Ajouter une instance sans serveur Amazon DocumentDB
Pour ajouter une instance sans serveur DocumentDB, suivez la même procédure dans[Ajouter une instance Amazon DocumentDB à un cluster](db-instance-add.md), en veillant à spécifier db.serverless comme classe d'instance.
### Ajout d'une instance sans serveur à l'aide du AWS Management Console.
Pour ajouter une instance sans serveur DocumentDB à l'aide de la console, consultez [Ajouter une instance Amazon DocumentDB à un cluster](db-instance-add.md) et choisissez l'onglet **Utilisation** de l'onglet. AWS Management Console
### Ajouter une instance sans serveur à l'aide du AWS CLI
Pour ajouter une instance sans serveur DocumentDB à l'aide de AWS CLI, consultez [Ajouter une instance Amazon DocumentDB à un cluster](db-instance-add.md) et choisissez l'onglet **Utilisation** de l'onglet. AWS CLI
Utilisez l'argument CLI de classe d'instance suivant :
```
--db-instance-class db.serverless
```
Exemple :
```
aws docdb create-db-instance \
--db-cluster-identifier sample-cluster \
--db-instance-identifier sample-instance \
--db-instance-class db.serverless \
--engine docdb
```
# Migration vers Amazon DocumentDB sans serveur
**Topics**
+ [Migration de clusters DocumentDB existants vers des clusters sans serveur](#w2aac41c19b5)
+ [Migration de MongoDB vers DocumentDB sans serveur](#w2aac41c19b7)
## Migration de clusters DocumentDB existants vers des clusters sans serveur
### Mise à niveau de la version du moteur d'un cluster
Si votre cluster provisionné exécute une version inférieure du moteur qui ne prend pas en charge DocumentDB sans serveur, vous devez d'abord mettre à niveau le cluster vers une version de moteur prise en charge. Pour de plus amples informations, veuillez consulter [Mise à niveau sur place de la version majeure d'Amazon DocumentDB](docdb-mvu.md).
### Migration d'un cluster provisionné vers DocumentDB sans serveur
Pour changer un cluster provisionné afin d'utiliser DocumentDB sans serveur, procédez comme suit :
1. Vérifiez si la version du moteur du cluster provisionné doit être mise à niveau pour être utilisée avec DocumentDB sans serveur. Consultez [Exigences et limites de DocumentDB sans serveur](docdb-serverless-limitations.md).
**Note**
Si le cluster provisionné exécute une version du moteur qui n'est pas disponible pour DocumentDB sans serveur, mettez à niveau la version du moteur du cluster. Consultez [Mise à niveau sur place de la version majeure d'Amazon DocumentDB](docdb-mvu.md).
1. Définissez la configuration de mise à l’échelle du cluster. Pour plus de détails sur le choix de la configuration de dimensionnement, consultez[Choix de la plage de capacité de dimensionnement pour un cluster sans serveur DocumentDB](docdb-serverless-scaling-config.md#docdb-serverless-scaling-capacity-choosing). Pour modifier la configuration de dimensionnement d'un cluster, consultez[Affichage et modification de la configuration de la plage de capacités d'évolutivité d'un cluster](docdb-serverless-managing.md#docdb-serverless-range-config).
1. Configurez toutes les autres propriétés du cluster pour tenir compte des exigences et des limites de DocumentDB sans serveur issues de. [Exigences et limites de DocumentDB sans serveur](docdb-serverless-limitations.md)
1. Ajoutez une ou plusieurs instances sans serveur DocumentDB au cluster. Suivez la procédure décrite dans [Ajouter une instance sans serveur Amazon DocumentDB](docdb-serverless-create-cluster.md#docdb-serverless-adding-instance).
**Note**
Dans certains cas, il se peut que vous disposiez déjà d'une ou de plusieurs instances de lecteur provisionnées dans le cluster. Dans ce cas, vous pouvez choisir de convertir l'un des lecteurs en une instance sans serveur DocumentDB au lieu de créer une nouvelle instance. Pour ce faire, suivez la procédure décrite dans [Modification de la classe d'une instance](db-instance-classes.md#db-instance-class-changing).
1. (Facultatif) Effectuez une opération de basculement pour faire d'une instance de DocumentDB sans serveur le rédacteur du cluster. Consultez [Basculement d'Amazon DocumentDB](failover.md).
1. (Facultatif) Convertissez toutes les instances Amazon DocumentDB provisionnées restantes en instances sans serveur DocumentDB ([Modification de la classe d'une instance](db-instance-classes.md#db-instance-class-changing)voir) ou supprimez-les du cluster (voir). [Suppression d'une instance Amazon DocumentDB](db-instance-delete.md)
------
#### [ Using the AWS Management Console ]
L'exemple de AWS Management Console configuration suivant montre le processus de migration à l'aide d'un cluster provisionné Amazon DocumentDB qui exécute Amazon DocumentDB 5.0.0, qui ne nécessite pas de mise à niveau de la version du moteur pour commencer à utiliser DocumentDB sans serveur. Le cluster est nommé `sample` et commence par trois instances provisionnées nommées `sample``sample2`, et`sample3`. Dans cet exemple, ces trois instances seront remplacées par trois instances sans serveur.
1. Connectez-vous à la console Amazon DocumentDB [AWS Management Console](https://console.aws.amazon.com/docdb/home?region=us-east-1)et ouvrez-la.
1. Dans le panneau de navigation, choisissez **Clusters**.
**Astuce**
Si vous ne voyez pas le volet de navigation sur le côté gauche de votre écran, choisissez l'icône de menu (![\[Hamburger menu icon with three horizontal lines.\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/docdb-menu-icon.png)) dans le coin supérieur gauche de la page.
Le tableau **Clusters** apparaît.
1. Dans le tableau **Clusters**, cochez la case du cluster auquel vous souhaitez ajouter une instance sans serveur.
1. Choisissez **Actions**, puis **Add instances (Ajouter des instances)**.
1. Dans la boîte de dialogue **Ajouter des instances**, sélectionnez **Serverless** dans la section de **classe d'instance** de base de données pour chaque nouvelle instance sans serveur que vous souhaitez créer.
1. Pour les **paramètres de capacité sans serveur**, définissez la configuration de dimensionnement en fonction de la description de la capacité dans la boîte de dialogue.
1. (Facultatif) Pour ajouter une autre instance, choisissez **Ajouter une instance**. Continuez à ajouter des instances jusqu'à ce que vous ayez atteint le nombre de nouvelles instances souhaité.
Dans cet exemple, trois nouvelles instances sans serveur sont créées.
1. Choisissez **Créer**.
La création d'une instance prend quelques minutes. Vous pouvez utiliser la console ou le AWS CLI pour consulter le statut de l'instance. Pour plus d'informations, consultez [Surveillance de l'état d'un cluster Amazon DocumentDB](https://docs.aws.amazon.com//documentdb/latest/developerguide/monitoring_docdb-cluster_status.html).
1. Pour revenir au tableau **Clusters**, cochez les cases des trois instances provisionnées d'origine.
1. Choisissez **Actions**, puis **Supprimer**.
Lors de la suppression, un basculement est automatiquement effectué pour promouvoir l'une des instances restantes en tant que rédactrice. Après quelques minutes, le processus de suppression est terminé. Le cluster existant contient désormais trois instances sans serveur DocumentDB (telles que définies dans la colonne **Taille**).
------
#### [ Using the AWS CLI ]
L'exemple de AWS CLI configuration suivant montre le processus de migration à l'aide d'un cluster provisionné Amazon DocumentDB qui exécute Amazon DocumentDB 5.0.0, qui ne nécessite pas de mise à niveau de la version du moteur pour commencer à utiliser DocumentDB sans serveur. Le cluster est nommé `sample` et commence par trois instances provisionnées nommées `sample``sample2`, et`sample3`. Dans cet exemple, ces trois instances seront remplacées par trois instances sans serveur. Le cluster est nommé `sample-cluster` et commence par deux instances provisionnées nommées `sample-provisioned-instance-1` et une instance `sample-provisioned-instance-2` d'écriture et une instance de lecteur.
Dans l'exemple suivant, remplacez chacun *user input placeholder* par vos propres informations ou paramètres de configuration.
Utilisez cette `aws docdb describe-db-clusters` opération pour déterminer l'état d'un cluster. Le code suivant trouve l'état du cluster `sample-cluster` et affiche les résultats dans un tableau :
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].DBClusterMembers' \
--output table
```
```
--------------------------------------------------------------------------------------------------------
| DescribeDBClusters |
+--------------------------------+---------------------------------+------------------+----------------+
| DBClusterParameterGroupStatus | DBInstanceIdentifier | IsClusterWriter | PromotionTier |
+--------------------------------+---------------------------------+------------------+----------------+
| in-sync | sample-provisioned-instance-2 | False | 1 |
| in-sync | sample-provisioned-instance-1 | True | 1 |
+--------------------------------+---------------------------------+------------------+----------------+
```
Ajoutez la configuration de dimensionnement pour le cluster :
```
aws docdb modify-db-cluster \
--db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16
```
Ajoutez les instances sans serveur. Dans cet exemple, les nouvelles instances sans serveur `sample-serverless-instance-2` sont nommées `sample-serverless-instance-1` et ajoutées :
```
aws docdb create-db-instance \
--db-cluster-identifier sample-cluster \
--db-instance-identifier sample-serverless-instance-1 \
--db-instance-class db.serverless \
--engine docdb
aws docdb create-db-instance \
--db-cluster-identifier sample-cluster \
--db-instance-identifier sample-serverless-instance-2 \
--db-instance-class db.serverless \
--engine docdb
```
Entrez ce qui suit pour attendre que les instances sans serveur soient disponibles avant de continuer :
```
aws docdb wait db-instance-available \
--db-instance-identifier sample-serverless-instance-1
aws docdb wait db-instance-available \
--db-instance-identifier sample-serverless-instance-2
```
Effectuez un basculement pour faire de la nouvelle `sample-serverless-instance-1` instance le rédacteur du cluster :
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster \
--target-db-instance-identifier sample-serverless-instance-1
```
Le basculement prend quelques secondes, après quoi sample-serverless-instance -1 devient le rédacteur du cluster. Vérifiez cela à l'aide des données suivantes :
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].DBClusterMembers' \
--output table
```
```
--------------------------------------------------------------------------------------------------------
| DescribeDBClusters |
+--------------------------------+---------------------------------+------------------+----------------+
| DBClusterParameterGroupStatus | DBInstanceIdentifier | IsClusterWriter | PromotionTier |
+--------------------------------+---------------------------------+------------------+----------------+
| in-sync | sample-provisioned-instance-2 | False | 1 |
| in-sync | sample-provisioned-instance-1 | False | 1 |
| in-sync | sample-serverless-instance-2 | False | 1 |
| in-sync | sample-serverless-instance-1 | True | 1 |
+--------------------------------+---------------------------------+------------------+----------------+
```
Enfin, supprimez les instances provisionnées d'origine :
```
aws docdb delete-db-instance \
--db-instance-identifier sample-provisioned-instance-1
aws docdb delete-db-instance \
--db-instance-identifier sample-provisioned-instance-2
```
------
## Migration de MongoDB vers DocumentDB sans serveur
Vous pouvez migrer vos bases de données MongoDB vers DocumentDB sans serveur, comme avec Amazon DocumentDB provisionné. Pour de plus amples informations, veuillez consulter [Migration vers Amazon DocumentDB](docdb-migration.md).
# Gestion d'Amazon DocumentDB sans serveur
## Affichage et modification de la configuration de la plage de capacités d'évolutivité d'un cluster
L'`ServerlessV2ScalingConfiguration`argument indique la plage de capacité de dimensionnement de vos instances sans serveur DocumentDB. Il comprend les valeurs minimales et maximales des unités de capacité DocumentDB (DCU) qui s'appliquent à toutes les instances sans serveur DocumentDB du cluster.
+ **`MinCapacity`**— La capacité de mise à l'échelle minimale de toutes les instances sans serveur DocumentDB du cluster.
+ **`MaxCapacity`**— La capacité de mise à l'échelle maximale de toutes les instances sans serveur DocumentDB du cluster.
**Note**
Les modifications de configuration de dimensionnement suivantes nécessitent un redémarrage de l'instance pour refléter les nouvelles `MaxCapacity` valeurs `MinCapacity` et :
Toute modification de la `MaxCapacity` valeur
Modification de la `MinCapacity` valeur à 1,0 ou inférieure à partir d'une valeur supérieure
Modification de la `MinCapacity` valeur à une valeur supérieure à 1,0 à partir d'une valeur inférieure
Pour plus d'informations sur la configuration de dimensionnement et sur la manière de sélectionner les limites de capacité de dimensionnement appropriées, consultez[Configuration du dimensionnement sans serveur Amazon DocumentDB](docdb-serverless-scaling-config.md).
------
#### [ Using the AWS Management Console ]
L'exemple AWS Management Console de configuration suivant montre comment afficher et modifier les paramètres de configuration de dimensionnement d'un cluster sans serveur DocumentDB.
1. Connectez-vous à la console Amazon DocumentDB [AWS Management Console](https://console.aws.amazon.com/docdb/home?region=us-east-1)et ouvrez-la.
1. Dans le panneau de navigation, choisissez **Clusters**.
**Astuce**
Si vous ne voyez pas le volet de navigation sur le côté gauche de votre écran, choisissez l'icône de menu (![\[Hamburger menu icon with three horizontal lines.\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/docdb-menu-icon.png)) dans le coin supérieur gauche de la page.
Le tableau **Clusters** apparaît.
1. Dans le tableau **Clusters**, cochez la case du cluster dont vous souhaitez modifier la capacité de dimensionnement.
1. Choisissez **Actions**, puis **Modify (Modifier)**.
La boîte de dialogue **Modifier le cluster** apparaît.
1. Localisez la section des **paramètres de capacité sans serveur** et définissez la configuration de dimensionnement (**plage de capacités**) en fonction de la description de la capacité dans la boîte de dialogue.
Pour plus d'informations sur le dimensionnement et les plages de capacité, consultez[Configuration du dimensionnement sans serveur Amazon DocumentDB](docdb-serverless-scaling-config.md).
1. Choisissez **Continuer**.
1. Pour **Scheduling of Modifications (Planification des modifications)**, choisissez **Appliquer immédiatement**.
1. Choisissez **Modifier le cluster**.
1. Une fois la modification terminée, chaque instance sans serveur doit être redémarrée. Pour minimiser l'indisponibilité de l'enregistreur, effectuez la séquence d'opérations suivante :
1. Redémarrez chaque instance de lecteur sans serveur.
1. Sélectionnez l'instance du lecteur, choisissez **Actions**, puis **Redémarrer**.
1. Attendez que le statut de l'instance revienne à **Disponible**.
1. Effectuez un basculement vers une instance sans serveur redémarrée.
1. Sélectionnez le cluster, choisissez **Actions**, puis **Failover**.
1. Attendez que l'opération de basculement soit terminée.
1. Redémarrez l'instance sans serveur restante.
1. Sélectionnez l'instance restante, choisissez **Actions**, puis **Redémarrer**.
1. Attendez que le statut de l'instance revienne à **Disponible**.
------
#### [ Using the AWS CLI ]
L'exemple AWS CLI de configuration suivant montre la configuration de dimensionnement actuelle.
Dans l'exemple suivant, remplacez chacun *user input placeholder* par vos propres informations ou paramètres de configuration.
La configuration de dimensionnement actuelle du cluster peut être visualisée à l'aide de la `describe-db-clusters` AWS CLI commande :
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[0].ServerlessV2ScalingConfiguration'
```
Voici la sortie de cette commande :
```
{
"MinCapacity": 0.5,
"MaxCapacity": 16.0
}
```
La configuration de dimensionnement du cluster peut être modifiée à l'aide de la `modify-db-cluster` commande :
```
aws docdb modify-db-cluster \
--db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=32
```
Une fois l'opération terminée, chaque instance sans serveur doit être redémarrée. Pour minimiser l'indisponibilité de l'enregistreur, nous pouvons effectuer la séquence d'opérations suivante :
```
aws docdb reboot-db-instance \
--db-instance-identifier sample-serverless-instance-reader
aws docdb wait db-instance-available \
--db-instance-identifier sample-serverless-instance-reader
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster \
--target-db-instance-identifier sample-serverless-instance-reader
aws docdb reboot-db-instance \
--db-instance-identifier sample-serverless-instance-writer
aws docdb wait db-instance-available \
--db-instance-identifier sample-serverless-instance-writer
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster \
--target-db-instance-identifier sample-serverless-instance-writer
```
------
## Affichage et modification du niveau de promotion des lecteurs sans serveur
Pour les clusters contenant plusieurs instances sans serveur DocumentDB ou un mélange d'instances provisionnées et sans serveur, faites attention au paramètre du niveau de promotion pour chaque instance sans serveur. Ce paramètre contrôle davantage le comportement des instances sans serveur que des instances provisionnées.
Pour les instances provisionnées, le choix du niveau 0 à 15 détermine uniquement l'ordre dans lequel Amazon DocumentDB choisit l'instance de lecteur à promouvoir auprès du rédacteur lors d'une opération de basculement. Toutefois, pour les instances sans serveur, le numéro de niveau détermine également si l'instance augmente pour correspondre à la capacité de l'instance de rédaction ou si elle évolue indépendamment en fonction de sa propre charge de travail. Les instances de lecteur sans serveur de niveau 0 ou 1 sont maintenues à une capacité minimale au moins égale à celle de l'instance d'écriture. Ils sont ainsi prêts à prendre le relais de l'instance du rédacteur en cas de basculement. Si l'instance de rédaction est une instance provisionnée, Amazon DocumentDB estime la capacité sans serveur équivalente de DocumentDB. Il utilise cette estimation comme capacité minimale pour l'instance de lecteur sans serveur.
Les instances de lecteur sans serveur DocumentDB 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é DocumentDB (DCU) spécifiée dans la plage de capacité du cluster.
------
#### [ Using the AWS Management Console ]
L'exemple AWS Management Console de configuration suivant montre comment afficher et modifier les paramètres du niveau promotionnel d'un lecteur d'instance sans serveur DocumentDB.
1. Connectez-vous à la console Amazon DocumentDB [AWS Management Console](https://console.aws.amazon.com/docdb/home?region=us-east-1)et ouvrez-la.
Les niveaux de promotion de chaque instance sont affichés dans la colonne **Niveau de promotion** du AWS Management Console.
1. Dans le panneau de navigation, choisissez **Clusters**.
**Astuce**
Si vous ne voyez pas le volet de navigation sur le côté gauche de votre écran, choisissez l'icône de menu (![\[Hamburger menu icon with three horizontal lines.\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/docdb-menu-icon.png)) dans le coin supérieur gauche de la page.
Le tableau **Clusters** apparaît.
1. Dans le tableau **Clusters**, cochez la case de l'instance pour laquelle vous souhaitez modifier le niveau de promotion.
1. Choisissez **Actions**, puis **Modify (Modifier)**.
La boîte de dialogue **Modifier l'instance** apparaît.
1. Localisez la section **Failover** et réglez le **niveau de promotion** au niveau souhaité.
1. Choisissez **Continuer**.
1. Pour **Scheduling of Modifications (Planification des modifications)**, choisissez **Appliquer immédiatement**.
1. Choisissez **Modify instance** (Modifier l’instance).
------
#### [ Using the AWS CLI ]
L'exemple AWS CLI de configuration suivant montre la configuration de dimensionnement actuelle.
Dans l'exemple suivant, remplacez chacun *user input placeholder* par vos propres informations ou paramètres de configuration.
Les niveaux de promotion de toutes les instances d'un cluster peuvent être consultés à l'aide de la `describe-db-clusters` AWS CLI commande :
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[0].DBClusterMembers' \
--output table
```
Voici la sortie de cette commande :
```
--------------------------------------------------------------------------------------------------------
| DescribeDBClusters |
+--------------------------------+---------------------------------+------------------+----------------+
| DBClusterParameterGroupStatus | DBInstanceIdentifier | IsClusterWriter | PromotionTier |
+--------------------------------+---------------------------------+------------------+----------------+
| in-sync | sample-serverless-instance-2 | False | 1 |
| in-sync | sample-serverless-instance-1 | True | 1 |
+--------------------------------+---------------------------------+------------------+----------------+
```
Le niveau de promotion d'une instance spécifique peut être modifié à l'aide de la `modify-db-instance` commande :
```
aws docdb modify-db-instance \
--db-instance-identifier sample-serverless-instance-2 \
--promotion-tier 3
```
------
# Limites des instances sans serveur Amazon DocumentDB
Pour les instances sans serveur DocumentDB, les limites suivantes par instance dépendent de la capacité de dimensionnement actuelle de l'instance :
+ Mémoire d'instance (GiB)
+ Connexions (toutes)
+ Limite du curseur
+ Transactions ouvertes
+ Connexions (actives)
Les tableaux suivants décrivent comment les limites par instance des instances sans serveur évoluent par rapport à la capacité de dimensionnement actuelle de l'instance.
Notez que les valeurs limites sont différentes selon que la configuration de `MinCapacity` dimensionnement du cluster a été définie sur une valeur supérieure à deux (2). Si la valeur `MinCapacity` est inférieure ou égale à 2, les valeurs limites pour le curseur, les transactions ouvertes et les connexions (actives) sont plafonnées à une valeur maximale inférieure. (La raison technique du plafond est de permettre le passage à un état « inactif ». Pour de plus amples informations, veuillez consulter [État inactif (0,5 DCUs)](docdb-serverless-how-it-works.md#docdb-serverlerss-idle-state).
**limites d'instance db.serverless si ≤1 MinCapacity **
| Capacité actuelle (DCU) | Mémoire d'instance (GiB) | Connexions (toutes) | Limite du curseur | Transactions ouvertes | Connexions (actives) |
| --- | --- | --- | --- | --- | --- |
| 0.5 | 1 | 250 | 6 | 12 | 39 |
| 1 | 2 | 500 | 12 | 24 | 79 |
| 2 | 4 | 1 000 | 24 | 48 | 173 |
| 4 | 8 | 2000 | 48 | 96 | 416 |
| 8 | 16 | 4000 | 96 | 192 | 1071 |
| 16 | 32 | 8000 | 132 | 264 | 1550 |
| 32 | 64 | 16000 | 132 | 264 | 1550 |
| 64 | 128 | 32000 | 132 | 264 | 1550 |
| 128 | 256 | 60000 | 132 | 264 | 1550 |
| 256 | 512 | 60000 | 132 | 264 | 1550 |
**limites d'instance db.serverless si >1 MinCapacity **
| Capacité actuelle (DCU) | Mémoire d'instance (GiB) | Connexions (toutes) | Limite du curseur | Transactions ouvertes | Connexions (actives) |
| --- | --- | --- | --- | --- | --- |
| 1.5 | 3 | 7250 | 18 | 36 | 124 |
| 2 | 4 | 1 000 | 24 | 48 | 173 |
| 4 | 8 | 2000 | 48 | 96 | 416 |
| 8 | 16 | 4000 | 96 | 192 | 1071 |
| 16 | 32 | 8000 | 192 | 384 | 2709 |
| 32 | 64 | 16000 | 384 | 768 | 4500 |
| 64 | 128 | 32000 | 768 | 1536 | 4500 |
| 128 | 256 | 60000 | 1536 | 3072 | 4500 |
| 256 | 512 | 60000 | 3072 | 6144 | 4500 |
Vous pouvez surveiller et déclencher une alarme sur les limites par instance à l'aide CloudWatch des métriques suivantes. Pour en savoir plus sur les CloudWatch métriques Amazon DocumentDB, consultez. [Surveillance d'Amazon DocumentDB avec CloudWatch](cloud_watch.md)
| Ressource | CloudWatch métrique limite | CloudWatch métrique d'utilisation (1 min maximum) | CloudWatch métrique d'utilisation |
| --- | --- | --- | --- |
| Mémoire d'instance | - | - | FreeableMemory |
| Connexions (toutes) | DatabaseConnectionsLimit | DatabaseConnectionsMax | DatabaseConnections |
| Curseurs | DatabaseCursorsLimit | DatabaseCursorsMax | DatabaseCursors |
| Transactions | TransactionsOpenLimit | TransactionsOpenMax | TransactionsOpen |
# Configuration du dimensionnement sans serveur Amazon DocumentDB
**Topics**
+ [Choix de la plage de capacité de dimensionnement pour un cluster sans serveur DocumentDB](#docdb-serverless-scaling-capacity-choosing)
+ [Choix du `MinCapacity` paramètre pour un cluster sans serveur DocumentDB](#docdb-serverless-scaling-mincapacity-choosing)
+ [Choix du `MaxCapacity` paramètre pour un cluster sans serveur DocumentDB](#docdb-serverless-scaling-maxcapacity-choosing)
+ [Éviter les out-of-memory erreurs](#docdb-serverless-scaling-mem-errors)
+ [Pourquoi mon instance sans serveur n'est-elle pas réduite ?](#docdb-serverless-scaling-down)
## Choix de la plage de capacité de dimensionnement pour un cluster sans serveur DocumentDB
Avant d'ajouter des instances sans serveur DocumentDB à un cluster Amazon DocumentDB, les paramètres du cluster doivent également être définis. `ServerlessV2ScalingConfiguration`
Le `ServerlessV2ScalingConfiguration` paramètre se compose de deux valeurs qui définissent la plage de capacité de dimensionnement sans serveur de toute instance sans serveur du cluster :
+ **`MinCapacity`**— La capacité de mise à l'échelle minimale de toutes les instances sans serveur DocumentDB du cluster.
+ **`MaxCapacity`**— La capacité de mise à l'échelle maximale de toutes les instances sans serveur DocumentDB du cluster.
## Choix du `MinCapacity` paramètre pour un cluster sans serveur DocumentDB
Il est tentant de toujours choisir 0,5 pour`MinCapacity`. Cette valeur permet à l'instance de réduire sa capacité au minimum lorsqu'elle est complètement inactive, tout en restant active. Toutefois, selon la façon dont vous utilisez ce cluster et les autres paramètres que vous configurez, une autre capacité minimale peut s’avérer plus efficace. Tenez compte des facteurs suivants lors du choix de la valeur minimale de capacité :
+ Le taux de dimensionnement d'une instance sans serveur DocumentDB dépend de sa capacité actuelle. Plus sa capacité actuelle est élevée, plus son augmentation d’échelle est rapide. Si vous avez besoin que l'instance atteigne rapidement une capacité très élevée, pensez à définir la capacité minimale à une valeur correspondant au taux de mise à l'échelle correspondant à vos besoins.
+ Si vous modifiez généralement la classe d'instance de vos instances en prévision d'une charge de travail particulièrement élevée ou faible, vous pouvez utiliser cette expérience pour faire une estimation approximative de la plage de capacité équivalente sans serveur de DocumentDB. Pour déterminer la taille de mémoire d'un type d'instance Amazon DocumentDB provisionné, consultez. [Limites d’instance](limits.md#limits.instance)
Supposons, par exemple, que vous utilisiez la classe d'`db.r6g.xlarge`instance lorsque la charge de travail de votre cluster est faible. Cette classe d'instance dispose de 32 GiB de mémoire. Ainsi, vous pouvez spécifier une valeur `MinCapacity` de 16 pour configurer une instance sans serveur qui peut être réduite à peu près à la même capacité. En effet, chaque DCU correspond à environ 2 GiB de mémoire. Vous pouvez spécifier une valeur légèrement inférieure pour réduire davantage l'instance au cas où votre `db.r6g.xlarge` instance serait parfois sous-utilisée.
+ Si votre application fonctionne de manière optimale lorsque les instances ont une certaine quantité de données dans le cache tampon, pensez à spécifier un paramètre DCU minimum dans lequel la mémoire est suffisamment grande pour contenir les données fréquemment consultées. Dans le cas contraire, certaines données sont expulsées du cache tampon lorsque les instances sans serveur réduisent leur taille de mémoire. Ensuite, lorsque les instances redimensionnent, les informations sont relues dans le cache tampon au fil du temps. Si la quantité de données I/O à remettre dans le cache tampon est importante, il peut être plus efficace de choisir une valeur DCU minimale plus élevée. Pour de plus amples informations, veuillez consulter [Dimensionnement des instances](best_practices.md#best_practices-instance_sizing).
+ Si vos instances DocumentDB sans serveur s'exécutent la plupart du temps à une capacité particulière, pensez à spécifier un paramètre de capacité minimale inférieur à cette ligne de base, mais pas trop bas. Les instances sans serveur peuvent estimer le plus efficacement la quantité et la rapidité de mise à l'échelle lorsque la capacité actuelle n'est pas nettement inférieure à la capacité requise.
+ Si les besoins en mémoire de votre charge de travail provisionnée sont trop élevés pour les petites classes d'instances telles que T3 ou T4g, choisissez un paramètre DCU minimum fournissant une mémoire comparable à celle d'une instance R5 ou R6g.
+ En particulier, nous recommandons le minimum suivant `MinCapacity` pour une utilisation avec les fonctionnalités spécifiées (ces recommandations sont sujettes à modification) :
+ Informations sur les Performances — 2 DCUs
+ Clusters mondiaux — 8 DCUs (s'applique uniquement au cluster principal Région AWS)
+ Dans Amazon DocumentDB, la réplication s'effectue au niveau de la couche de stockage, de sorte que la capacité du lecteur n'affecte pas directement la réplication. Toutefois, pour les instances de lecteur sans serveur DocumentDB qui évoluent indépendamment, assurez-vous que la capacité minimale est suffisante pour gérer les charges de travail pendant les périodes d'écriture intensive afin d'éviter la latence des requêtes. Si les instances de lecteur des niveaux de promotion 2 à 15 rencontrent des problèmes de performances, envisagez d'augmenter la capacité minimale du cluster. Pour plus de détails sur la modification de l'évolutivité des instances du lecteur en fonction du rédacteur ou indépendamment, voir[Affichage et modification du niveau de promotion des lecteurs sans serveur](docdb-serverless-managing.md#docdb-serverless-promo-tier).
Si vous avez un cluster avec des instances de lecteur sans serveur DocumentDB, les lecteurs ne s'adaptent pas à l'instance de rédacteur lorsque le niveau de promotion des lecteurs n'est pas 0 ou 1. Dans ce cas, la définition d’une valeur minimale de capacité faible peut entraîner un retard de réplication excessif. En effet, la capacité des lecteurs peut ne pas être suffisante pour appliquer les modifications depuis l’enregistreur lorsque la base de données est occupée. Nous vous recommandons de définir la capacité minimale sur une valeur représentant une quantité de mémoire et de processeur comparable à celle de l'instance d'écriture.
+ Le temps nécessaire à une instance sans serveur DocumentDB pour passer de sa capacité minimale à sa capacité maximale dépend de la différence entre ses valeurs DCU minimale et maximale. Lorsque la capacité actuelle de l'instance est importante, DocumentDB sans serveur augmente par incréments plus importants que lorsque l'instance démarre à partir d'une faible capacité. Ainsi, si vous spécifiez une capacité maximale relativement élevée et que l'instance passe le plus clair de son temps à proximité de cette capacité, envisagez d'augmenter le paramètre DCU minimum. Ainsi, une instance inactive peut revenir à sa capacité maximale plus rapidement.
+ Certaines limites d'instance sont déterminées par la capacité actuelle de l'instance sans serveur, comme la limite de connexions, la limite de curseur et la limite de transactions ouvertes. Si la capacité actuelle de l'instance est faible, les limites seront également faibles en conséquence. Si ces limites posent problème lorsque votre instance sans serveur est réduite à sa `MinCapacity` valeur, envisagez de passer `MinCapacity` à une valeur supérieure. Pour de plus amples informations, veuillez consulter [Limites des instances sans serveur Amazon DocumentDB](docdb-serverless-instance-limits.md).
+ En outre, certaines limites d'instance sont plafonnées à une valeur maximale inférieure si elle `MinCapacity` est définie sur une valeur inférieure ou égale à 1,0 DCUs, comme la limite de connexions actives, la limite de curseur et la limite de transactions ouvertes. Si ces limites plafonnées ne sont pas suffisantes pour votre charge de travail, veuillez utiliser une `MinCapacity` valeur d'au moins 1,5 DCUs. Pour de plus amples informations, veuillez consulter [Limites des instances sans serveur Amazon DocumentDB](docdb-serverless-instance-limits.md).
Pour obtenir des instructions sur la façon de modifier la configuration de dimensionnement d'un cluster, consultez[Gestion d'Amazon DocumentDB sans serveur](docdb-serverless-managing.md).
## Choix du `MaxCapacity` paramètre pour un cluster sans serveur DocumentDB
Il est tentant de toujours choisir une valeur élevée pour le paramètre de capacité maximale sans serveur de DocumentDB. Une capacité maximale élevée permet à l'instance d'augmenter au maximum lorsqu'elle exécute une charge de travail intensive. Une valeur faible évite la possibilité de frais inattendus. Selon votre utilisation de ce cluster et des autres paramètres que vous configurez, la valeur la plus efficace peut être supérieure ou inférieure à celle à laquelle vous pensiez initialement. Tenez compte des facteurs suivants lors du choix de la valeur maximale de capacité :
+ La capacité maximale doit être au moins aussi élevée que la capacité minimale. Vous pouvez définir la capacité minimale et la capacité maximale pour qu’elles soient identiques. Cependant, dans ce cas, la capacité ne fait jamais l’objet d’une augmentation ou d’une réduction d’échelle. Par conséquent, l’utilisation de valeurs identiques pour les capacités minimale et maximale n’est pas appropriée en dehors des situations de test.
+ La capacité maximale doit être d'au moins 1,0 DCUs et d'au plus 256 DCUs.
+ Nous vous recommandons de surveiller le dimensionnement et l'utilisation des ressources de vos instances sans serveur. Si votre instance sans serveur évolue fréquemment pour atteindre sa capacité maximale et se heurte à des contraintes de ressources (par exemple lorsque la `DCUUtilization` métrique est de 100,0), nous vous recommandons de sélectionner une valeur plus élevée`MaxCapacity`. Pour de plus amples informations, veuillez consulter [Surveillance d'Amazon DocumentDB sans serveur](docdb-serverless-monitoring.md).
+ Si vous modifiez généralement la classe d'instance de vos instances provisionnées en prévision d'une charge de travail particulièrement élevée ou faible, vous pouvez utiliser cette expérience pour estimer la plage de capacité équivalente sans serveur de DocumentDB. Pour déterminer la taille de mémoire des instances Amazon DocumentDB provisionnées, consultez. [Limites d’instance](limits.md#limits.instance)
Supposons, par exemple, que vous utilisiez la classe d'`db.r6g.4xlarge`instance lorsque la charge de travail de votre cluster est élevée. Cette classe d'instance dispose de 128 GiB de mémoire. Ainsi, vous pouvez spécifier un paramètre DCU maximal de 64 pour configurer une instance sans serveur pouvant atteindre approximativement la même capacité. En effet, chaque DCU correspond à environ 2 GiB de mémoire. Vous pouvez spécifier une valeur légèrement plus élevée pour permettre à l'instance de s'étendre davantage au cas où votre `db.r6g.4xlarge` instance ne disposerait pas de la capacité suffisante pour gérer efficacement la charge de travail.
+ Si votre budget limite l'utilisation de votre base de données, choisissez une valeur qui reste dans les limites de ce plafond, même si toutes vos instances sans serveur fonctionnent à leur capacité maximale en permanence. N'oubliez pas que lorsque vous avez n instances sans serveur dans votre cluster, la capacité maximale théorique sans serveur que le cluster peut consommer à tout moment est n fois le paramètre DCU maximal pour le cluster. (La quantité réelle consommée peut être inférieure, par exemple si certains lecteurs sont mis à l’échelle indépendamment de l’enregistreur.)
+ Si vous utilisez des instances de lecteur sans serveur pour décharger une partie de la charge de travail en lecture seule de l'instance de rédacteur, vous pouvez peut-être choisir un paramètre de capacité maximale inférieur. Vous procédez ainsi pour tenir compte du fait que chaque instance de lecteur n'a pas besoin d'être redimensionnée aussi haut que si le cluster ne contenait qu'une seule instance.
+ Supposons que vous souhaitiez vous protéger contre une utilisation excessive due à une mauvaise configuration des paramètres de base de données ou à l’inefficacité des requêtes de votre application. Dans ce cas, vous pouvez éviter une surutilisation accidentelle en choisissant une valeur maximale de capacité inférieure à la valeur absolue la plus élevée que vous pourriez définir.
+ Si les pics dus à l’activité réelle de l’utilisateur sont rares mais existent, vous pouvez les prendre en compte lorsque vous choisissez la valeur maximale de capacité. Si la priorité est que l’application continue de s’exécuter à des performances et une capacité de mise à l’échelle optimales, vous pouvez spécifier une valeur maximale de capacité supérieure à celle que vous constatez dans le cas d’une utilisation normale. S’il est admis que l’application s’exécute à un débit réduit pendant les pics d’activité très élevés, vous pouvez choisir une valeur maximale de capacité légèrement inférieure. Assurez-vous de choisir une valeur dont les ressources de mémoire et de processeur sont suffisantes pour maintenir l’application en cours d’exécution.
+ Si vous activez dans votre cluster des paramètres qui augmentent l'utilisation de la mémoire pour chaque instance, tenez compte de cette mémoire lorsque vous déterminez la valeur maximale du DCU. Ces paramètres incluent ceux relatifs à Performance Insights et aux clusters globaux. Assurez-vous que la valeur DCU maximale permet aux instances sans serveur d'augmenter suffisamment leur capacité pour gérer la charge de travail lorsque ces fonctionnalités sont utilisées. Pour plus d'informations sur la résolution des problèmes liés à la combinaison d'un paramètre DCU maximal faible et des fonctionnalités Amazon DocumentDB qui entraînent une surcharge de mémoire, [Éviter les out-of-memory erreurs](#docdb-serverless-scaling-mem-errors) consultez (ci-dessous).
+ En particulier, nous recommandons le minimum suivant `MaxCapacity` pour une utilisation avec les fonctionnalités spécifiées (ces recommandations sont sujettes à modification) :
+ Création d'instances sans serveur sur un cluster contenant un volume de données important : 2 DCUs (cela inclut la création d'instances sans serveur dans le cadre d'une restauration de cluster.)
+ Certaines limites d'instance sont déterminées par la capacité actuelle de l'instance, comme la limite de connexions, la limite de curseur et la limite de transactions ouvertes. Lorsque vous choisissez la `MaxCapacity` valeur de votre charge de travail, veillez à tenir compte de ces limites d'instance afin d'éviter de vous retrouver bloqué par l'une de ces limites. Pour de plus amples informations, veuillez consulter [Limites des instances sans serveur Amazon DocumentDB](docdb-serverless-instance-limits.md).
Pour obtenir des instructions sur la façon de modifier la configuration de dimensionnement d'un cluster, consultez[Gestion d'Amazon DocumentDB sans serveur](docdb-serverless-managing.md).
## Éviter les out-of-memory erreurs
**Si l'une de vos instances sans serveur DocumentDB atteint régulièrement la limite de sa capacité maximale, Amazon DocumentDB indique cette condition en définissant l'instance sur le statut de paramètres incompatibles.** Bien que le statut des **paramètres de l'instance soit incompatible**, certaines opérations sont bloquées. Par exemple, vous ne pouvez pas mettre à niveau la version du moteur. Pour plus d'informations sur le statut d'une instance Amazon DocumentDB, consultez [Surveillance du statut d'une instance Amazon DocumentDB](https://docs.aws.amazon.com//documentdb/latest/developerguide/monitoring_docdb-instance_status.html).
Généralement, votre instance passe dans cet état lorsqu'elle redémarre fréquemment en raison d' out-of-memoryerreurs. Amazon DocumentDB enregistre un événement lorsque ce type de redémarrage se produit. Pour consulter les événements relatifs aux ressources, voir[Affichage des événements Amazon DocumentDB](managing-events.md#viewing-events). L'utilisation de la mémoire peut être anormalement élevée en raison de la surcharge liée à l'activation de paramètres tels que Performance Insights. Cela peut également être dû à une charge de travail importante sur votre instance ou à la gestion des métadonnées associées à un grand nombre d'objets de schéma.
Si la pression de la mémoire diminue et que l'instance n'atteint pas souvent sa capacité maximale, Amazon DocumentDB redéfinit automatiquement le statut de l'instance pour qu'il soit de nouveau disponible.
Pour vous remettre de cet état, vous pouvez prendre tout ou partie des mesures suivantes :
+ Augmentez la limite inférieure de capacité pour les instances sans serveur en modifiant la valeur minimale de l'unité de capacité DocumentDB (DCU) pour le cluster. Cela évite les situations problématiques où une base de données inactive fait l’objet d’une réduction d’échelle jusqu’à une capacité où la mémoire est inférieure à la mémoire nécessaire pour les fonctionnalités activées dans votre cluster. Après avoir modifié les paramètres DCU du cluster, redémarrez l'instance sans serveur. Cela permet d'évaluer si Amazon DocumentDB peut remettre le statut sur disponible.
+ Augmentez la limite supérieure de capacité pour les instances sans serveur en modifiant la valeur DCU maximale pour le cluster. Cela évite les situations problématiques où une base de données occupée ne peut pas faire l’objet d’une augmentation d’échelle jusqu’à une capacité où la mémoire est suffisante pour les fonctionnalités activées dans votre cluster et pour la charge de travail de la base de données. Après avoir modifié les paramètres DCU du cluster, redémarrez l'instance sans serveur. Cela permet d'évaluer si Amazon DocumentDB peut remettre le statut sur disponible.
+ Désactivez les paramètres de configuration exigeant une surcharge de mémoire. Supposons, par exemple, qu'une fonctionnalité telle que Performance Insights soit activée mais que vous ne l'utilisez pas. Si c'est le cas, vous pouvez le désactiver. Vous pouvez également ajuster les valeurs de capacité minimale et maximale du cluster à une valeur supérieure pour tenir compte de la mémoire utilisée par ces types de fonctionnalités. Pour obtenir des directives sur le choix des valeurs de capacité minimale et maximale, consultez [Choix de la plage de capacité de dimensionnement pour un cluster sans serveur DocumentDB](#docdb-serverless-scaling-capacity-choosing).
+ Réduisez la charge de travail de l'instance. Par exemple, vous pouvez ajouter des instances de lecteur au cluster pour répartir la charge des requêtes en lecture seule sur un plus grand nombre d'instances.
## Pourquoi mon instance sans serveur n'est-elle pas réduite ?
Dans certains cas, DocumentDB serverless ne réduit pas sa capacité minimale, même si la base de données n'est pas chargée. Plusieurs raisons sont possibles :
+ Performance Insights peut augmenter l'utilisation des ressources et empêcher la réduction de la capacité de la base de données au minimum. Ces fonctionnalités sont les suivantes :
+ Si une instance de lecteur n'est pas réduite au minimum et conserve une capacité égale ou supérieure à celle de l'instance d'écriture, vérifiez le niveau de priorité de l'instance de lecteur. Les instances de lecteur sans serveur DocumentDB de niveau 0 ou 1 sont maintenues à une capacité minimale au moins aussi élevée que celle de l'instance d'écriture. Changez le niveau de priorité du processus de lecture à 2 ou plus pour qu’il augmente et diminue indépendamment du processus d’écriture. Pour de plus amples informations, veuillez consulter [Dimensionnement sans serveur Amazon DocumentDB](docdb-serverless-how-it-works.md#docdb-serverless-scaling).
+ De lourdes charges de travail de base de données peuvent augmenter l’utilisation des ressources.
+ D’importants volumes de base de données peuvent augmenter l’utilisation des ressources. Amazon DocumentDB utilise la mémoire et les ressources du processeur pour la gestion des clusters. Amazon DocumentDB nécessite davantage de processeur et de mémoire pour gérer les clusters dotés de volumes de base de données plus importants. Si la capacité minimale de votre cluster est inférieure à la capacité minimale requise pour la gestion du cluster, votre cluster ne sera pas réduit à la capacité minimale.
+ Les activités de maintenance en arrière-plan peuvent augmenter périodiquement l'utilisation des ressources.
Si la base de données n’est toujours pas réduite à la capacité minimale configurée, arrêtez et redémarrez la base de données pour récupérer les fragments de mémoire qui ont pu s’accumuler au fil du temps. L’arrêt et le démarrage d’une base de données entraînent une durée d’indisponibilité, il est donc recommandé de le faire avec parcimonie.
# Surveillance d'Amazon DocumentDB sans serveur
Pour en savoir plus sur la surveillance dans Amazon DocumentDB, consultez. [Surveillance d'Amazon DocumentDB](monitoring_docdb.md)
**Topics**
+ [Mémoire insuffisante : état des paramètres incompatibles](#w2aac41c27b7)
+ [CloudWatch Métriques Amazon pour DocumentDB sans serveur](#w2aac41c27b9)
+ [Surveillance des performances sans serveur de DocumentDB avec Performance Insights](#w2aac41c27c11)
## Mémoire insuffisante : état des paramètres incompatibles
Si l'une de vos instances sans serveur atteint régulièrement la limite de sa capacité maximale, Amazon DocumentDB indique cette condition en définissant l'instance sur le statut de paramètres incompatibles. Pour de plus amples informations, veuillez consulter [Éviter les out-of-memory erreurs](docdb-serverless-scaling-config.md#docdb-serverless-scaling-mem-errors).
## CloudWatch Métriques Amazon pour DocumentDB sans serveur
Pour en savoir plus sur l'utilisation CloudWatch avec Amazon DocumentDB, consultez. [Surveillance d'Amazon DocumentDB avec CloudWatch](cloud_watch.md)
Vous pouvez consulter vos instances sans serveur CloudWatch pour surveiller la capacité consommée par chaque instance à l'aide de la `ServerlessDatabaseCapacity` métrique. Vous pouvez également surveiller toutes les CloudWatch métriques DocumentDB standard, telles que `DatabaseConnections` et les requêtes. Pour obtenir la liste complète des CloudWatch métriques que vous pouvez surveiller pour Amazon DocumentDB, consultez. [Surveillance d'Amazon DocumentDB avec CloudWatch](cloud_watch.md) Il est important de surveiller les métriques suivantes CloudWatch au niveau de l'instance afin de comprendre comment vos instances sans serveur DocumentDB augmentent ou diminuent. Toutes ces métriques sont calculées toutes les secondes. Ainsi, vous pouvez surveiller l'état actuel de vos instances sans serveur. Vous pouvez définir des alarmes pour vous avertir si une instance sans serveur approche un seuil pour les métriques liées à la capacité. Vous pouvez déterminer si les valeurs de capacité minimale et maximale sont appropriées ou si vous devez les ajuster. Vous pouvez déterminer où concentrer vos efforts pour optimiser l’efficacité de votre base de données.
+ **`ServerlessDatabaseCapacity`**— En tant que métrique au niveau de l'instance, elle indique le nombre de DCUs représentés par la capacité actuelle de l'instance. En tant que métrique au niveau du cluster, elle représente la moyenne des `ServerlessDatabaseCapacity` valeurs de toutes les instances sans serveur DocumentDB du cluster.
+ **`DCUUtilization.`**— Cette métrique est nouvelle dans DocumentDB serverless. Cette valeur est représentée sous forme de pourcentage. Elle est calculée comme la valeur de la `ServerlessDatabaseCapacity` métrique divisée par la valeur DCU maximale du cluster. Tenez compte des directives suivantes pour interpréter cette métrique et prendre les mesures nécessaires :
+ Si cette métrique s'approche d'une valeur de`100.0`, l'instance a été agrandie au maximum. Envisagez d'augmenter le paramètre DCU maximal pour le cluster. Ainsi, les instances de rédacteur et de lecteur peuvent augmenter leur capacité.
+ Supposons qu'une charge de travail en lecture seule amène une instance de lecteur à s'approcher d'un `DCUUtilization` de`100.0`, alors que l'instance de rédacteur n'est pas proche de sa capacité maximale. Dans ce cas, envisagez d'ajouter des instances de lecteur supplémentaires au cluster. Ainsi, vous pouvez répartir la partie en lecture seule de la charge de travail sur un plus grand nombre d'instances, réduisant ainsi la charge sur chaque instance de lecteur.
+ Supposons que vous exécutiez une application de production, où les performances et la capacité de mise à l’échelle sont les principaux facteurs à prendre en compte. Dans ce cas, vous pouvez définir la valeur DCU maximale pour le cluster sur un nombre élevé. Votre objectif est que la `DCUUtilization` métrique soit toujours inférieure à 100,0. Avec une valeur DCU maximale élevée, vous pouvez être sûr qu'il y a suffisamment de place en cas de pics inattendus d'activité de la base de données. Seule la capacité de base de données réellement consommée vous est facturée.
+ **`CPUUtilization`**— Cette métrique est interprétée différemment dans DocumentDB serverless que dans les instances provisionnées. Pour DocumentDB serverless, cette valeur est un pourcentage calculé comme la quantité de processeur actuellement utilisée, divisée par la capacité du processeur disponible sous la valeur DCU maximale du cluster. Amazon DocumentDB surveille automatiquement cette valeur et augmente le dimensionnement de votre instance sans serveur lorsque celle-ci utilise régulièrement une grande partie de sa capacité de processeur.
Si cette métrique s'approche d'une valeur de`100.0`, l'instance a atteint sa capacité CPU maximale. Envisagez d'augmenter le paramètre DCU maximal pour le cluster. Si cette métrique se rapproche d'une valeur de `100.0` sur une instance de lecteur, envisagez d'ajouter des instances de lecteur supplémentaires au cluster. Ainsi, vous pouvez répartir la partie en lecture seule de la charge de travail répartie sur un plus grand nombre d'instances, réduisant ainsi la charge sur chaque instance de lecteur.
+ **`FreeableMemory`**— Cette valeur représente la quantité de mémoire inutilisée disponible lorsque l'instance sans serveur DocumentDB est dimensionnée à sa capacité maximale. Pour chaque DCU dont la capacité actuelle est inférieure à la capacité maximale, cette valeur augmente d'environ 2 GiB. Ainsi, cette métrique n'approche pas zéro tant que l'instance n'est pas agrandie au maximum.
Si cette métrique est proche de zéro, cela signifie que l'instance a été agrandie autant que possible et qu'elle est proche de la limite de sa mémoire disponible. Envisagez d'augmenter le paramètre DCU maximal pour le cluster. Si cette métrique approche une valeur nulle sur une instance de lecteur, envisagez d'ajouter des instances de lecteur supplémentaires au cluster. Ainsi, la partie en lecture seule de la charge de travail peut être répartie sur un plus grand nombre d'instances, réduisant ainsi l'utilisation de la mémoire sur chaque instance de lecteur.
+ **`TempStorageIops`**— Le nombre d'IOPS effectuées sur le stockage local attaché à l'instance. Il inclut les E/S par seconde pour les lectures et les écritures. Cette métrique représente un nombre et est mesurée une fois par seconde. Il s'agit d'une nouvelle métrique pour DocumentDB sans serveur. Pour en savoir plus, consultez [Surveillance d'Amazon DocumentDB avec CloudWatch](cloud_watch.md).
+ **`TempStorageThroughput`**— La quantité de données transférée vers et depuis le stockage local associé à l'instance. Cette métrique représente des octets et est mesurée une fois par seconde. Il s'agit d'une nouvelle métrique pour DocumentDB sans serveur. Pour en savoir plus, consultez [Surveillance d'Amazon DocumentDB avec CloudWatch](cloud_watch.md).
Généralement, la majeure partie de la mise à l'échelle des instances sans serveur DocumentDB est due à l'utilisation de la mémoire et à l'activité du processeur. Les `TempStorageThroughput` indicateurs `TempStorageIops` et peuvent vous aider à diagnostiquer les rares cas où l'activité réseau liée aux transferts entre votre instance et les périphériques de stockage locaux est responsable d'augmentations de capacité inattendues. Pour surveiller d’autres activités du réseau, vous pouvez utiliser ces métriques existantes :
+ `NetworkReceiveThroughput`
+ `NetworkThroughput`
+ `NetworkTransmitThroughput`
+ `StorageNetworkReceiveThroughput`
+ `StorageNetworkThroughput`
+ `StorageNetworkTransmitThroughput`
### Comment les CloudWatch métriques sans serveur DocumentDB s'appliquent à votre facture AWS
Les frais sans serveur DocumentDB figurant sur votre AWS facture sont calculés sur la base de la même `ServerlessDatabaseCapacity` métrique que vous pouvez surveiller. Le mécanisme de facturation peut différer de la CloudWatch moyenne calculée pour cette métrique dans les cas où vous utilisez la capacité sans serveur de DocumentDB pendant une partie d'heure seulement. Cela peut également être différent si des problèmes du système rendent la CloudWatch métrique indisponible pendant de brèves périodes. Ainsi, il se peut que la valeur des heures DCU sur votre facture soit légèrement différente de celle indiquée si vous la calculez vous-même à partir de la valeur moyenne. `ServerlessDatabaseCapacity`
### Exemples de commandes Amazon CloudWatch CLI pour les métriques sans serveur DocumentDB
Les AWS CLI exemples suivants montrent comment surveiller les CloudWatch indicateurs les plus importants liés à DocumentDB sans serveur. Dans chaque cas, remplacez la `Value=` chaîne du `--dimensions` paramètre par l'identifiant de votre propre instance sans serveur DocumentDB.
L'exemple Linux suivant affiche les valeurs de capacité minimale, maximale et moyenne d'une instance, mesurées toutes les 10 minutes pendant une heure. Les commandes de date de Linux spécifient les heures de début et de fin par rapport à la date et à l'heure actuelles. La fonction `sort_by` du paramètre `--query` trie les résultats par ordre chronologique en fonction du champ `Timestamp`.
```
aws cloudwatch get-metric-statistics \
--metric-name "ServerlessDatabaseCapacity" \
--start-time "$(date -d '1 hour ago')" \
--end-time "$(date -d 'now')" \
--period 600 \
--namespace "AWS/DocDB" \
--statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=my_instance \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' \
--output table
```
L'exemple Linux suivant illustre la surveillance de la capacité d'une instance dans un cluster. Il mesure l'utilisation minimale, maximale et moyenne de la capacité d'une instance. Les mesures sont effectuées une fois par heure sur une période de trois heures. Ces exemples utilisent la `DCUUtilization` métrique représentant un pourcentage de la limite supérieure de DCUs, au lieu de `ServerlessDatabaseCapacity` représenter un nombre fixe de DCUs. Ainsi, vous n'avez pas besoin de connaître les chiffres réels des valeurs DCU minimales et maximales dans la plage de capacité. Les pourcentages sont compris entre 0 et 100.
```
aws cloudwatch get-metric-statistics \
--metric-name "DCUUtilization" \
--start-time "$(date -d '3 hours ago')" \
--end-time "$(date -d 'now')" \
--period 3600 \
--namespace "AWS/DocDB" \
--statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=my_instance \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' \
--output table
```
L’exemple Linux suivant effectue des mesures similaires aux précédentes. Dans ce cas, les mesures concernent la métrique `CPUUtilization`. Les mesures sont effectuées toutes les 10 minutes sur une période d’une heure. Les chiffres représentent le pourcentage du processeur disponible utilisé, en fonction des ressources du processeur disponibles par rapport au paramètre de capacité maximale défini pour l'instance.
```
aws cloudwatch get-metric-statistics \
--metric-name "CPUUtilization" \
--start-time "$(date -d '1 hour ago')" \
--end-time "$(date -d 'now')" \
--period 600 \
--namespace "AWS/DocDB" \
--statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=my_instance \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' \
--output table
```
L’exemple Linux suivant effectue des mesures similaires aux précédentes. Dans ce cas, les mesures concernent la métrique `FreeableMemory`. Les mesures sont effectuées toutes les 10 minutes sur une période d’une heure.
```
aws cloudwatch get-metric-statistics \
--metric-name "FreeableMemory" \
--start-time "$(date -d '1 hour ago')" \
--end-time "$(date -d 'now')" \
--period 600 \
--namespace "AWS/DocDB" \
--statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=my_instance \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' \
--output table
```
## Surveillance des performances sans serveur de DocumentDB avec Performance Insights
Vous pouvez utiliser Performance Insights pour surveiller les performances des instances sans serveur de DocumentDB. Pour connaître les procédures relatives à Performance Insights, consultez [Surveillance avec Performance Insights](performance-insights.md).
Les nouveaux compteurs Performance Insights suivants s'appliquent aux instances sans serveur DocumentDB :
+ **`os.general.serverlessDBCapacity`**— La capacité actuelle de l'instance en DCUs. La valeur correspond à la `ServerlessDatabaseCapacity` CloudWatch métrique de l'instance.
+ **`os.general.dcuUtilization`**— Le pourcentage de la capacité actuelle par rapport à la capacité maximale configurée. La valeur correspond à la `DCUUtilization` CloudWatch métrique de l'instance.
+ **`os.general.maxConfiguredDcu`**— Capacité maximale que vous avez configurée pour cette instance sans serveur DocumentDB. C'est mesuré en DCUs.
+ **`os.general.minConfiguredDcu`**— Capacité minimale que vous avez configurée pour cette instance sans serveur DocumentDB. C'est mesuré en DCUs.
Pour obtenir la liste complète des compteurs Performance Insights, consultez [Performance Insights pour les contre-métriques](performance-insights-counter-metrics.md).
Lorsque les valeurs de vCPU sont affichées pour une instance sans serveur DocumentDB dans Performance Insights, ces valeurs représentent des estimations basées sur la valeur DCU de l'instance. À l’intervalle par défaut d’une minute, toutes les valeurs vCPU fractionnelles sont arrondies au nombre entier le plus proche. Pour les intervalles plus longs, la valeur vCPU affichée correspond à la moyenne des valeurs entières de vCPU pour chaque minute.