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. # Gestion de votre base de données Amazon Neptune Cette section explique comment gérer et maintenir votre cluster de base de données Neptune à l'aide du AWS Management Console et du. AWS CLI Neptune opère sur des clusters de serveurs de base de données qui sont connectés dans une topologie de réplication. Par conséquent, la gestion de Neptune implique souvent de déployer des modifications sur plusieurs serveurs et de s'assurer que tous les réplicas Neptune suivent le rythme du serveur principal. Étant donné que Neptune met à l'échelle le stockage sous-jacent en toute transparence à mesure que vos données augmentent, la gestion de Neptune exige relativement peu de gestion au niveau du stockage sur disque. De la même manière, étant donné que Neptune effectue automatiquement des sauvegardes continues, un cluster Neptune nécessite peu de planification ou de temps d'arrêt pour la réalisation des sauvegardes. **Topics** + [ # Utilisation de la Blue/Green solution Neptune pour effectuer des mises à jour bleues ](neptune-BG-deployments.md) + [ # Création d'un utilisateur IAM avec les autorisations nécessaires pour accéder à Neptune ](manage-console-iam-user.md) + [ # Groupes de paramètres Amazon Neptune ](parameter-groups.md) + [ # Paramètres Amazon Neptune ](parameters.md) + [ # Lancement d'un cluster de base de données Neptune à l'aide du AWS Management Console ](manage-console-launch-console.md) + [ # Arrêt et démarrage d'un cluster de bases de données Amazon Neptune. ](manage-console-stop-start.md) + [ # Vider un cluster de bases de données Amazon Neptune à l'aide de l'API de réinitialisation rapide ](manage-console-fast-reset.md) + [ # Ajout d'instances de lecteur Neptune à un cluster de bases de données ](manage-console-add-replicas.md) + [ # Création d'une instance de lecteur Neptune à l'aide de la console ](manage-console-create-replica.md) + [ # Modification d'un cluster de bases de données Neptune à l'aide de la console ](manage-console-modify.md) + [ # Performances et mise à l'échelle dans Amazon Neptune ](manage-console-performance-scaling.md) + [ # Autoscaling du nombre de réplicas dans un cluster de bases de données Amazon Neptune ](manage-console-autoscaling.md) + [ # Maintenance du cluster de bases de données Amazon Neptune ](cluster-maintenance.md) + [ # Utilisation d'un CloudFormation modèle pour mettre à jour la version du moteur de votre cluster de base de données Neptune ](cfn-engine-update.md) + [ # Clonage de bases de données dans Neptune ](manage-console-cloning.md) + [ # Gestion des instances Amazon Neptune ](manage-console-instances.md) # Utilisation de la Blue/Green solution Neptune pour effectuer des mises à jour bleues Les mises à niveau du moteur Amazon Neptune peuvent impliquer un temps d'arrêt des applications, car la base de données n'est pas disponible pendant l'installation et la vérification des mises à jour, et ce que les mises à niveau aient initiées manuellement ou automatiquement. Neptune fournit une solution de Blue/Green déploiement que vous pouvez exécuter à l'aide d'une CloudFormation pile et qui réduit considérablement ces temps d'arrêt. Il crée un environnement intermédiaire vert qui est synchronisé avec l'environnement de production bleu. Vous pouvez ensuite mettre à jour cet environnement intermédiaire pour effectuer une mise à niveau mineure ou majeure de la version du moteur, une modification du modèle de données de graphe ou une mise à jour du système d'exploitation, puis tester le résultat. Enfin, vous pouvez le changer rapidement pour en faire votre environnement de production, avec un temps d'arrêt minime. La Blue/Green solution Neptune passe par deux phases, comme illustré dans ce schéma : ![\[Schéma de haut niveau de la stratégie de déploiement bleu/vert\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/BG-flow.png) **La phase 1 crée un cluster de bases de données vert identique au cluster de production** La solution crée un cluster de base de données avec un identifiant de blue/green déploiement unique et avec la même topologie de cluster que votre cluster de production. En d'autres termes, il possède le même nombre et la même taille d'instances de base de données, les mêmes groupes de paramètres et les mêmes configurations que le cluster de bases de données de production (bleu), sauf qu'il a été mis à niveau vers la version de moteur cible que vous avez spécifiée, qui doit être supérieure à la version actuelle du moteur (bleu). Vous pouvez spécifier une version mineure et une version majeure du moteur pour la cible. Si nécessaire, la solution effectue toutes les mises à niveau intermédiaires nécessaires pour atteindre la version cible spécifiée du moteur. Ce nouveau cluster devient l'environnement intermédiaire vert. **La phase 2 configure la synchronisation continue des données** Une fois que l'environnement vert a été entièrement préparé, la solution configure une réplication continue entre le cluster source (bleu) et le cluster cible (vert) à l'aide des flux Neptune. Lorsque la différence de réplication entre eux atteint zéro, l'environnement intermédiaire est prêt à être testé. À ce stade, vous devez suspendre l'écriture dans le cluster bleu pour éviter tout retard de réplication supplémentaire. La version cible du moteur peut avoir de nouvelles fonctionnalités ou dépendances qui affectent vos applications. Consultez la page de la version cible du moteur et les pages de mises à jour apportées entre-temps au moteur sous [Versions du moteur](engine-releases.md) pour identifier ce qui a changé depuis la version actuelle du moteur. Il est préférable d'exécuter des tests d'intégration ou de vérifier vos applications manuellement sur le cluster vert avant de le promouvoir dans l'environnement de production. Après avoir testé et qualifié les modifications dans le cluster vert, il vous suffit de faire passer le point de terminaison de base de données de vos applications du cluster bleu au cluster vert. Après le passage au numérique, la Blue/Green solution Neptune ne supprime pas l'ancien environnement de production bleu. Vous y aurez toujours accès pour une validation et des tests supplémentaires si nécessaire. Les frais de facturation standard s'appliqueront à ses instances jusqu'à ce que vous les supprimiez. La Blue/Green solution utilise également d'autres AWS services dont les coûts sont facturés aux prix normaux. Les détails relatifs à la suppression de la solution une fois que vous n'en avez plus besoin sont décrits dans la [section sur le nettoyage](neptune-BG-cleanup.md). ## Conditions préalables à l'utilisation de la pile Neptune Blue/Green Avant de lancer la pile Neptune Blue/Green  : + Assurez-vous d'[activer les flux Neptune](streams-using.md) dans le cluster de production (bleu). + Toutes les instances du cluster bleu doivent présenter l'état **disponible**. Vous pouvez vérifier l'état des instances dans la [console Neptune](https://console.aws.amazon.com/neptune) ou à l'aide de l'[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/neptune/describe-db-instances.html)API. + Toutes les instances doivent également être synchronisées avec le [groupe de paramètres du cluster de bases de données](parameter-groups.md). + La Blue/Green solution Neptune nécessite un point de terminaison DynamoDB VPC dans le VPC où se trouve votre cluster bleu. Consultez [Utilisation des points de terminaison d'un VPC Amazon pour accéder à DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/network-isolation.html#vpc-endpoints-dynamodb). + Choisissez d'exécuter la solution à un moment où la charge de travail d'écriture sur le cluster de bases de données de production bleu sera aussi légère que possible. Évitez, par exemple, d'exécuter la solution lorsqu'un chargement en bloc doit avoir lieu ou lorsque vous prévoyez un grand nombre d'opérations d'écriture pour une autre raison. # Utilisation d'un CloudFormation modèle pour exécuter la solution Neptune Blue/Green Vous pouvez l'utiliser AWS CloudFormation pour déployer la solution Neptune Blue/Green . Le CloudFormation modèle crée une instance Amazon EC2 dans le même VPC que votre base de données Neptune Blue Source, y installe la solution et l'exécute. Vous pouvez suivre sa progression dans des CloudWatch journaux, comme expliqué dans la section [Surveillance de la progression](neptune-BG-monitoring.md). Vous pouvez utiliser ces liens pour consulter le modèle de solution ou sélectionner le bouton **Launch Stack** pour le lancer dans la CloudFormation console : | | | | | --- |--- |--- | | [Afficher](https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [Afficher dans Designer](https://console.aws.amazon.com/cloudformation/designer/home?templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | Dans la console, choisissez la AWS région dans laquelle vous souhaitez exécuter la solution dans le menu déroulant en haut à droite de la fenêtre. Définissez les paramètres de la pile comme suit : + **`DeploymentID`**— Un identifiant unique pour chaque déploiement de Neptune Blue/Green . Il est utilisé comme identifiant de cluster de bases de données vert et comme préfixe pour nommer les nouvelles ressources créées lors du déploiement. + **`NeptuneSourceClusterId`** : identifiant du cluster de bases de données bleu que vous souhaitez mettre à niveau. + **`NeptuneTargetClusterVersion:`** : [version du moteur Neptune](engine-releases.md) vers laquelle vous souhaitez mettre à niveau le cluster de bases de données bleu. Cette valeur doit être plus récente que la version actuelle du moteur du cluster de bases de données bleu. + **`DeploymentMode`** : indique s'il s'agit d'un nouveau déploiement ou d'une tentative de reprise d'un déploiement précédent. Lorsque vous utilisez un `DeploymentID` identique à celui d'un déploiement précédent, définissez `DeploymentMode` sur `resume`. Les valeurs valides sont `new` (par défaut) et `resume`. + **`GraphQueryType`** : type de données de graphe correspondant à votre base de données. Les valeurs valides sont `propertygraph` (par défaut) et `rdf`. + **`SubnetId`** : ID de sous-réseau provenant du même VPC que celui dans lequel se trouve le cluster de bases de données bleu (voir [Connexion à un cluster de bases de données Neptune à partir d'une instance Amazon EC2 dans le même VPC](get-started-connect-ec2-same-vpc.md)). Fournissez l'ID d'un sous-réseau public si vous souhaitez accéder à l'instance par SSH via [EC2 Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html). + **`InstanceSecurityGroup`** : groupe de sécurité de votre instance Amazon EC2. Le groupe de sécurité doit avoir accès à votre cluster de bases de données bleu, et vous devez être en mesure de vous connecter à l'instance par SSH. Consultez [Créez un groupe de sécurité à l'aide de la console VPC.](get-started-vpc.md#security-vpc-security-group). Patientez jusqu'à ce que la pile soit terminée. Dès que cette étape est terminée, le lancement de la solution a lieu. Vous pouvez ensuite surveiller le processus de déploiement à l'aide CloudWatch des journaux, comme décrit dans la section suivante. # Surveillance de la progression d'un déploiement de Neptune Blue/Green Vous pouvez suivre la progression de la Blue/Green solution Neptune en accédant à la [CloudWatch console](https://console.aws.amazon.com/cloudwatch/) et en consultant les journaux du groupe de `/aws/neptune/(Neptune Blue/Green deployment ID)` CloudWatch journaux. Vous pouvez trouver un lien vers les CloudWatch journaux dans les sorties de la CloudFormation pile de la solution : ![\[Capture d'écran de la sortie Blue/Green CloudFormation Stack\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/BG-stack-output.png) Si vous avez fourni un sous-réseau public en tant que paramètre de pile, vous pouvez également accéder par SSH à l'instance Amazon EC2 créée dans le cadre de la pile et vous référer au journal dans `/var/log/cloud-init-output.log`. Le journal indique les actions entreprises par la Blue/Green solution Neptune, comme le montre cette capture d'écran : ![\[Capture d'écran de l'écran du journal Neptune Blue/Green\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/BG-log-screenshot.png) Les messages du journal indiquent l'état de synchronisation entre les clusters bleu et vert : ![\[Capture d'écran des messages du journal de la Blue/Green solution Neptune\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/BG-log-messages.png) Le processus de synchronisation vérifie le délai de réplication en calculant la différence entre le dernier flux du cluster bleu et `eventID` le point de contrôle de réplication présent dans la table de points de contrôle DynamoDB créée par la pile de réplication. Neptune-to-Neptune À l'aide de ces messages, vous pouvez surveiller la différence de réplication actuelle. # Passage du cluster bleu de production au cluster vert mis à jour Avant de promouvoir le cluster vert en production, assurez-vous que la différence de validation entre les clusters bleu et vert est nulle, puis désactivez tout le trafic d'écriture vers le cluster bleu. Toute nouvelle écriture dans le cluster bleu lors du basculement du point de terminaison de la base de données vers le cluster vert entraînerait une corruption des données provoquée par l'écriture de données partielles dans les deux clusters. Vous n'avez pas encore besoin de désactiver le trafic de lecture. Si vous avez activé l'authentification IAM sur le cluster source (bleu), veillez à mettre à jour toutes les politiques IAM utilisées dans vos applications pour qu'elles pointent vers le cluster vert (pour un exemple de politique de ce type, consultez cette [stratégie d'accès illimité](iam-data-access-examples.md#iam-auth-data-policy-example-general)). Après avoir désactivé le trafic d'écriture, attendez que la réplication soit terminée, puis activez le trafic d'écriture sur le cluster vert (mais pas sur le cluster bleu). Faites également passer le trafic de lecture du cluster bleu au cluster vert. # Nettoyage une fois la Blue/Green solution Neptune terminée Après avoir promu le cluster intermédiaire (vert) en production, nettoyez les ressources créées par la solution Neptune Blue/Green  : + Supprimez l'instance Amazon EC2 créée pour exécuter la solution. + Supprimez les CloudFormation modèles pour la [réplication basée sur les flux Neptune](streams-consumer-setup.md) qui maintenaient le cluster vert synchronisé avec le cluster bleu. Le modèle principal porte le nom de pile que vous avez fourni précédemment, et l'autre est composé de l'ID de déploiement suivi de "-replication", à savoir `(DeploymentID)-replication`. La suppression CloudFormation de modèles ne supprime pas les clusters eux-mêmes. Une fois que vous avez vérifié que le cluster vert fonctionne comme prévu, vous pouvez choisir de créer un instantané avant de supprimer manuellement le cluster bleu. # Bonnes pratiques en matière de Blue/Green solutions Neptune + Avant de passer le cluster vert en production, il est important de vérifier minutieusement qu'il fonctionne correctement. Vérifiez la cohérence des données et la configuration de la base de données. Il est possible que certaines des nouvelles versions du moteur nécessitent également des mises à niveau du client. Consultez les notes de mise à jour du moteur avant de procéder à la mise à niveau. Il vaut la peine de tester tout cela dans des environnements de développement, de test et de pré-production avant de commencer une blue/green mise à niveau en production. + Il est préférable de passer du serveur bleu au serveur vert pendant la fenêtre de maintenance. + Pour garantir que tout fonctionne correctement après la mise à niveau et la synchronisation, il est conseillé de conserver le cluster d'origine pendant un certain temps avant de le supprimer. Cela pourrait s'avérer utile en cas de problème imprévu. + Évitez les opérations d'écriture lourdes telles que les chargements en masse lors de l'exécution de la Blue/Green solution Neptune, car elles peuvent entraîner un retard de réplication entraînant des temps d'arrêt importants. Idéalement, le délai entre la désactivation des écritures dans le cluster bleu et leur activation dans le cluster vert est de quelques instants seulement. # Résolution des problèmes liés à la solution Neptune Blue/Green Les informations suivantes mettent en évidence les problèmes qui peuvent survenir au cours du processus de déploiement de la Blue/Green solution, tels que les conflits avec les clusters existants, la nécessité d'activer les flux Neptune, les opérations de chargement groupé en cours et les exigences de compatibilité des versions. En résolvant ces problèmes potentiels, vous pouvez garantir un déploiement fluide et réussi de la solution Neptune Blue/Green . **Erreurs signalées par la solution Neptune Blue/Green** + **`Cluster with id = (blue_green_deployment_id) already exists`**— Il existe un cluster avec identifiant*(blue\$1green\$1deployment\$1id)*. Fournissez un nouvel ID de déploiement ou définissez le mode de déploiement comme `resume` si le cluster a été créé lors d'une précédente exécution de Neptune Blue/Green . + **`Streams should be enabled on the source Cluster for Blue Green Deployment`** : activez les [flux Neptune](streams-using-enabling.md) sur le cluster bleu (source). + **`No Bulkload should be in progress on source cluster: (cluster_id)`**— La Blue/Green solution Neptune prend fin si elle identifie un chargement en vrac en cours. Cela permet de s'assurer que le processus de synchronisation est capable de rattraper son retard par rapport aux écritures effectuées. Évitez ou annulez toute tâche de chargement en vrac en cours avant de démarrer la solution Neptune Blue/Green . + **`Blue Green deployment requires instances to be in sync with db cluster parameter group`** : toute modification apportée au groupe de paramètres du cluster doit être synchronisée dans l'ensemble du cluster de bases de données. Consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md). + **`Invalid target engine version for Blue Green Deployment`** : la version cible du moteur doit être répertoriée comme active dans [Versions du moteur pour Amazon Neptune](engine-releases.md) et doit être supérieure à la version actuelle du moteur du cluster source (bleu). # Création d'un utilisateur IAM avec les autorisations nécessaires pour accéder à Neptune Pour accéder à la console Neptune afin de créer et de gérer un cluster de bases de données Neptune, vous devez créer un utilisateur IAM doté de toutes les autorisations nécessaires. La première étape consiste à créer une politique de rôle liée à un service pour Neptune : ## Création d'une politique de rôle liée à un service pour Amazon Neptune 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de gauche, sélectionnez **Policies** (Politiques). 1. Sur la page **Politiques**, sélectionnez **Créer une politique**. 1. Sur la page **Créer une politique**, sélectionnez l'onglet **JSON** et copiez la politique de rôle suivante liée à un service : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "iam:CreateServiceLinkedRole", "Effect": "Allow", "Resource": "arn:aws:iam::*:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS", "Condition": { "StringLike": { "iam:AWSServiceName":"rds.amazonaws.com" } } } ] } ``` ------ 1. Sélectionnez **Suivant : Balises**, puis sur la page **Ajouter des balises**, sélectionnez **Suivant : Vérification**. 1. Sur la page **Réviser la politique**, nommez la nouvelle politique « NeptuneServiceLinked ». Pour plus d’informations sur les rôles liés à un service, consultez [Utilisation de rôles liés à un service pour Amazon Neptune](security-iam-service-linked-roles.md). ## Création d'un utilisateur IAM avec toutes les autorisations nécessaires Créez ensuite l'utilisateur IAM avec les politiques gérées appropriées associées qui accorderont les autorisations dont vous avez besoin, ainsi que la politique de rôle liée à un service que vous avez créée (nommée ici `NeptuneServiceLinked`) : 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de gauche, sélectionnez **Utilisateurs**, puis sur la page **Utilisateurs**, choisissez **Ajouter des utilisateurs**. 1. Sur la page **Ajouter un utilisateur**, entrez le nom du nouvel utilisateur IAM, choisissez **Clé d'accès - Accès programmatique** pour le type AWS d'identifiant, puis choisissez **Suivant** : Autorisations. 1. Sur la page **Définir les autorisations**, dans la zone **Politiques de filtre**, tapez « Neptune ». Sélectionnez maintenant les politiques suivantes parmi celles qui sont répertoriées : + **NeptuneFullAccess** + **NeptuneConsoleFullAccess** + **NeptuneServiceLinked**(en supposant que c'est ainsi que vous avez nommé la politique de rôle liée au service que vous avez créée précédemment). 1. Tapez ensuite « VPC » dans le champ **Politiques de filtre** à la place de « Neptune ». Sélectionnez **Amazon VPCFull Access** dans les politiques répertoriées. 1. Sélectionnez **Suivant : Balises**, puis sur la page **Ajouter des balises**, sélectionnez **Suivant : Vérification**. 1. Sur la page **Vérification**, vérifiez que toutes les politiques suivantes sont désormais associées au nouvel utilisateur : + **NeptuneFullAccess** + **NeptuneConsoleFullAccess** + **NeptuneServiceLinked** + **Amazon VPCFull Access** Sélectionnez ensuite **Créer un utilisateur**. 1. Enfin, téléchargez et enregistrez l'ID de clé d'accès et la clé d'accès secrète du nouvel utilisateur. Pour interagir avec d'autres services tels qu'Amazon Simple Storage Service (Amazon S3), vous devez ajouter des autorisations et des relations d'approbation supplémentaires. # Groupes de paramètres Amazon Neptune Vous gérez votre configuration de base de données dans Amazon Neptune à l'aide de [paramètres](parameters.md) dans un groupe de paramètres. Les groupes de paramètres servent de *conteneurs* pour les valeurs de configuration de moteur qui sont appliquées à une ou plusieurs instances de base de données. Il existe deux types de groupes de paramètres : les groupes de paramètres de cluster de bases de données et les groupes de paramètres de base de données. + Les *groupes de paramètres de base de données* s'appliquent au niveau de l'instance et sont généralement associés aux paramètres du moteur de graphe Neptune, comme le paramètre `neptune_query_timeout`. + Les *groupes de paramètres de cluster de base de données* s'appliquent à chaque instance du cluster et ont généralement des valeurs plus générales. Chaque cluster Neptune est associé à un groupe de paramètres de cluster de bases de données. Toutes les instances de base de données au sein de ce cluster héritent des valeurs de configuration du moteur contenues dans le groupe de paramètres de cluster de bases de données. Les valeurs de configuration que vous modifiez dans le groupe de paramètres de cluster de base de données remplacent les valeurs par défaut du groupe de paramètres de base de données. Si vous modifiez les valeurs correspondantes dans le groupe de paramètres de base de données, ces valeurs remplacent celles du groupe de paramètres de cluster de bases de données. Un groupe de paramètres de base de données par défaut est utilisé si vous créez une instance de base de données sans spécifier un groupe de paramètres de base de données personnalisé. Vous ne pouvez pas modifier les valeurs de paramètre d'un groupe de paramètres de base de données par défaut. Pour modifier les paramètres par défaut, vous devez créer un groupe de paramètres de base de données. Il n'est pas possible de modifier tous les paramètres de moteur de base de données dans un groupe de paramètres de base de données que vous créez. Les groupes de paramètres sont créés dans des familles compatibles avec des versions spécifiques du moteur Neptune. Lorsque vous effectuez une mise à niveau vers une nouvelle version majeure ou secondaire du moteur, vous devrez peut-être recréer vos groupes de paramètres personnalisés en utilisant la famille de groupes de paramètres correspondante pour cette version. La dénomination de la famille de groupes de paramètres suit le modèle`neptuneX.Y`, où `X.Y` correspond à la version du moteur. Par exemple : + `neptune1`— pour les versions du moteur antérieures à 1.2.0.0 + `neptune1.2`— pour les versions de moteur 1.2.x + `neptune1.3`— pour les versions de moteur 1.3.x + `neptune1.4`— pour les versions de moteur 1.4.x Lors de la mise à niveau de votre cluster Neptune, consultez les [notes de publication](engine-releases.md) de la version de votre moteur cible pour déterminer si une nouvelle famille de groupes de paramètres est requise. Dans ce cas, vous devez recréer tous les groupes de paramètres personnalisés de la nouvelle famille avant de procéder à la mise à niveau. Certains paramètres Neptune sont statiques, tandis que d'autres sont dynamiques. Les différences sont les suivantes : **Paramètres statiques** + Un paramètre statique est un paramètre qui ne prend effet qu'après le redémarrage d'une instance de base de données. En d'autres termes, lorsque vous modifiez un paramètre statique et que vous enregistrez le groupe de paramètres de base de données d'une instance, vous devez redémarrer manuellement l'instance de base de données pour que la modification du paramètre soit appliquée. Actuellement, tous les paramètres au niveau des instances Neptune (dans un groupe de paramètres de base de données plutôt que dans un groupe de paramètres de cluster de bases de données) sont statiques. + Lorsque vous modifiez un paramètre statique au niveau du cluster et que vous enregistrez le groupe de paramètres de base de données d'un cluster, la modification de ce paramètre est appliquée après que vous avez redémarré manuellement chaque instance de base de données du cluster. **Paramètres dynamiques** + Un paramètre dynamique est un paramètre qui prend effet presque immédiatement après sa mise à jour dans son groupe de paramètres. En d'autres termes, il n'est pas nécessaire de redémarrer une instance de base de données après avoir mis à jour un paramètre dynamique pour que la modification prenne effet. + Attendez-vous à un léger délai avant que la modification d'un paramètre de cluster dynamique soit appliquée à toutes les instances de base de données. + Une valeur de paramètre dynamique mise à jour n'est pas appliquée aux demandes en cours d'exécution, mais uniquement à celles soumises après la modification. + Lorsque vous modifiez un paramètre dynamique au niveau du cluster, par défaut, la modification de ce paramètre est appliquée à votre cluster de bases de données immédiatement, sans nécessiter de redémarrage. Pour différer la modification des paramètres jusqu'au redémarrage des instances de base de données du cluster, vous pouvez utiliser le pour définir la AWS CLI valeur sur `ApplyMethod` `pending-reboot` pour la modification des paramètres. Actuellement, tous les paramètres sont statiques, à l'exception des nouveaux paramètres de cluster suivants : + `neptune_enable_slow_query_log` (au niveau du cluster) + `neptune_slow_query_log_threshold` (au niveau du cluster) Voici quelques éléments importants que vous devez connaître concernant l'utilisation de paramètres dans un groupe de paramètres DB : + La configuration incorrecte de paramètres dans un groupe de paramètres DB peut avoir des effets contraires involontaires, dont une dégradation de la performance et une instabilité du système. Montrez-vous toujours prudent lorsque vous modifiez des paramètres de base de données et sauvegardez vos données avant de modifier un groupe de paramètres de base de données. Testez les modifications de paramètres de votre groupe de paramètres sur une instance de base de données test avant d'appliquer ces modifications à une instance de base de données de production. + Lorsque vous modifiez le groupe de paramètres DB associé à une instance de base de données, vous devez redémarrer manuellement l'instance avant que le nouveau groupe de paramètres DB soit utilisé par l'instance de base de données. **Note** Avant la [Sortie : 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), toutes les instances de réplica en lecture d'un cluster de bases de données étaient automatiquement redémarrées lors du redémarrage de l'instance (d'enregistreur) principale. À compter de la [Sortie : 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), le redémarrage de l'instance principale n'entraîne le redémarrage d'aucune des instances de réplica. Dès lors, si vous modifiez un paramètre au niveau du cluster, vous devez redémarrer chaque instance séparément pour que cette modification de paramètre s'applique. ## Modification d'un groupe de paramètres de cluster de base de données ou d'un groupe de paramètres de base de données 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Choisissez **Parameter groups (Groupes de paramètres)** dans le volet de navigation. 1. Choisissez le lien **Name (Nom)** pour le groupe de paramètres de base de données à modifier. (Facultatif) Choisissez **Create parameter group (Créer un groupe de paramètres)** pour créer un nouveau groupe de paramètres de cluster. Choisissez ensuite le **Name (Nom)** du nouveau groupe de paramètres. **Important** Cette étape est *obligatoire* si vous ne disposez que du groupe de paramètres de cluster de base de données par défaut, car ce groupe de paramètres ne peut pas être modifié. 1. Recherchez le paramètre et cliquez sur le champ **Valeur** à côté de la colonne **Nom**. 1. Entrez la valeur autorisée et cochez la case à côté du champ de valeur. 1. Sélectionnez **Enregistrer les modifications**. 1. Redémarrez chaque instance de base de données du cluster Neptune si vous modifiez un paramètre de cluster de bases de données, ou une ou plusieurs instances spécifiques si vous modifiez un paramètre d'instance de base de données. ## Création d'un groupe de paramètres de base de données ou d'un groupe de paramètres de cluster de bases de données Vous pouvez facilement utiliser la console Neptune pour créer un groupe de paramètres : 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Choisissez **Parameter groups (Groupes de paramètres)** dans le volet de navigation de gauche. 1. Choisissez **Create DB parameter group (Créer un groupe de paramètres de base de données)**. La page **Create DB parameter group (Créer un groupe de paramètres de base de données)** s'affiche. 1. ****Dans la liste des **familles de groupes de paramètres**, choisissez la famille qui correspond à la version de votre moteur Neptune cible (par exemple, **neptune1.2, neptune1.3 ou neptune1.4**).**** 1. Dans la liste **Type**, choisissez **DB Parameter Group (Groupe de paramètres de base de données)** ou **DB Cluster Parameter Group (Groupe de paramètres de cluster de base de donnée)**. 1. Dans la zone **Nom du groupe**, saisissez le nom du nouveau groupe de paramètres de base de données. 1. Dans la zone **Description**, saisissez une description pour le nouveau groupe de paramètres de base de données. 1. Choisissez **Créer**. Vous pouvez également créer un groupe de paramètres à l'aide de l' AWS CLI : ``` aws neptune create-db-parameter-group \ --db-parameter-group-name (a name for the new DB parameter group) \ --db-parameter-group-family (the family matching your engine version, such as neptune1.2, neptune1.3, or neptune1.4) \ --description (a description for the new DB parameter group) ``` # Paramètres Amazon Neptune Vous gérez votre configuration de base de données dans Amazon Neptune à l'aide de paramètres dans des [groupes de paramètres](parameter-groups.md). Les paramètres suivants sont disponibles pour configurer votre base de données Neptune : **Paramètres de niveau cluster** + [neptune\$1enable\$1audit\$1log](#parameters-db-cluster-parameters-neptune_enable_audit_log) + [neptune\$1enable\$1slow\$1query\$1log](#parameters-db-cluster-parameters-neptune_enable_slow_query_log) + [neptune\$1slow\$1query\$1log\$1threshold](#parameters-db-cluster-parameters-neptune_slow_query_log_threshold) + [neptune\$1lab\$1mode](#parameters-db-cluster-parameters-neptune_lab_mode) + [neptune\$1query\$1timeout](#parameters-db-cluster-parameters-neptune_query_timeout) + [neptune\$1streams](#parameters-db-cluster-parameters-neptune_streams) + [neptune\$1streams\$1expiry\$1days](#parameters-db-cluster-parameters-neptune_streams_expiry_days) + [neptune\$1lookup\$1cache](#parameters-db-cluster-parameters-neptune_lookup_cache) + [neptune\$1autoscaling\$1config](#parameters-db-cluster-parameters-neptune_autoscaling_config) + [neptune\$1ml\$1iam\$1role](#parameters-db-cluster-parameters-neptune_ml_iam_role) + [neptune\$1ml\$1endpoint](#parameters-db-cluster-parameters-neptune_ml_endpoint) + [neptune\$1enable\$1inline\$1server\$1generated\$1edge\$1id](#parameters-db-cluster-parameters-neptune_inline_edge_id)   **Paramètres de niveau instance** + [neptune\$1dfe\$1query\$1engine](#parameters-instance-parameters-neptune_dfe_query_engine) + [neptune\$1query\$1timeout](#parameters-instance-parameters-neptune_query_timeout) + [neptune\$1result\$1cache](#parameters-db-instance-parameters-neptune_result_cache) + [UndoLogPurgeConfig](#parameters-db-instance-parameters-undo_log_purge_config)   **Paramètres obsolètes** + [neptune\$1enforce\$1ssl](#parameters-db-cluster-parameters-neptune_enforce_ssl) ## `neptune_enable_audit_log` (paramètre de niveau cluster) Ce paramètre active la journalisation des audits pour Neptune. Les valeurs autorisées sont `0` (désactivé) et `1` (activé). La valeur par défaut est `0`. Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Vous pouvez publier des journaux d'audit sur Amazon CloudWatch, comme décrit dans[Utilisation de la CLI pour publier les journaux d'audit de Neptune dans Logs CloudWatch](cloudwatch-logs.md#cloudwatch-logs-cli). ## `neptune_enable_slow_query_log` (paramètre de niveau cluster) Utilisez ce paramètre pour activer ou désactiver la fonctionnalité de [journalisation des requêtes lentes](slow-query-logs.md) de Neptune. Il s'agit d'un paramètre dynamique. Autrement dit, la modification de sa valeur ne nécessite ni ne provoque le redémarrage du cluster de bases de données. Les valeurs autorisées sont les suivantes : + **`info`** : active la journalisation des requêtes lentes et enregistre les attributs sélectionnés susceptibles de contribuer au ralentissement des performances. + **`debug`** : active la journalisation des requêtes lentes et enregistre tous les attributs disponibles de la requête exécutée. + **`disabled`** : désactive la journalisation des requêtes lentes. La valeur par défaut est `disabled`. Vous pouvez publier des journaux de requêtes lentes sur Amazon CloudWatch, comme décrit dans. [Utilisation de la CLI pour publier les journaux de requêtes lentes de Neptune dans Logs CloudWatch](cloudwatch-logs.md#cloudwatch-slow-query-logs-cli) ## `neptune_slow_query_log_threshold` (paramètre de niveau cluster) Ce paramètre indique le délai d'exécution, en millisecondes, après lequel une requête est considérée comme une requête lente. Si la [journalisation des requêtes lentes](slow-query-logs.md) est activée, les requêtes dont l'exécution dépasse ce seuil sont journalisées avec certains de leurs attributs. La valeur par défaut est de 5 000 millisecondes (5 secondes). Il s'agit d'un paramètre dynamique. Autrement dit, la modification de sa valeur ne nécessite ni ne provoque le redémarrage du cluster de bases de données. ## `neptune_lab_mode` (paramètre de niveau cluster) Lorsqu'il est défini, ce paramètre active des fonctionnalités expérimentales spécifiques de Neptune. Consultez [Mode expérimental Neptune](features-lab-mode.md) pour connaître les fonctions expérimentales actuellement disponibles. Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Pour activer ou désactiver une fonctionnalité expérimentale, incluez *(feature name)* `=enabled` ou *(feature name)* `=disabled` dans ce paramètre. Vous pouvez activer ou désactiver plusieurs fonctions en les séparant par des virgules, comme ceci : *(feature \$11 name)*`=enabled,` *(feature \$12 name)*`=enabled` Les fonctionnalités du mode expérimental sont généralement désactivées par défaut. Une exception est la fonctionnalité `DFEQueryEngine`, qui a été activée par défaut pour être utilisée avec les indicateurs de requête (`DFEQueryEngine=viaQueryHint`) à partir de la [version 1.0.5.0 du moteur Neptune](engine-releases-1.0.5.0.md). Depuis la [version 1.1.1.0 du moteur Neptune](engine-releases-1.1.1.0.md), le moteur DFE n'est plus en mode laboratoire et est désormais contrôlé à l'aide du paramètre d'instance [neptune\$1dfe\$1query\$1engine](#parameters-instance-parameters-neptune_dfe_query_engine) dans le groupe de paramètres de base de données d'une instance. ## `neptune_query_timeout` (paramètre de niveau cluster) Spécifie une durée d'expiration particulière pour les requêtes de graphe, en millisecondes. Les valeurs autorisées vont de `10` à `2,147,483,647` (231 - 1). La valeur par défaut est `120,000` (2 minutes). Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Lorsque plusieurs paramètres de délai d'attente sont configurés (au niveau du cluster, au niveau de l'instance et par requête), le tableau suivant indique quelle valeur de délai est prioritaire : | PG de clusters | Instance PG | Indicateur de requête | Outcome | | --- | --- | --- | --- | | Par défaut | Par défaut | Aucune | Cluster | | Personnalisé | Par défaut | Aucune | Cluster | | Personnalisé | Personnalisé | Aucune | Instance | | Par défaut | Personnalisé | Aucune | Instance | | N’importe lequel | N’importe lequel | le plus bas | Query | | Par défaut | Personnalisé | pas le plus bas | Instance | | Personnalisé | Par défaut | pas le plus bas | Cluster | | Personnalisé | Personnalisé | pas le plus bas | Instance | **Note** Il est possible que vous encouriez des coûts inattendus si vous définissez une valeur trop élevée pour le délai d'expiration des requêtes, en particulier sur une instance sans serveur. En l'absence d'un délai raisonnable d'expiration des requêtes, vous risquez de lancer par inadvertance une requête qui s'exécute bien plus longtemps que prévu, entraînant ainsi des coûts que vous n'aviez pas anticipés. Cela est particulièrement vrai pour une instance sans serveur, qui pourrait passer à un type d'instance volumineux et coûteux lors de l'exécution de la requête. Pour éviter des dépenses imprévues de ce type, utilisez une valeur de délai d'expiration qui convient à la plupart des requêtes et qui n'implique que l'expiration de celles dont le délai est étonnamment long. ## `neptune_streams` (paramètre de niveau cluster) Active ou désactive [Flux Neptune](streams.md). Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Les valeurs autorisées sont `0` (désactivé, qui est la valeur par défaut) et `1` (activé). ## `neptune_streams_expiry_days` (paramètre de niveau cluster) Spécifie le nombre de jours qui s'écoulent avant que le serveur ne supprime les enregistrements de flux. Les valeurs autorisées vont de `1` à `90` inclus. La valeur par défaut est `7`. Ce paramètre a été introduit dans la [version 1.2.0.0 du moteur](engine-releases-1.2.0.0.md). Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. ## `neptune_lookup_cache` (paramètre de niveau cluster) Désactive ou réactive le [cache de recherche Neptune](feature-overview-lookup-cache.md) sur les instances `R5d`. Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Les valeurs autorisées sont `1` (activé) et `0` (désactivé). La valeur par défaut est `0`, mais chaque fois qu'une instance `R5d` est créée dans le cluster de bases de données, le paramètre `neptune_lookup_cache` est automatiquement défini sur `1`, et un cache de recherche est créé sur cette instance. ## `neptune_autoscaling_config` (paramètre de niveau cluster) Définit les paramètres de configuration des instances de réplica en lecture créées et gérées par l'[auto-scaling](manage-console-autoscaling.md) Neptune. Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. À l'aide d'une chaîne JSON que vous définissez comme valeur du paramètre `neptune_autoscaling_config`, vous pouvez spécifier : + Type d'instance utilisé par l'auto-scaling Neptune pour toutes les nouvelles instances de réplica en lecture qu'il crée. + Les fenêtres de maintenance attribuées à ces réplicas en lecture. + Les balises à associer à tous les nouveaux réplicas en lecture. La chaîne JSON a une structure comme celle-ci : ``` "{ \"tags\": [ { \"key\" : \"reader tag-0 key\", \"value\" : \"reader tag-0 value\" }, { \"key\" : \"reader tag-1 key\", \"value\" : \"reader tag-1 value\" }, ], \"maintenanceWindow\" : \"wed:12:03-wed:12:33\", \"dbInstanceClass\" : \"db.r5.xlarge\" }" ``` Notez que les guillemets de la chaîne doivent tous être précédés d'une barre oblique inverse (`\`). Les trois paramètres de configuration non spécifiés dans le paramètre `neptune_autoscaling_config` sont copiés à partir de la configuration de l'instance d'enregistreur principale du cluster de bases de données. ## `neptune_ml_iam_role` (paramètre de niveau cluster) Spécifie l'ARN du rôle IAM utilisé dans Neptune ML. Cette valeur peut être n'importe quel ARN de rôle IAM valide. Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Vous pouvez spécifier l'ARN du rôle IAM par défaut pour le machine learning au niveau des graphes. ## `neptune_ml_endpoint` (paramètre de niveau cluster) Spécifie le point de terminaison utilisé pour Neptune ML. La valeur peut être n'importe quel nom de point de [terminaison SageMaker AI](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateEndpoint.html#sagemaker-CreateEndpoint-request-EndpointName) valide. Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Vous pouvez spécifier le point de terminaison d' SageMaker IA par défaut pour l'apprentissage automatique sur des graphiques. ## `neptune_enable_inline_server_generated_edge_id` (paramètre de niveau cluster) Activez ou désactivez la fonctionnalité Edge ID générée par le serveur en ligne Neptune. Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Les valeurs autorisées sont `1` (activé) et `0` (désactivé). La valeur par défaut est `0`. ## `neptune_dfe_query_engine` (paramètres de niveau instance) À partir de la [version 1.1.1.0 du moteur Neptune](engine-releases-1.1.1.0.md), ce paramètre d'instance de base de données est utilisé pour contrôler la manière dont le [moteur de requêtes DFE](neptune-dfe-engine.md) est utilisé. Les valeurs autorisées sont les suivantes : Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. + **`enabled`** : fait en sorte que le moteur DFE soit utilisé dans la mesure du possible, sauf lorsque l'indicateur de requête `useDFE` est présent et défini sur `false`. + **`viaQueryHint`** (valeur par défaut) : fait en sorte que le moteur DFE soit utilisé uniquement pour les requêtes qui incluent explicitement l'indicateur de requête `useDFE` défini sur `true`. Si ce paramètre n'a pas été défini explicitement, la valeur par défaut, `viaQueryHint`, est utilisée au démarrage de l'instance. **Note** Toutes les requêtes openCypher sont exécutées par le moteur DFE, quelle que soit la manière dont ce paramètre est défini. Avant la version 1.1.1.0, il s'agissait d'un paramètre en mode expériemental plutôt que d'un paramètre d'instance de base de données. ## `neptune_query_timeout` (paramètres de niveau instance) Ce paramètre d'instance de base de données spécifie un délai d'expiration pour les requêtes de graphe, en millisecondes, pour une instance. Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Les valeurs autorisées vont de `10` à `2,147,483,647` (231 - 1). La valeur par défaut est `120,000` (2 minutes). **Note** Il est possible que vous encouriez des coûts inattendus si vous définissez une valeur trop élevée pour le délai d'expiration des requêtes, en particulier sur une instance sans serveur. En l'absence d'un délai raisonnable d'expiration des requêtes, vous risquez de lancer par inadvertance une requête qui s'exécute bien plus longtemps que prévu, entraînant ainsi des coûts que vous n'aviez pas anticipés. Cela est particulièrement vrai pour une instance sans serveur, qui pourrait passer à un type d'instance volumineux et coûteux lors de l'exécution de la requête. Pour éviter des dépenses imprévues de ce type, utilisez une valeur de délai d'expiration qui convient à la plupart des requêtes et qui n'implique que l'expiration de celles dont le délai est étonnamment long. ## `neptune_result_cache` (paramètres de niveau instance) **`neptune_result_cache`** : ce paramètre d'instance de base de données active ou désactive [Mise en cache des résultats de requête](gremlin-results-cache.md). Ce paramètre est statique, ce qui signifie que les modifications apportées ne prennent effet sur aucune instance tant qu'elle n'a pas été redémarrée. Les valeurs autorisées sont `0` (désactivé, qui est la valeur par défaut) et `1` (activé). ## `UndoLogPurgeConfig` (paramètres de niveau instance) **`UndoLogPurgeConfig`**— Utilisez ce paramètre pour activer ou désactiver la UndoLog purge agressive dans Neptune. Les valeurs autorisées sont `default` les suivantes : qui utilise le nombre standard de threads pour la purge des journaux d'annulation et `aggressive` qui utilise un nombre accru de threads pour accélérer le nettoyage des journaux d'annulation. Lorsque l'`agressive`option est sélectionnée, vous pouvez vous attendre à observer une valeur plus élevée pour la `NumUndoPagesPurged` métrique. ## `neptune_enforce_ssl` (paramètre au niveau du cluster OBSOLÈTE) (**Obsolète**) Certaines régions autorisaient les connexions HTTP à Neptune, et ce paramètre était utilisé pour forcer toutes les connexions à utiliser le protocole HTTPS lorsqu'il était défini sur 1. Ce paramètre n'est toutefois plus pertinent, car Neptune n'accepte désormais que les connexions HTTPS dans toutes les régions. # Lancement d'un cluster de base de données Neptune à l'aide du AWS Management Console Le moyen le plus simple de lancer un nouveau cluster de base de données Neptune consiste à utiliser un CloudFormation modèle qui crée toutes les ressources nécessaires pour vous, comme expliqué dans. [Créer un cluster Neptune](get-started-create-cluster.md) Si vous préférez, vous pouvez également utiliser la console Neptune pour lancer un nouveau cluster de bases de données manuellement, comme expliqué ici. **Note** Avant de pouvoir accéder à la console Neptune pour créer un cluster Neptune, vous devez disposer d'un utilisateur disposant des autorisations suffisantes. Si votre utilisateur actuel ne dispose pas de ces autorisations, vous pouvez créer un utilisateur IAM doté des autorisations nécessaires, comme expliqué dans[Création d'un utilisateur IAM avec les autorisations nécessaires pour accéder à Neptune](manage-console-iam-user.md). Une fois que vous avez vérifié que votre utilisateur dispose des autorisations appropriées, ou que vous avez créé un utilisateur avec les autorisations appropriées, connectez-vous en AWS Management Console tant qu'utilisateur IAM et suivez les étapes ci-dessous pour créer un nouveau cluster de base de données : **Pour lancer un cluster de bases de données Neptune à l'aide de la console** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Accédez à la page **Clusters** sous **Bases de données** et choisissez **Créer une base de données**, ce qui ouvre la page **Créer une base de données**. 1. Sous **Paramètres**, entrez le nom de votre nouveau cluster de bases de données ou acceptez le nom par défaut qui y est fourni. Ce nom est utilisé dans l'adresse de point de terminaison de l'instance et doit satisfaire aux contraintes suivantes : + Il doit contenir entre 1 et 63 caractères alphanumériques ou traits d’union. + Son premier caractère doit être une lettre. + Il ne peut pas se terminer par un trait d’union ou contenir deux traits d’union consécutifs. + Il doit être unique pour toutes les instances de base de données de votre AWS compte dans une AWS région donnée. 1. Sous **Modèles**, choisissez **Production** ou **Développement et test**. 1. Sous **Taille de l'instance debase de données**, choisissez une taille d'instance. Cela détermine la capacité de traitement et de mémoire de l'instance d'enregistreur principale du nouveau cluster de bases de données. Si vous avez sélectionné le modèle **Production**, vous avez uniquement le choix entre les classes optimisées pour la mémoire disponibles dans la liste, mais si vous avez sélectionné **Développement et test**, vous pouvez également choisir des classes extensibles plus économiques (voir [Instances extensibles T3](manage-console-instances-t3.md) pour une discussion sur les classes extensibles). **Note** Neptune ne prend plus en charge les types d'`R4`instances. 1. Sous **Disponibilité et durabilité**, vous pouvez choisir d'activer ou non le déploiement multi-availability-zone (multi-AZ). Le modèle de production permet le déploiement multi-AZ par défaut, contrairement au modèle de développement et de test. Si le déploiement multi-AZ est activé, Neptune localise les instances de réplication en lecture que vous créez dans différentes zones AZs de disponibilité () afin d'améliorer la disponibilité. 1. Sous **Connectivité**, sélectionnez parmi les choix disponibles le cloud privé virtuel (VPC) qui hébergera le nouveau cluster de bases de données. Ici, vous pouvez choisir **Créer un VPC** si vous souhaitez que Neptune crée le VPC pour vous. Vous devez créer une instance Amazon EC2 dans ce même VPC pour accéder à l'instance Neptune (pour plus d'informations, consultez [Sécurisation de votre base de données Amazon Neptune avec Amazon VPC](security-vpc.md)). Notez que vous ne pourrez pas modifier le VPC après la création du cluster de bases de données. Si nécessaire, vous pouvez configurer davantage la connectivité du cluster sous **Configuration de connectivité supplémentaire** : 1. Sous **Groupe de sous-réseaux**, vous pouvez choisir le groupe de sous-réseaux de base de données Neptune à utiliser pour le nouveau cluster de bases de données. Si votre VPC ne comporte pas encore de groupes de sous-réseaux, Neptune vous créera un groupe de sous-réseaux de base de données (voir [Sécurisation de votre base de données Amazon Neptune avec Amazon VPC](security-vpc.md)). 1. Sous **Groupes de sécurité VPC**, choisissez un ou plusieurs groupes de sécurité VPC existants pour sécuriser l'accès réseau au nouveau cluster de bases de données, ou choisissez **Créer** si vous souhaitez que Neptune en crée un pour vous, puis fournissez un nom pour le nouveau groupe de sécurité VPC (voir [Créez un groupe de sécurité à l'aide de la console VPC.](get-started-vpc.md#security-vpc-security-group)). 1. Sous **Port de base de données**, entrez le TCP/IP port que la base de données utilisera pour les connexions aux applications. Neptune utilise le numéro de port `8182` par défaut. 1. Sous **Configuration du bloc-notes**, choisissez **Créer un bloc-notes** si vous souhaitez que Neptune vous crée des blocs-notes Jupyter dans le workbench Neptune (voir [Utilisation d'Amazon Neptune avec des carnets graphiques](graph-notebooks.md) et [Utilisation du workbench Neptune pour héberger des blocs-notes Neptune](graph-notebooks.md#graph-notebooks-workbench)). Vous pouvez ensuite choisir la manière dont les nouveaux blocs-notes doivent être configurés : 1. Sous **Type d'instance de bloc-notes**, choisissez parmi les classes d'instances disponibles pour votre bloc-notes. 1. Dans **Nom du bloc-notes**, entrez un nom pour le bloc-notes. 1. Si vous le souhaitez, vous pouvez également saisir une description du bloc-notes sous **Description (facultatif)**. 1. Sous **Nom du rôle IAM**, choisissez soit de demander à Neptune de créer un rôle IAM pour le bloc-notes et d'entrer un nom pour le nouveau rôle, soit de sélectionner un rôle IAM existant parmi les rôles disponibles. 1. Enfin, choisissez si votre bloc-notes se connecte à Internet directement, via Amazon SageMaker AI ou via un VPC doté d'une passerelle NAT. Consultez [Connexion d'une instance de bloc-notes aux ressources d'un VPC](https://docs.aws.amazon.com/sagemaker/latest/dg/appendix-notebook-and-internet-access.html) pour plus d'informations. 1. Sous **Balises**, vous pouvez associer jusqu'à 50 balises à votre nouveau cluster de bases de données. 1. Sous **Configuration supplémentaire**, vous pouvez définir d'autres paramètres pour votre nouveau cluster de bases de données (dans de nombreux cas, vous pouvez les ignorer et accepter les valeurs par défaut pour le moment) : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/manage-console-launch-console.html) 1. Choisissez **Créer une base de données** pour lancer le nouveau cluster de bases de données Neptune et son instance principale. Dans la console Amazon Neptune, le nouveau cluster de bases de données s'affiche dans la liste des bases de données. Le cluster de base de données a le statut **Creating (Création)** jusqu'à ce qu'il soit créé et prêt à l'emploi. Lorsque le statut devient **Available (Disponible)**, vous pouvez vous connecter à l'instance principale de votre cluster de base de données. En fonction du stockage et de la classe d'instance de bases de données alloués, la mise à disposition des nouvelles instances de bases de données peut nécessiter plusieurs minutes. Pour afficher le cluster que vous venez de créer, choisissez la vue **Bases de données** dans la console Neptune. **Note** Si vous supprimez toutes les instances de base de données Neptune d'un cluster de base de données à l'aide de AWS Management Console, la console supprime automatiquement le cluster de base de données lui-même. Si vous utilisez le SDK AWS CLI ou, vous devez supprimer le cluster de base de données manuellement après avoir supprimé sa dernière instance. Notez la valeur du **point de terminaison du cluster**. Vous en aurez besoin pour vous connecter à votre cluster de bases de données Neptune. # Arrêt et démarrage d'un cluster de bases de données Amazon Neptune. L'arrêt et le démarrage des clusters Amazon Neptune vous permettent de maîtriser les coûts liés aux environnements de développement et de test. Vous pouvez arrêter temporairement toutes les instances de base de données de votre cluster au lieu de configurer et de détruire toutes les instances de base de données chaque fois que vous utilisez le cluster. **Topics** + [ ## Présentation de l'arrêt et du démarrage d'un cluster de bases de données Neptune ](#manage-console-start-stop-overview) + [ ## Arrêt d'un cluster de bases de données Neptune ](#manage-console-stopping) + [ ## Démarrage d'un cluster de bases de données Neptune arrêté ](#manage-console-start) ## Présentation de l'arrêt et du démarrage d'un cluster de bases de données Neptune Pendant les périodes où vous n'avez pas besoin d'un cluster Neptune, vous pouvez arrêter toutes les instances du cluster en une seule opération. Vous pouvez à tout moment redémarrer le cluster dès que vous avez besoin de l’utiliser. Le démarrage et l’arrêt simplifie les processus de configuration et de destruction des clusters utilisés à des fins de développement, de test ou d’activités similaires qui ne nécessitent pas une disponibilité continue. Vous pouvez y parvenir en AWS Management Console une seule action, quel que soit le nombre d'instances présentes dans le cluster. Pendant que votre cluster de bases de données est à l'arrêt, vous êtes facturé uniquement pour le stockage du cluster, des instantanés manuels et des sauvegardes automatiques dans le cadre de votre fenêtre de rétention spécifiée. Aucune heure d'instance de base de données ne vous est facturée. Après sept jours, Neptune redémarre automatiquement votre cluster de bases de données pour éviter qu'il ne passe à côté de mises à jour de maintenance obligatoires. Afin de limiter les frais pour un cluster Neptune à faible charge, vous pouvez arrêter ce cluster plutôt que de supprimer tous ses réplicas en lecture. Pour les clusters comportant plus d'une ou deux instances, la suppression et la recréation fréquentes des instances de base de données ne sont pratiques qu'à l' AWS CLI aide de l'API Neptune, et les suppressions peuvent également être difficiles à effectuer dans le bon ordre. Par exemple, vous devez supprimer tous les réplicas en lecture avant de supprimer l'instance principale pour éviter d'activer le mécanisme de basculement. Évitez de démarrer et d'arrêter votre cluster de bases de données s'il doit s'exécuter en permanence, mais que vous souhaitez réduire sa capacité. Si votre cluster est trop coûteux ou sous-utilisé, vous pouvez supprimer une ou plusieurs instances de base de données ou modifier vos instances de base de données afin qu'elles utilisent une classe d'instance plus petite, mais vous ne pouvez pas arrêter une instance de base de données individuelle. ## Arrêt d'un cluster de bases de données Neptune Lorsque vous ne l'utilisez pas pendant un certain temps, vous pouvez arrêter un cluster de bases de données Neptune en cours d'exécution, puis le redémarrer lorsque vous en avez besoin. Pendant que le cluster est à l'arrêt, vous êtes facturé pour le stockage du cluster, des instantanés manuels et des sauvegardes automatiques dans le cadre de votre fenêtre de rétention spécifiée, mais pas pour les heures d'instance de base de données. L'opération d'arrêt stoppe les instances de réplica en lecture du cluster avant de stopper l'instance principale, pour éviter l'activation du mécanisme de basculement. ### Arrêt d'un cluster de base de données à l'aide du AWS Management Console **Pour utiliser le AWS Management Console pour arrêter un cluster Neptune** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, sélectionnez **Bases de données**, choisissez un cluster. Vous pouvez effectuer l’opération d’arrêt soit à partir de cette page, soit en accédant à la page de détails du cluster de bases de données que vous voulez arrêter. 1. Dans **Actions**, choisissez **Arrêter**. ### Arrêt d'un cluster de base de données à l'aide du AWS CLI Pour arrêter une instance de base de données à l'aide de AWS CLI, appelez la [stop-db-cluster](api-clusters.md#StopDBCluster)commande en utilisant le `--db-cluster-identifier` paramètre pour identifier le cluster de base de données que vous souhaitez arrêter. **Example** ``` aws neptune stop-db-cluster --db-cluster-identifier mydbcluster ``` ### Arrêt d'un cluster de bases de données à l'aide de l'API de gestion Neptune Pour arrêter une instance de base de données à l'aide de l'API de gestion Neptune, appelez l'DBClusterAPI [Stop](api-clusters.md#StopDBCluster) et utilisez le `DBClusterIdentifier` paramètre pour identifier le cluster de base de données que vous souhaitez arrêter. ### Ce qui peut se produire lorsqu'un cluster de bases de données est arrêté + Vous **pouvez** le restaurer à partir d'un instantané (voir [Restauration à partir d'un instantané de cluster de base de données](backup-restore-restore-snapshot.md)). + Vous **ne pouvez pas** modifier la configuration du cluster de bases de données ou de ses instances de base de données. + Vous **ne pouvez pas** ajouter des instances de base de données au cluster ni supprimer des instances de base de données du cluster. + Vous **ne pouvez pas** supprimer le cluster si des instances de base de données lui sont encore associées. + En général, vous devez redémarrer un cluster de bases de données arrêté pour effectuer la plupart des actions administratives. + Neptune appliquera les opérations de maintenance planifiée au cluster arrêté dès qu'il est redémarré. N'oubliez pas qu'après sept jours, Neptune redémarre automatiquement un cluster arrêté afin qu'il n'accumule pas trop de retard au niveau de l'état de la maintenance. + Neptune n'effectue aucune sauvegarde automatisée d'un cluster de bases de données arrêté, car les données sous-jacentes ne peuvent pas changer pendant que le cluster est arrêté. + Neptune n'étend pas la période de rétention des sauvegarde pour le cluster de bases de données pendant qu'il est arrêté. ## Démarrage d'un cluster de bases de données Neptune arrêté Vous pouvez uniquement démarrer un cluster de bases de données Neptune qui est à l'état arrêté. Lorsque vous démarrez le cluster, toutes ses instances de base de données redeviennent disponibles. Le cluster conserve ses paramètres de configuration, notamment les points de terminaison, les groupes de paramètres et les groupes de sécurité VPC. ### Démarrage d'un cluster de base de données arrêté à l'aide du AWS Management Console 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, sélectionnez **Bases de données**, choisissez un cluster. Vous pouvez effectuer l'opération de démarrage soit à partir de cette page, soit en accédant à la page de détails du cluster de bases de données. 1. Dans **Actions**, choisissez **Start (Démarrer)**. ### Démarrage d'un cluster de base de données arrêté à l'aide du AWS CLI Pour démarrer un cluster de base de données arrêté à l'aide du AWS CLI, appelez la [start-db-cluster](api-clusters.md#StartDBCluster)commande à l'aide du `--db-cluster-identifier` paramètre pour spécifier le cluster de base de données arrêté que vous souhaitez démarrer. Indiquez le nom de cluster que vous avez choisi lors de la création du cluster de bases de données ou utilisez un nom d'instance de base de données que vous avez choisi, en ajoutant `-cluster` à la fin de celui-ci. **Example** ``` aws neptune start-db-cluster --db-cluster-identifier mydbcluster ``` ### Démarrage d'un cluster de bases de données arrêté à l'aide de l'API de gestion Neptune Pour démarrer un cluster de base de données Neptune à l'aide de l'API de gestion Neptune, appelez l'DBClusterAPI [Start](api-clusters.md#StartDBCluster) à l'aide du `DBCluster` paramètre pour spécifier le cluster de base de données arrêté que vous souhaitez démarrer. Indiquez le nom de cluster que vous avez choisi lors de la création du cluster de bases de données ou utilisez un nom d'instance de base de données que vous avez choisi, en ajoutant `-cluster` à la fin de celui-ci. # Vider un cluster de bases de données Amazon Neptune à l'aide de l'API de réinitialisation rapide L'API REST de réinitialisation rapide Neptune vous permet de réinitialiser un graphe Neptune rapidement et facilement en supprimant toutes ses données. Pour ce faire, utilisez la magie linéaire [%db\$1reset](#manage-console-fast-reset-db-reset-magic) dans un bloc-notes Neptune. + Dans la plupart des cas, une opération de réinitialisation rapide se termine en quelques minutes. La durée peut varier légèrement en fonction de la charge exécutée sur le cluster au lancement de l'opération. + Une opération de réinitialisation rapide n'entraîne pas d'E/S supplémentaires. + La taille du volume de stockage ne diminue pas après une réinitialisation rapide. Au lieu de cela, le stockage est réutilisé à mesure que de nouvelles données sont insérées. Par conséquent, les tailles de volume des instantanés créés avant et après une opération de réinitialisation rapide sont les mêmes. Les tailles de volume des clusters restaurés à l'aide des instantanés créés avant et après une opération de réinitialisation rapide sont également les mêmes + Dans le cadre de l'opération de réinitialisation, toutes les instances du cluster de bases de donnes sont redémarrées. **Note** Dans de rares cas, ces redémarrages de serveur peuvent également entraîner un basculement du cluster. **Important** L'utilisation de la réinitialisation rapide peut interrompre l'intégration de votre cluster de bases de données Neptune avec d'autres services. Par exemple : La réinitialisation rapide supprime toutes les données de flux de votre base de données et réinitialise complètement les flux. En d'autres termes, les consommateurs de flux risquent de ne plus fonctionner sans une nouvelle configuration. La réinitialisation rapide supprime toutes les métadonnées relatives aux ressources d' SageMaker IA utilisées par Neptune ML, y compris les tâches et les points de terminaison. Ils existent toujours dans l' SageMaker IA, et vous pouvez continuer à utiliser les points de terminaison SageMaker IA existants pour les requêtes d'inférence Neptune ML, mais la APIs gestion de Neptune ML ne fonctionne plus avec eux. Les intégrations telles que l' full-text-searchintégration avec ElasticSearch sont également annulées par une réinitialisation rapide et doivent être rétablies manuellement avant de pouvoir être réutilisées. **Pour supprimer toutes les données d'un cluster de bases de données Neptune à l'aide de l'API** 1. Tout d'abord, générez un jeton que vous pourrez ensuite utiliser pour réinitialiser la base de données. Cette étape vise à empêcher quiconque de réinitialiser accidentellement une base de données. Pour ce faire, envoyez une demande `HTTP POST` au point de terminaison `/system` de l'instance d'enregistreur du cluster de bases de données afin de spécifier l'action `initiateDatabaseReset`. Voici la commande `curl` qui utilise le type de contenu JSON : ``` curl -X POST \ -H 'Content-Type: application/json' \ https://your_writer_instance_endpoint:8182/system \ -d '{ "action" : "initiateDatabaseReset" }' ``` Ou celle qui utilise le type de contenu `x-www-form-urlencoded` : ``` curl -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ https://your_writer_instance_endpoint:8182/system \ -d 'action=initiateDatabaseReset ' ``` La demande `initiateDatabaseReset` renvoie le jeton de réinitialisation dans sa réponse JSON, comme suit : ``` { "status" : "200 OK", "payload" : { "token" : "new_token_guid" } } ``` Le jeton reste valide pendant une heure (60 minutes) après son émission. Si vous envoyez la demande à une instance de lecteur ou au point de terminaison de statut, Neptune génère une exception `ReadOnlyViolationException`. Si vous envoyez plusieurs demandes `initiateDatabaseReset`, seul le dernier jeton généré est valide pour la deuxième étape, étape au cours de laquelle vous effectuez réellement la réinitialisation. Si le serveur redémarre juste après la demande `initiateDatabaseReset`, le jeton généré n'est plus valide, et vous devez envoyer une nouvelle demande pour obtenir un nouveau jeton. 1. Ensuite, envoyez une demande `performDatabaseReset` avec le jeton que vous avez obtenu via `initiateDatabaseReset` au point de terminaison `/system` de l'instance d'enregistreur du cluster de bases de données. Cette action supprime toutes les données du cluster de bases de données. Voici la commande `curl` qui utilise le type de contenu JSON : ``` curl -X POST \ -H 'Content-Type: application/json' \ https://your_writer_instance_endpoint:8182/system \ -d '{ "action" : "performDatabaseReset", "token" : "token_guid" }' ``` Ou celle qui utilise le type de contenu `x-www-form-urlencoded` : ``` curl -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ https://your_writer_instance_endpoint:8182/system \ -d 'action=performDatabaseReset&token=token_guid' ``` La demande renvoie une réponse JSON. Si la demande est acceptée, la réponse est la suivante : ``` { "status" : "200 OK" } ``` Si le jeton que vous avez envoyé ne correspond pas à celui qui a été émis, la réponse est la suivante : ``` { "code" : "InvalidParameterException", "requestId":"token_guid", "detailedMessage" : "System command parameter 'token' : 'token_guid' does not match database reset token" } ``` Si la demande est acceptée et que la réinitialisation commence, le serveur redémarre et supprime les données. Vous ne pouvez pas envoyer d'autres demandes au cluster de bases de données pendant sa réinitialisation. ## Utilisation de l'API de réinitialisation rapide avec l'authentification IAM Si l'authentification IAM est activée sur le cluster de bases de données, vous pouvez utiliser [awscurl](https://github.com/okigan/awscurl) pour envoyer des commandes de réinitialisation rapide authentifiées à l'aide de ce mode d'authentification : **Utilisation d'awscurl pour envoyer des demandes de réinitialisation rapide avec l'authentification IAM** 1. Définissez correctement les variables d'environnement `AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY` (ainsi qu'`AWS_SECURITY_TOKEN` si vous utilisez des informations d'identification temporaires). 1. Une demande `initiateDatabaseReset` se présente comme suit : ``` awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \ -H 'Content-Type: application/json' --region us-west-2 \ -d '{ "action" : "initiateDatabaseReset" }' ``` 1. Une demande `performDatabaseReset` se présente comme suit : ``` awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \ -H 'Content-Type: application/json' --region us-west-2 \ -d '{ "action" : "performDatabaseReset" }' ``` ## Utilisation de la magie linéaire `%db_reset` du workbench Neptune pour réinitialiser un cluster de bases de données Le workbench Neptune intègre une magie linéaire `%db_reset` qui vous permet de réinitialiser rapidement la base de données dans un bloc-notes Neptune. Si vous invoquez la magie sans aucun paramètre, un écran vous demande si vous souhaitez supprimer toutes les données du cluster. Vous devez également cocher une case afin de confirmer que vous comprenez que les données du cluster ne seront plus disponibles une fois que vous les aurez supprimées. À ce stade, vous pouvez choisir de continuer et de supprimer les données, ou d'annuler l'opération. Une option plus risquée consiste à invoquer `%db_reset` avec l'option `--yes` ou `-y`, ce qui entraîne la suppression sans invite supplémentaire. Vous pouvez également effectuer la réinitialisation en deux étapes, tout comme avec l'API REST : ``` %db_reset --generate-token ``` La réponse est : ``` { "status" : "200 OK", "payload" : { "token" : "new_token_guid" } } ``` Continuez avec : ``` %db_reset --token new_token_guid ``` La réponse est : ``` { "status" : "200 OK" } ``` ## Codes d'erreur courants pour les opérations de réinitialisation rapide | Code d'erreur Neptune | Statut HTTP | Message | Exemple | | --- | --- | --- | --- | | `InvalidParameterException` | 400 | La valeur « » du paramètre de commande système *action* « » n'est pas prise en charge *XXX* | Paramètre non valide | | `InvalidParameterException` | 400 | Trop de valeurs ont été fournies pour : *action* | Une demande de réinitialisation rapide avec plusieurs actions envoyée avec l'en-tête « Content-Type:Application/ » x-www-form-urlencoded | | `InvalidParameterException` | 400 | Champ 'action' en double | Demande de réinitialisation rapide avec plusieurs actions, envoyée avec l'en-tête 'Content-Type: application/json' | | `MethodNotAllowedException` | 400 | Mauvais itinéraire :/*bad\$1endpoint* | Demande envoyée à un point de terminaison incorrect | | `MissingParameterException` | 400 | Paramètres obligatoires manquants : [action] | Une demande de réinitialisation rapide ne contient pas le paramètre 'action' obligatoire | | `ReadOnlyViolationException` | 400 | Les écritures ne sont pas autorisées sur une instance de réplica en lecture | Une demande de réinitialisation rapide a été envoyée à un point de terminaison de lecteur ou de statut | | `AccessDeniedException` | 403 | Jeton d'authentification manquant | Une demande de réinitialisation rapide a été envoyée sans les signatures correctes à un point de terminaison de base de données sur lequel l'authentification IAM est activée | | `ServerShutdownException` | 500 | La réinitialisation de la base de données est en cours. Réessayez la requête une fois que le cluster sera disponible. | Lorsque la réinitialisation rapide commence, les requêtes Gremlin/Sparql existantes et entrantes échouent. | # Ajout d'instances de lecteur Neptune à un cluster de bases de données Les clusters de bases de données Neptune comprennent une instance de base de données principale et jusqu'à 15 instances de lecteur Neptune. L'instance de base de données principale prend en charge les opérations de lecture et d'écriture, et effectue toutes les modifications de données dans le volume de cluster. Les instances de lecteur Neptune se connectent au même volume de stockage que l'instance de base de données principale et prennent uniquement en charge les opérations de lecture. Utilisez des instances de lecteur pour décharger les charges de travail en lecture de l'instance de base de données principale. Nous vous recommandons de répartir l'instance principale et les lecteurs Neptune de votre cluster de bases de données sur plusieurs zones de disponibilité afin d'améliorer la disponibilité du cluster. La [section suivante](manage-console-create-replica.md) explique comment créer une instance de lecteur dans votre cluster de bases de données. # Création d'une instance de lecteur Neptune à l'aide de la console Après avoir créé l'instance principale pour votre cluster de bases de données Neptune, vous pouvez ajouter des instances de lecteur Neptune supplémentaires à l'aide de la console Neptune. **Pour créer une instance de lecteur Neptune à l'aide du AWS Management Console** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**. 1. Sélectionnez le cluster de bases de données dans lequel vous souhaitez créer l'instance de lecteur. 1. Choisissez **Actions**, puis **Ajouter un lecteur**. 1. Sur la page **Créer un réplica d'instance de base de données**, spécifiez les options de votre réplica Neptune. Le tableau suivant présente les paramètres d'un réplica en lecture Neptune. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/manage-console-create-replica.html) 1. Choisissez **Créer un réplica en lecture** pour créer l'instance de réplica Neptune. Pour supprimer une instance de lecteur Neptune d'un cluster de bases de données, suivez les instructions de la section [Suppression d'une instance de base de données dans Amazon Neptune](manage-console-instances-delete.md). # Modification d'un cluster de bases de données Neptune à l'aide de la console Lorsque vous modifiez une instance de base de données à l'aide du AWS Management Console, vous pouvez choisir d'appliquer les modifications immédiatement en sélectionnant **Appliquer immédiatement**. Si vous choisissez d'appliquer les modifications immédiatement, vos nouvelles modifications et les modifications placées dans la file d'attente des modifications en attente sont appliquées immédiatement. Si vous ne choisissez pas d'appliquer les modifications immédiatement, les modifications sont placées dans la file d'attente des modifications en attente. Au cours de la fenêtre de maintenance suivante, les modifications en attente sont appliquées. **Important** Si les modifications en attente exigent un temps d'arrêt, le fait de choisir de les appliquer immédiatement peut entraîner un temps d'arrêt imprévu pour l'instance de base de données en question. Il n’y a pas de durée d’indisponibilité pour les autres instances de base de données du cluster de bases de données. **Note** Lorsque vous modifiez un cluster de bases de données dans Neptune, le paramètre **Appliquer immédiatement** concerne uniquement les modifications apportées à l'**identifiant de cluster de bases de données** et à l'**authentification de la base de données IAM**. Toutes les autres modifications sont appliquées immédiatement, quelle que soit la valeur du paramètre **Appliquer immédiatement**. **Pour modifier un cluster de base de données à l'aide de la console** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le volet de navigation, choisissez **Clusters**, puis sélectionnez le cluster de bases de données que vous souhaitez modifier. 1. Choisissez **Actions**, puis **Modifier le cluster**. La page **Modify DB cluster (Modifier le cluster DB)** s’affiche. 1. Modifiez les paramètres de votre choix. **Note** Sur la console, certaines modifications au niveau de l'instance s'appliquent uniquement à l'instance de base de données active, tandis que d'autres s'appliquent à l'intégralité du cluster de bases de données. Pour modifier un paramètre qui modifie l'intégralité du cluster de bases de données au niveau de l'instance sur la console, suivez les instructions de [Modification d'une instance de base de données dans un cluster de base de données](#manage-console-modify-instance). 1. Lorsque toutes les modifications vous conviennent, choisissez **Continuer** et vérifiez le résumé. 1. Pour immédiatement appliquer les modifications, sélectionnez **Apply Immediately (Appliquer immédiatement)**. 1. Sur la page de confirmation, examinez vos modifications. Si elles sont correctes, choisissez **Modifier le cluster** pour enregistrer vos modifications. Pour éditer vos modifications, cliquez sur **Back (Retour)**, ou pour annuler vos modifications, choisissez **Cancel (Annuler)**. ## Modification d'une instance de base de données dans un cluster de base de données **Pour modifier une instance DB dans un cluster DB à l'aide de la console** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, choisissez **Instances**, puis l'instance de base de données que vous souhaitez modifier. 1. Choisissez **Actions d'instance**, puis **Modifier**. La page **Modifier l'instance de base de données** s'affiche. 1. Modifiez les paramètres de votre choix. **Note** Certains paramètres s’appliquent à l’intégralité du cluster de bases de données et doivent être modifiés au niveau du cluster. Pour modifier ces paramètres, suivez les instructions de la section [Modification d'un cluster de bases de données Neptune à l'aide de la console](#manage-console-modify). Dans le AWS Management Console, certaines modifications au niveau de l'instance s'appliquent uniquement à l'instance de base de données actuelle, tandis que d'autres s'appliquent à l'ensemble du cluster de bases de données. 1. Lorsque toutes les modifications vous conviennent, choisissez **Continuer** et vérifiez le résumé. 1. Pour immédiatement appliquer les modifications, sélectionnez **Apply Immediately (Appliquer immédiatement)**. 1. Sur la page de confirmation, examinez vos modifications. Si elles sont correctes, choisissez **Modification d'une instance de base de données** pour enregistrer vos modifications. Pour éditer vos modifications, cliquez sur **Back (Retour)**, ou pour annuler vos modifications, choisissez **Cancel (Annuler)**. # Performances et mise à l'échelle dans Amazon Neptune Les clusters de bases de données et les instances de base de données Neptune se mettent à l'échelle à trois niveaux différents : + [Dimensionnement du stockage](#manage-console-performance-scaling-storage) + [Mise à l'échelle d'une instance ;](#manage-console-performance-scaling-instances) + [Dimensionnement en lecture](#manage-console-performance-scaling-reads) ## Mise à l'échelle du stockage dans Neptune Le stockage Neptune procède à une mise à l'échelle automatique avec les données de votre volume de cluster. À mesure que vos données augmentent, le volume de stockage de votre cluster augmente, jusqu'à 128 TiB dans toutes les régions prises en charge, à l'exception de la Chine GovCloud, où il est limité à 64 TiB. La taille de votre volume de cluster est vérifiée toutes les heures afin de déterminer vos coûts de stockage. Le stockage consommé par votre base de données Neptune est facturé par tranches de Go par mois et par tranche de consommation par votre base de données Neptune, et vous I/Os consumed are billed in per million request increments. You pay only for the storage and I/Os n'avez pas besoin de le provisionner à l'avance. Pour plus d'informations, consultez la [page produit Neptune](https://aws.amazon.com/neptune/pricing). ## Mise à l'échelle des instances dans Neptune Vous pouvez mettre à l'échelle le cluster de bases de données Neptune en modifiant la classe de chaque instance de base de données dans le cluster de bases de données. Neptune prend en charge plusieurs classes d'instances de base de données à des valeurs optimales. ## Mise à l'échelle des lectures dans Neptune Vous pouvez procéder à une mise à l'échelle en lecture de votre cluster de bases de données Neptune en créant jusqu'à 15 réplicas Neptune dans le cluster de bases de données. Chaque réplica Neptune renvoie les mêmes données du volume de cluster avec un retard de réplica minimal (souvent très inférieur à 100 millisecondes, après que l'instance principale a écrit une mise à jour). Tandis que votre trafic en lecture augmente, vous pouvez créer des réplicas Neptune additionnels et vous y connecter directement pour répartir la charge de lecture de votre cluster de bases de données. Les réplicas Neptune n'ont pas à être de la même classe d'instances de base de données que l'instance principale. Pour en savoir plus sur l'ajout de réplicas Neptune à un cluster de bases de données, consultez [Ajout d'instances de lecteur](manage-console-create-replica.md). # Autoscaling du nombre de réplicas dans un cluster de bases de données Amazon Neptune Vous pouvez utiliser l'autoscaling Neptune pour ajuster automatiquement le nombre de réplicas Neptune dans un cluster de bases de données afin de répondre à vos exigences en matière de connectivité et de charge de travail. L'autoscaling permet au cluster de bases de données Neptune de gérer l'augmentation de la charge de travail, puis, lorsque la charge de travail diminue, il supprime les réplicas inutiles afin que vous ne payiez pas la capacité inutilisée. Vous ne pouvez utiliser l'auto-scaling qu'avec un cluster de bases de données Neptune qui possède déjà une instance d'enregistreur principale et au moins une instance de réplica en lecture (voir [Clusters de bases de données et instances de base de données Amazon Neptune](feature-overview-db-clusters.md)). En outre, toutes les instances de réplica en lecture du cluster doivent être dans un état disponible. Si un réplica en lecture présente un état autre que disponible, l'autoscaling Neptune ne fait rien tant que tous les réplicas en lecture du cluster ne sont pas disponibles. Consultez [Créer un cluster Neptune](get-started-create-cluster.md) si vous devez créer un cluster. À l'aide du AWS CLI, vous définissez et appliquez une [politique de dimensionnement](#manage-console-autoscaling-define-policy) au cluster de bases de données. Vous pouvez également utiliser le AWS CLI pour modifier ou supprimer votre politique d'auto-scaling. Cette politique spécifie les paramètres d'autoscaling suivants : + Nombre minimal et maximal de réplicas dans le cluster. + `ScaleOutCooldown`Intervalle entre l'activité de dimensionnement par ajout de répliques et `ScaleInCooldown` intervalle entre l'activité de dimensionnement par suppression de répliques. + La CloudWatch métrique et la valeur de déclenchement de la métrique pour la mise à l'échelle à la hausse ou à la baisse. La fréquence des actions d'autoscaling Neptune est réduite de plusieurs manières : + Au départ, pour que l'autoscaling puisse ajouter ou supprimer un lecteur, le seuil élevé de l'alarme `CPUUtilization` doit être activé pendant au moins trois minutes ou le seuil bas de l'alarme doit être activé pendant au moins 15 minutes. + Après ce premier ajout ou cette première suppression, la fréquence des actions d'autoscaling Neptune suivantes est limitée par les paramètres `ScaleOutCooldown` et `ScaleInCooldown` de la politique d'autoscaling. Si la CloudWatch métrique que vous utilisez atteint le seuil élevé que vous avez spécifié dans votre politique, si l'`ScaleOutCooldown`intervalle s'est écoulé depuis la dernière action d'auto-scaling, et si votre cluster de bases de données ne possède pas encore le nombre maximum de répliques que vous avez défini, Neptune auto-scaling crée un nouveau réplica en utilisant le même type d'instance que l'instance principale du cluster de base de données. De même, si la métrique atteint le seuil bas que vous avez spécifié, si l'intervalle `ScaleInCooldown` s'est écoulé depuis la dernière action d'auto-scaling et si votre cluster de bases de données possède un nombre de réplicas supérieur au nombre minimum que vous avez spécifié, l'auto-scaling Neptune supprime l'un des réplicas. **Note** L'autoscaling Neptune supprime uniquement les réplicas qu'il a créés. Les réplicas préexistants ne sont pas supprimés. À l'aide du paramètre de cluster de bases de données [neptune\$1autoscaling\$1config](parameters.md#parameters-db-cluster-parameters-neptune_autoscaling_config), vous pouvez également spécifier le type d'instance des réplicas en lecture créés par l'auto-scaling Neptune, les fenêtres de maintenance de ces réplicas et les balises à associer à chacun d'eux. Vous fournissez ces paramètres de configuration dans une chaîne JSON en tant que valeur du paramètre `neptune_autoscaling_config`, comme suit : ``` "{ \"tags\": [ { \"key\" : \"reader tag-0 key\", \"value\" : \"reader tag-0 value\" }, { \"key\" : \"reader tag-1 key\", \"value\" : \"reader tag-1 value\" }, ], \"maintenanceWindow\" : \"wed:12:03-wed:12:33\", \"dbInstanceClass\" : \"db.r5.xlarge\" }" ``` Notez que les guillemets de la chaîne JSON doivent tous être précédés d'une barre oblique inverse (`\`). Tous les espaces blancs dans la chaîne sont facultatifs, comme d'habitude. Les trois paramètres de configuration non spécifiés dans le paramètre `neptune_autoscaling_config` sont copiés à partir de la configuration de l'instance d'enregistreur principale du cluster de bases de données. Lorsque l'[autoscaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/) ajoute une nouvelle instance de réplica en lecture, il insère le préfixe `autoscaled-reader` dans l'ID de l'instance de base de données (par exemple, `autoscaled-reader-7r7t7z3lbd-20210828`). Il ajoute également une balise à chaque réplica en lecture qu'il crée avec la clé `autoscaled-reader` et la valeur `TRUE`. Vous pouvez voir cette balise dans l'onglet **Balises** de la page de détails de l'instance de base de données dans la AWS Management Console. ``` "key" : "autoscaled-reader", "value" : "TRUE" ``` Le niveau de promotion de toutes les instances de réplica en lecture créées par l'auto-scaling est le niveau de priorité le plus bas, qui est `15` par défaut. Cela signifie que pendant un basculement, un réplica ayant une priorité supérieure (par exemple, un réplica créé manuellement) serait promu en premier. Consultez [Tolérance aux pannes pour un cluster de bases de données Neptune](backup-restore-overview-fault-tolerance.md). L'auto-scaling de Neptune est implémenté à l'aide d'Application Auto Scaling avec une [politique de dimensionnement du suivi des cibles](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) qui utilise une métrique Neptune comme métrique prédéfinie [`CPUUtilization`](cw-metrics.md#cw-metrics-available) CloudWatch . ## Utilisation de l'auto-scaling dans un cluster de bases de données Neptune sans serveur Neptune sans serveur répond beaucoup plus rapidement que l'autoscaling Neptune lorsque la demande dépasse la capacité d'une instance, et augmente la capacité de l'instance au lieu d'en ajouter une autre. Là où l'autoscaling est conçu pour répondre à des augmentations ou à des baisses relativement stables de la charge de travail, le système sans serveur excelle dans la gestion des pics et des fluctuations rapides de la demande. En comprenant leurs points forts, vous pouvez combiner l'autoscaling et le mode sans serveur pour créer une infrastructure flexible capable de gérer efficacement l'évolution de votre charge de travail et de répondre à la demande tout en minimisant les coûts. Pour permettre à l'autoscaling de fonctionner efficacement avec le mode sans serveur, il est important de [configurer le paramètre `maxNCU` de votre cluster sans serveur](neptune-serverless-capacity-scaling.md#neptune-serverless-capacity-range-max) pour qu'il soit suffisamment élevé afin de faire face aux pics et aux brèves variations de la demande. Dans le cas contraire, les modifications transitoires ne déclencheront pas la mise à l'échelle sans serveur, ce qui pourra entraîner l'activation de nombreuses instances supplémentaires inutiles. Si la valeur `maxNCU` est suffisamment élevée, la mise à l'échelle sans serveur pourra gérer ces modifications plus rapidement et à moindre coût. ## Comment activer l'autoscaling pour Amazon Neptune Le dimensionnement automatique ne peut être activé que pour un cluster de bases de données Neptune à l'aide de l' AWS CLI. Vous ne pouvez pas activer l'autoscaling à l'aide de la AWS Management Console. De plus, l'autoscaling n'est pas pris en charge dans les régions Amazon suivantes : + Afrique (Le Cap) : `af-south-1` + Moyen-Orient (EAU) : `me-central-1` + AWS GovCloud (USA Est) : `us-gov-east-1` + AWS GovCloud (USA Ouest) : `us-gov-west-1` L'activation de l'autoscaling pour un cluster de bases de données Neptune implique trois étapes : ### 1. Enregistrement de votre cluster de bases de données avec Application Auto Scaling La première étape pour activer l'auto-scaling pour un cluster de base de données Neptune consiste à enregistrer le cluster auprès d'Application Auto Scaling, en utilisant le AWS CLI ou l'un des outils Application Auto Scaling. SDKs Le cluster doit déjà avoir une instance principale et au moins une instance de réplica en lecture : Par exemple, pour enregistrer un cluster à dimensionner automatiquement avec une à huit répliques supplémentaires, vous pouvez utiliser la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)commande suivante : ``` aws application-autoscaling register-scalable-target \ --service-namespace neptune \ --resource-id cluster:(your DB cluster name) \ --scalable-dimension neptune:cluster:ReadReplicaCount \ --min-capacity 1 \ --max-capacity 8 ``` Cela est équivalent à l'utilisation de l'opération [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html) de l'API Application Auto Scaling. La commande AWS CLI `register-scalable-target` utilise les paramètres suivants : + **`service-namespace`** : défini sur `neptune`. Ce paramètre est équivalent au paramètre `ServiceNamespace` de l'API Application Auto Scaling. + **`resource-id`** : définissez ce paramètre sur l'identifiant de ressource de votre cluster de bases de données Neptune. Le type de ressource est `cluster`, suivi du signe deux-points (`:`), puis du nom de votre cluster de bases de données. Ce paramètre est équivalent au paramètre `ResourceID` de l'API Application Auto Scaling. + **`scalable-dimension`** : la dimension pouvant être mise à l'échelle dans ce cas est le nombre d'instances de réplica dans le cluster de bases de données. Vous devez donc définir ce paramètre sur `neptune:cluster:ReadReplicaCount`. Ce paramètre est équivalent au paramètre `ScalableDimension` de l'API Application Auto Scaling. + **`min-capacity`** : nombre minimal d'instances de réplica de base de données de lecteur devant être gérées par Application Auto Scaling. Cette valeur doit être comprise entre 0 et 15 et doit être inférieure ou égale à la valeur spécifiée pour le nombre maximal de réplicas Neptune indiqué dans `max-capacity`. Il doit y avoir au moins un lecteur dans le cluster de bases de données pour que l'autoscaling fonctionne. Ce paramètre est équivalent au paramètre `MinCapacity` de l'API Application Auto Scaling. + **`max-capacity`** : nombre maximal d'instances de réplica de base de données de lecteur dans le cluster de bases de données, y compris les instances préexistantes et les nouvelles instances gérées par Application Auto Scaling. Cette valeur doit être comprise entre 0 et 15 et doit être supérieure ou égale à la valeur spécifiée pour le nombre minimal de réplicas Neptune indiqué dans `min-capacity`. Le `max-capacity` AWS CLI paramètre est équivalent au `MaxCapacity` paramètre de l'API Application Auto Scaling. Lorsque vous enregistrez votre cluster de bases de données, Application Auto Scaling crée un rôle `AWSServiceRoleForApplicationAutoScaling_NeptuneCluster` lié à un service. Pour plus d'informations, consultez [Rôles liés aux services pour Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) dans le *Guide de l'utilisateur Application Auto Scaling*. ### 2. Définition d'une politique d'autoscaling à utiliser avec votre cluster de bases de données Une politique de mise à l'échelle de suivi de la cible est définie comme un objet texte JSON qui peut également être enregistré dans un fichier texte. Pour Neptune, cette politique ne peut actuellement utiliser la métrique Neptune qu'en tant que [`CPUUtilization`](cw-metrics.md#cw-metrics-available) CloudWatch métrique prédéfinie nommée. `NeptuneReaderAverageCPUUtilization` L'exemple suivant illustre une configuration avec suivi de cible d'une politique de mise à l'échelle pour Neptune : ``` { "PredefinedMetricSpecification": { "PredefinedMetricType": "NeptuneReaderAverageCPUUtilization" }, "TargetValue": 60.0, "ScaleOutCooldown" : 600, "ScaleInCooldown" : 600 } ``` L'élément **`TargetValue`** contient le pourcentage d'utilisation de CPU au-dessus duquel l'autoscaling *monte en puissance* (en ajoutant des réplicas) et en dessous duquel il *procède à une mise à l'échelle horizontale* (en supprimant des réplicas). Dans ce cas, le pourcentage cible qui déclenche la mise à l'échelle est `60.0` %. L'élément **`ScaleInCooldown`** spécifie la durée, en secondes, devant s'écouler entre la fin d'une activité de mise à l'échelle horizontale et le début d'une autre. La durée par défaut est 300 secondes. Ici, la valeur 600 indique qu'au moins dix minutes doivent s'écouler entre la fin de la suppression d'un réplica et le début d'un autre. L'élément **`ScaleOutCooldown`** spécifie la durée, en secondes, devant s'écouler entre la fin d'une activité de mise à l'échelle verticale et le début d'une autre. La durée par défaut est 300 secondes. Ici, la valeur 600 indique qu'au moins dix minutes doivent s'écouler entre la fin de l'ajout d'un réplica et le début d'un autre. L'élément **`DisableScaleIn`** est un booléen qui, s'il est présent et défini sur `true`, dèsactive complètement la mise à l'échelle horizontale, ce qui signifie que l'autoscaling peut ajouter des réplicas, mais n'en supprimera jamais aucun. Par défaut, la mise à l'échelle horizontale est activée, et `DisableScaleIn` est défini sur `false`. ### Après avoir enregistré votre cluster de bases de données Neptune auprès d'Application Auto Scaling et après avoir défini une politique de mise à l'échelle, appliquez cette dernière au cluster de bases de données Neptune enregistré. Pour ce faire, vous pouvez utiliser la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)commande avec des paramètres tels que les suivants : ``` aws application-autoscaling put-scaling-policy \ --policy-name (name of the scaling policy) \ --policy-type TargetTrackingScaling \ --resource-id cluster:(name of your Neptune DB cluster) \ --service-namespace neptune \ --scalable-dimension neptune:cluster:ReadReplicaCount \ --target-tracking-scaling-policy-configuration file://(path to the JSON configuration file) ``` Lorsque vous avez appliqué la politique d'autoscaling, l'autoscaling est activé sur votre cluster de bases de données. Vous pouvez également utiliser la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)commande pour mettre à jour une politique d'auto-scaling existante. Voir également [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)la *référence de l'API Application Auto Scaling*. ## Suppression de l'autoscaling d'un cluster de bases de données Neptune Pour supprimer l'auto-scaling d'un cluster de base de données Neptune, utilisez les commandes et. AWS CLI [delete-scaling-policy[deregister-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/deregister-scalable-target.html)](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html) # Maintenance du cluster de bases de données Amazon Neptune Neptune assure la maintenance périodique de toutes les ressources qu’elle utilise, notamment : + **Remplacement du matériel sous-jacent si nécessaire.** Cela se produit en arrière-plan, sans que vous ayez à agir, et n’a généralement aucune incidence sur vos opérations. + **Mise à jour du système d’exploitation sous-jacent.** Les mises à niveau du système d’exploitation des instances de votre cluster de bases de données visent à améliorer les performances et la sécurité. Vous devez donc généralement les terminer dès que possible. En général, les mises à jour prennent environ 10 minutes. Les mises à jour du système d’exploitation ne modifient pas la version du moteur de base de données ou la classe d’instance de base de données d’une instance de base de données. Il est généralement préférable de mettre à jour d’abord les instances de lecteur dans un cluster de bases de données, puis l’instance de scripteur. La mise à jour simultanée des lecteurs et de l’écriture peut provoquer un temps d’arrêt en cas de basculement. Notez que les instances de base de données ne sont pas automatiquement sauvegardées avant une mise à jour du système d’exploitation. Veillez donc à effectuer des sauvegardes manuelles avant d’appliquer une mise à jour du système d’exploitation. + **Mise à jour du moteur de base de données Neptune.** Neptune publie régulièrement diverses mises à jour du moteur afin d’introduire de nouvelles fonctionnalités et améliorations et de corriger des bogues. ## Numéros de version du moteur ### Numérotation des versions avant la version du moteur 1.3.0.0 Avant novembre 2019, Neptune ne prenait en charge qu'une seule version du moteur à la fois, et les numéros de version du moteur prenaient tous la forme `1.0.1.0.200`, où `xxx` était le numéro de correctif. Toutes les nouvelles versions du moteur ont toutes été publiées sous la forme de correctifs pour les versions antérieures. Depuis novembre 2019, Neptune prend en charge plusieurs versions, ce qui permet aux clients de mieux contrôler leurs chemins de mise à niveau. Par conséquent, la numérotation des versions du moteur a changé. De novembre 2019 jusqu’à la [version 1.3.0.0 du moteur](engine-releases-1.3.0.0.md), les numéros de version du moteur comportent 5 parties. Prenez le numéro de version `1.0.2.0.R2` par exemple : + La première partie était toujours 1. + La deuxième partie, `0` dans `1.0.2.0.R2`, était le numéro de version principal de la base de données. + Les troisième et quatrième parties, `1.0.2.0.R2` dans `2.0`, étaient toutes deux des numéros de version mineures. + La cinquième partie (`R2` dans `1.0.2.0.R2`) était le numéro de correctif. La plupart des mises à jour étaient des correctifs, et la distinction entre les correctifs et les mises à jour de versions mineures n’était pas toujours claire. ### Numérotation des versions à partir de la version 1.3.0.0 du moteur À partir de la [version 1.3.0.0 du moteur](engine-releases-1.3.0.0.md), Neptune a changé la façon dont les mises à jour du moteur sont numérotées et gérées. Les numéros de version du moteur comportent désormais quatre parties, chacune correspondant à un type de version, comme suit :     *product-version***.***major-version***.***minor-version***.***patch-version* Les modifications non majeures du type de celles qui étaient précédemment publiées sous forme de correctifs sont désormais publiées sous forme de versions mineures que vous pouvez gérer à l’aide du paramètre d’instance [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu). Cela signifie que si vous le souhaitez, vous pouvez recevoir une notification chaque fois qu’une nouvelle version mineure est publiée, en vous inscrivant à l’événement [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) (voir [Abonnement à la notification d’événement Neptune](events-subscribing.md)). Les versions de correctifs sont désormais réservées aux corrections ciblées urgentes et sont numérotées à l’aide de la dernière partie du numéro de version (`*.*.*.1`, `*.*.*.2`, etc.). # Différents types de version de moteurs dans Amazon Neptune Les quatre types de version du moteur correspondant aux quatre parties d’un numéro de version du moteur sont les suivants : + **Version du produit** : cela ne change que si le produit subit des modifications profondes et fondamentales en termes de fonctionnalité ou d’interface. La version actuelle du produit Neptune est 1. + [**Version majeure**](#major-versions) : les versions majeures introduisent de nouvelles fonctionnalités importantes et des modifications majeures, et ont généralement une durée de vie utile d’au moins deux ans. + [**Version mineure**](#minor-versions) : les versions mineures peuvent contenir de nouvelles fonctionnalités, des améliorations et des corrections de bogues, mais ne contiennent aucune modification majeure. Vous pouvez choisir de les faire appliquer automatiquement ou non lors de la prochaine fenêtre de maintenance, et vous pouvez également choisir d’être averti chaque fois qu’elles sont publiées. + [**Version de correctif**](#patch-version-updates) : les versions de correctif sont publiées uniquement pour corriger des bogues urgents ou apporter des mises à jour de sécurité critiques. Elles contiennent rarement des modifications majeures, et elles sont automatiquement appliquées lors de la fenêtre de maintenance suivante après leur publication. ## Mises à jour des versions majeures d’Amazon Neptune Une mise à jour de version majeure introduit généralement une ou plusieurs nouvelles fonctionnalités importantes et contient souvent des modifications majeures. Sa durée de vie de support est généralement d’environ deux ans. Les versions majeures de Neptune sont répertoriées dans les [versions du moteur](engine-releases.md), avec leur date de sortie et leur date de fin de vie estimée. Les mises à jour des versions majeures sont entièrement facultatives jusqu’à ce que la version majeure que vous utilisez atteigne la fin de son cycle de vie. Si vous choisissez de passer à une nouvelle version majeure, vous devez installer la nouvelle version vous-même à l'aide de la console Neptune AWS CLI ou de la console Neptune, comme décrit dans. [Mises à niveau de version majeure.](engine-updates-manually.md) Toutefois, si la version majeure que vous utilisez arrive à expiration, vous serez averti que vous devez effectuer une mise à niveau vers une version majeure plus récente. Ensuite, si vous n’effectuez pas de mise à niveau dans le délai de grâce suivant la notification, une mise à niveau vers la version majeure la plus récente est automatiquement planifiée lors de la prochaine fenêtre de maintenance. Pour plus d’informations, consultez [Durée de vie des versions du moteur](engine-updates-eol-planning.md). ## Mises à jour des versions mineures d’Amazon Neptune La plupart des mises à jour du moteur Neptune sont des mises à jour mineures. Elles se produisent assez fréquemment et ne contiennent pas de modifications majeures. Si le champ [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) est défini sur `true` dans l’instance de dispositif d’écriture (principale) de votre cluster de base de données, les mises à jour de version mineures sont appliquées automatiquement à toutes les instances de votre cluster de bases de données lors de la fenêtre de maintenance suivante après leur publication. Si le champ [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) est défini sur `false` dans l’instance de dispositif d’écriture de votre cluster de bases de données, ils ne sont appliqués que si vous [les installez explicitement](engine-updates-manually.md). **Note** Les mises à jour des versions mineures sont autonomes (elles ne dépendent pas des mises à jour précédentes de la même version majeure) et cumulatives (elles contiennent toutes les fonctionnalités et tous les correctifs introduits dans les mises à jour des versions mineures précédentes). Cela signifie que vous pouvez installer n’importe quelle mise à jour de version mineure, que vous ayez installé les versions précédentes ou non. Vous pouvez facilement suivre les sorties de versions mineures en vous abonnant à l’événement [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) (consultez [Abonnement à la notification d’événement Neptune](events-subscribing.md)). Vous serez alors averti chaque fois qu’une nouvelle version mineure sera publiée. De plus, que vous soyez abonné ou non aux notifications, vous pouvez toujours [vérifier quelles mises à jour sont en attente](engine-maintenance-management.md#check-pending-updates). ## Mises à jour de version de correctif d’Amazon Neptune En cas de problèmes de sécurité ou d’autres défauts graves affectant la fiabilité de l’instance, Neptune déploie les correctifs obligatoires. Ils sont appliqués à toutes les instances de votre cluster de bases de données lors de votre prochain créneau de maintenance sans aucune intervention de votre part. Une version de correctif n’est déployée que lorsque les risques liés à son non-déploiement l’emportent sur les risques et les interruptions de service associés à son déploiement. Les versions de correctif ont lieu peu fréquemment (en général une fois à quelques mois d’intervalle) et nécessitent rarement plus d’une fraction de votre fenêtre de maintenance. # Planification de la durée de vie des versions majeures du moteur Amazon Neptune Les versions du moteur Neptune atteignent presque toujours leur fin de vie à la fin d'un trimestre du calendrier civil, à l'exception des cas où des problèmes importants de sécurité ou de disponibilité surviennent. Lorsqu'une version du moteur arrive en fin de vie, vous devez mettre à niveau votre base de données Neptune vers une version plus récente. En général, les versions du moteur Neptune restent disponibles comme suit : + **Versions mineures du moteur :** les versions mineures du moteur restent disponibles pendant au moins six mois après leur sortie. + **Versions majeures du moteur :** les versions majeures du moteur restent disponibles pendant au moins 12 mois après leur sortie. Au moins 3 mois avant la fin de vie d'une version du moteur, AWS vous enverrez une notification automatique par e-mail à l'adresse e-mail associée à votre AWS compte et publierez le même message sur votre [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/aws-health-dashboard-status.html). Cela vous laisse ainsi le temps de planifier et de préparer la mise à niveau. Lorsqu'une version du moteur arrive en fin de vie, vous ne pouvez plus créer de clusters ni d'instances à l'aide de cette version. L'autoscaling ne peut plus créer d'instances à l'aide de cette version non plus. Une version du moteur qui arrive à sa date de fin de vie effective est automatiquement mise à niveau pendant une fenêtre de maintenance. Le message qui vous est envoyé trois mois avant la fin de vie de la version du moteur contient des informations sur les implications de cette mise à jour automatique, notamment sur la version de la mise à niveau qui aura lieu automatiquement, l'impact sur vos clusters de bases de données et les actions que nous recommandons. **Important** Vous êtes responsable de la mise à jour constante des versions de votre moteur de base de données. AWS invite tous les clients à mettre à niveau leurs bases de données vers la dernière version du moteur afin de bénéficier des garanties de sécurité, de confidentialité et de disponibilité les plus récentes. Si vous utilisez votre base de données sur un moteur ou un logiciel non pris en charge après la date d'obsolescence (ce que l'on considère comme un « ancien moteur »), vous êtes exposé à un risque accru de problèmes de sécurité, de confidentialité et d'exploitation, y compris des interruptions de service. L'exploitation de votre base de données sur n'importe quel moteur est soumise à l'accord régissant votre utilisation des AWS services. Les anciens moteurs ne sont généralement pas disponibles. AWS ne fournit plus de support à l'Legacy Engine et AWS peut imposer des limites à l'accès ou à l'utilisation de tout Legacy Engine à tout moment, s'il est AWS déterminé que l'Legacy Engine présente un risque de sécurité ou de responsabilité, ou un risque de préjudice AWS, pour les Services, ses filiales ou tout tiers. Votre décision de continuer à exécuter votre contenu dans un ancien moteur pourrait rendre votre contenu indisponible, corrompu ou irrécupérable. Les bases de données exécutées sur un ancien moteur sont soumises à des exceptions au contrat de niveau de service (SLA). LES BASES DE DONNÉES ET LES LOGICIELS ASSOCIÉS EXÉCUTÉS SUR UN ANCIEN MOTEUR CONTIENNENT DES BOGUES, DES ERREURS, DES DÉFAUTS ET DES COMPOSANTS AND/OR NUISIBLES. EN CONSÉQUENCE, ET NONOBSTANT TOUTE DISPOSITION CONTRAIRE DANS LE CONTRAT OU LES CONDITIONS DE SERVICE, AWS FOURNIT L'ANCIEN MOTEUR « TEL QUEL ». # Gestion des mises à jour du moteur de votre cluster de bases de données Neptune **Note** Les mises à jour sont appliquées simultanément à toutes les instances figurant dans un cluster de bases de données. Une mise à jour nécessite un redémarrage de la base de données sur ces instances. Vous subirez donc un temps d'arrêt allant de 20-30 secondes à plusieurs minutes, après quoi vous pourrez reprendre l'utilisation du cluster de bases de données. Dans le cas d’une instance, en de rares occasions, un basculement Multi-AZ peut être requis pour terminer une mise à jour de maintenance. Pour les mises à niveau des versions majeures dont l’application peut prendre plus de temps, vous pouvez utiliser une [stratégie de déploiement bleu/vert](neptune-BG-deployments.md) afin de minimiser les temps d’arrêt. ## Détermination de la version de moteur que vous utilisez actuellement Vous pouvez utiliser la AWS CLI [`get-engine-status`](access-graph-status.md)commande pour vérifier la version du moteur que votre cluster de base de données utilise actuellement : ``` aws neptunedata get-engine-status ``` La [sortie JSON](access-graph-status.md#access-graph-status-sample-output) inclut un champ `"dbEngineVersion"` comme celui-ci : ``` "dbEngineVersion": "1.3.0.0", ``` ## Vérification des mises à jour en attente et disponibles Vous pouvez rechercher des mises à jour en attente pour votre cluster de bases de données à l’aide de la console Neptune. Sélectionnez **Bases de données** dans la colonne de gauche, puis sélectionnez votre cluster de bases de données dans le volet des bases de données. Les mises à jour en attente sont répertoriées dans la colonne **Maintenance**. Si vous sélectionnez **Actions** puis **Maintenance**, trois options s’offrent à vous quant à la marche à suivre : + Mettre à niveau maintenant. + Mettre à niveau lors de la fenêtre suivante. + Différer la mise à niveau. Vous pouvez répertorier les mises à jour du moteur en attente à l'aide de AWS CLI ce qui suit : ``` aws neptune describe-pending-maintenance-actions \ --resource-identifier (ARN of your DB cluster) --region (your region) \ --engine neptune ``` Vous pouvez également répertorier les mises à jour du moteur disponibles à l'aide AWS CLI des méthodes suivantes : ``` aws neptune describe-db-engine-versions \ --region (your region) \ --engine neptune ``` La liste des mises à jour du moteur disponibles inclut uniquement ces mises à jour ayant un numéro de version supérieur au numéro actuel et pour lequel un chemin de mise à niveau est défini. ## Toujours effectuer des tests avant la mise à niveau Lorsqu'une nouvelle version majeure ou mineure du moteur Neptune est publiée, testez toujours vos applications Neptune sur cette version avant de procéder à la mise à niveau. Une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d’affecter le code même sans modification majeure. Commencez par comparer les pages de notes de mise à jour de votre version actuelle à celles de la version cible pour déterminer s’il existe des modifications des versions de langage de requête ou d’autres modifications majeures. La meilleure façon de tester une nouvelle version avant de mettre à niveau votre cluster de base de données de production est d’utiliser la solution de [déploiement bleu/vert Neptune](neptune-BG-deployments.md). Ainsi, vous pouvez exécuter des applications et des requêtes sur la nouvelle version sans affecter votre cluster de bases de données de production. ## Toujours créer un instantané manuel avant de procéder à la mise à niveau Avant la mise à niveau, nous vous recommandons vivement de toujours créer un instantané manuel du cluster de bases de données. Un instantané automatique n'offre qu'une protection à court terme, tandis qu'un instantané manuel reste disponible jusqu'à ce que vous le supprimiez explicitement. Dans certains cas, Neptune crée un instantané manuel pour vous dans le cadre du processus de mise à niveau, mais il est préférable de ne pas compter sur ce mécanisme et de créer dans tous les cas votre propre instantané manuel. Lorsque vous êtes certain de ne pas avoir besoin de rétablir l'état antérieur à la mise à niveau de votre cluster de bases de données, vous pouvez supprimer explicitement l'instantané manuel que vous avez créé vous-même, ainsi que celui que Neptune a éventuellement créé. Si Neptune crée un instantané manuel, il porte un nom commençant par `preupgrade`, suivi du nom de votre cluster de bases de données, de la version du moteur source, de la version du moteur cible et de la date. ## Fenêtre de maintenance Neptune La fenêtre de maintenance hebdomadaire est une période de 30 minutes au cours de laquelle les mises à jour planifiées du moteur et les autres modifications du système sont appliquées. La plupart des événements de maintenance se terminent également au cours de la fenêtre de maintenance de 30 minutes, mais des événements de maintenance plus importants peuvent prendre plus de 30 minutes. Chaque cluster de bases de données dispose d’un créneau de maintenance hebdomadaire de 30 minutes. Si vous ne spécifiez pas d’heure préférée lors de la création du cluster de bases de données, Neptune choisit un jour de semaine au hasard, puis attribue au hasard un créneau de 30 minutes sur un bloc horaire de 8 heures qui varie en fonction de la région. Voici, par exemple, les blocs horaires de 8 heures pour les fenêtres de maintenance utilisées dans plusieurs régions AWS  : **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/engine-maintenance-management.html) La fenêtre de maintenance détermine le moment où les opérations en attente commencent, et la plupart des opérations de maintenance se terminent dans cette fenêtre, mais les tâches de maintenance plus importantes peuvent se poursuivre au-delà de l’heure de fin de la fenêtre. ### Modification de la fenêtre de maintenance de cluster de bases de données Idéalement, votre fenêtre de maintenance devrait tomber au moment où votre cluster est le moins utilisé. Si ce n’est pas le cas pour votre fenêtre actuelle, vous pouvez le déplacer vers un meilleur moment, comme ceci : **Pour modifier la fenêtre de maintenance de votre cluster de bases de données** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le volet de navigation, sélectionnez les **bases de données**. 1. Choisissez le cluster de bases de données pour lequel vous souhaitez modifier la fenêtre de maintenance. 1. Sélectionnez **Modify**. 1. Choisissez **Afficher plus** en bas de la page **Modifier le cluster**. 1. Dans la section **Fenêtre de maintenance préférée**, définissez le jour, l’heure et la durée de la fenêtre de maintenance comme vous le souhaitez. 1. Choisissez **Suivant**. Sur la page de confirmation, examinez vos modifications. 1. Pour appliquer immédiatement les modifications à la fenêtre de maintenance, sélectionnez **Appliquer immédiatement**. 1. Choisissez **Soumettre** pour enregistrer vos modifications. Pour modifier vos modifications, cliquez sur **Retour**, ou pour annuler vos modifications, choisissez **Annuler**. ## Utilisation AutoMinorVersionUpgrade pour contrôler les mises à jour automatiques des versions mineures **Important** `AutoMinorVersionUpgrade` n’est efficace que pour les mises à niveau de versions mineures supérieures à la [version 1.3.0.0 du moteur](engine-releases-1.3.0.0.md). Si le champ `AutoMinorVersionUpgrade` est défini sur `true` dans l’instance de dispositif d’écriture (principale) de votre cluster de base de données, les mises à jour de version mineures sont appliquées automatiquement à toutes les instances de votre cluster de bases de données lors de la fenêtre de maintenance suivante après leur publication. Si le champ `AutoMinorVersionUpgrade` est défini sur `false` dans l’instance de dispositif d’écriture de votre cluster de bases de données, ils ne sont appliqués que si vous [les installez explicitement](engine-updates-manually.md#engine-minor-updates-using-console). **Note** Les versions de correctifs (`*.*.*.1`, `*.*.*.2`, etc.) sont toujours installées automatiquement lors de votre prochaine fenêtre de maintenance, quel que soit le paramètre `AutoMinorVersionUpgrade` défini. Vous pouvez effectuer le réglage `AutoMinorVersionUpgrade` en utilisant AWS Management Console les options suivantes : **Pour définir `AutoMinorVersionUpgrade` à l’aide de la console Neptune** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**. 1. Sélectionnez l’instance principale (dispositif d’écriture) du cluster de bases de données pour lequel vous souhaitez procéder à la définition de `AutoMinorVersionUpgrade`. 1. Sélectionnez **Modifier**. 1. Choisissez **Afficher plus** en bas de la page **Modifier le cluster**. 1. Au bas de la page développée, choisissez **Activer la mise à niveau automatique de la version mineure** ou **Désactiver la mise à niveau automatique de la version mineure**. 1. Choisissez **Suivant**. Sur la page de confirmation, examinez vos modifications. 1. Pour appliquer les modifications à la mise à niveau automatique de version mineure, sélectionnez **Appliquer immédiatement**. 1. Choisissez **Soumettre** pour enregistrer vos modifications. Pour modifier vos modifications, cliquez sur **Retour**, ou pour annuler vos modifications, choisissez **Annuler**. Vous pouvez également utiliser le AWS CLI pour définir le `AutoMinorVersionUpgrade` champ. Par exemple, pour le définir sur `true`, vous pouvez utiliser une commande comme celle-ci : ``` 1. aws neptune modify-db-instance \ 2. --db-instance-identifier (the ID of your cluster's writer instance) \ 3. --auto-minor-version-upgrade \ 4. --apply-immediately ``` De même, pour le définir sur `false`, utilisez une commande comme celle-ci : ``` 1. aws neptune modify-db-instance \ 2. --db-instance-identifier (the ID of your cluster's writer instance) \ 3. --no-auto-minor-version-upgrade \ 4. --apply-immediately ``` # Installation manuelle des mises à jour de votre moteur Neptune ## Installation d’une mise à niveau de version majeure du moteur Les versions majeures du moteur doivent être installées manuellement. Pour minimiser les temps d’arrêt et laisser suffisamment de temps aux tests et à la validation, le meilleur moyen d’installer une nouvelle version majeure est généralement d’utiliser la [solution de déploiement bleu/vert Neptune](neptune-BG-deployments.md). Dans certains cas, vous pouvez également utiliser le CloudFormation modèle avec lequel vous avez créé votre cluster de base de données pour installer une mise à niveau de version majeure (voir[Utilisation d'un CloudFormation modèle pour mettre à jour la version du moteur de votre cluster de base de données Neptune](cfn-engine-update.md)). Si vous souhaitez installer une mise à jour de version majeure immédiatement, vous pouvez utiliser une commande CLI comme celle-ci : ``` aws neptune modify-db-cluster \ --db-cluster-identifier (identifier for your neptune cluster) \ --engine neptune \ --engine-version (the new engine version) \ --apply-immediately ``` Assurez-vous de spécifier la version du moteur vers laquelle vous voulez effectuer la mise à niveau. Dans le cas contraire, votre moteur pourra être mis à niveau vers une version autre que la plus récente ou que celle à laquelle vous vous attendez. Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à le spécifier avec ce paramètre : ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` De même, si des instances du cluster utilisent un groupe de paramètres de bases de données personnalisé, veillez à le spécifier avec ce paramètre : ``` ---db-instance-parameter-group-name (name of the custom instance parameter group) ``` ## Installation d'une mise à niveau du moteur d'une version mineure à l'aide du AWS Management Console **Pour effectuer une mise à niveau d’une version mineure à l’aide de la console Neptune** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, choisissez **Bases de données**, puis choisissez le cluster de bases de données que vous souhaitez modifier. 1. Sélectionnez **Modifier**. 1. Sous **Spécifications de l’instance**, choisissez la nouvelle version vers laquelle vous souhaitez procéder à la mise à niveau. 1. Choisissez **Suivant**. 1. Si vous souhaitez appliquer les modifications immédiatement, choisissez **Appliquer immédiatement**. 1. Choisissez **Soumettre** pour mettre à jour votre cluster de base de données. ## Installation d'une mise à niveau du moteur d'une version mineure à l'aide du AWS CLI Vous pouvez utiliser une commande comme la suivante pour effectuer une mise à niveau d’une version mineure sans attendre la fenêtre de maintenance suivante : ``` aws neptune modify-db-cluster \ --db-cluster-identifier (your-neptune-cluster) \ --engine-version (new-engine-version) \ --apply-immediately ``` Si vous effectuez une mise à niveau manuelle à l'aide du AWS CLI, veillez à inclure la version du moteur vers laquelle vous souhaitez effectuer la mise à niveau. Dans le cas contraire, votre moteur pourra être mis à niveau vers une version autre que la plus récente ou que celle à laquelle vous vous attendez. # Mise à niveau vers la version 1.2.0.0 ou supérieure du moteur à partir d'une version antérieure à 1.2.0.0 La [version 1.2.0.0 du moteur](engine-releases-1.2.0.0.md) inclut plusieurs modifications importantes qui peuvent compliquer plus que d’habitude toute mise à niveau à partir d’une version antérieure : + La [version 1.2.0.0 du moteur](engine-releases-1.2.0.0.md) implique un nouveau format pour les groupes de paramètres personnalisés et les groupes de paramètres de cluster personnalisés. Par conséquent, si vous effectuez une mise à niveau d'une version de moteur antérieure vers la version 1.2.0.0 ou une version supérieure, vous devrez recréer tous vos groupes de paramètres personnalisés et groupes de paramètres de cluster personnalisés existants à l'aide de la famille de groupes de paramètres `neptune1.2`. Les versions antérieures utilisaient une famille de groupes de paramètres `neptune1`, lesquels ne sont pas compatibles avec les versions 1.2.0.0 et supérieures. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md). + La version 1.2.0.0 du moteur a introduit un nouveau format pour les journaux d'annulation. Par conséquent, si vous effectuez une mise à niveau vers la version 1.2.0.0 ou supérieure à partir d'une version antérieure à 1.2.0.0, la [`UndoLogListSize`](cw-metrics.md#cw-metrics-UndoLogListSize)métrique doit être inférieure à un certain seuil. Dans le cas contraire, le correctif sera annulé et échouera. Les seuils sont basés sur le type d'instance : la limite par défaut est de 40 000 pour les instances 4 x grandes ou plus, et de 10 000 pour les instances inférieures à 4 x large. Si la limite `UndoLogListSize` dépasse la limite lorsque vous tentez de procéder à la mise à niveau, le processus de correction sera annulé, et un événement indiquant le motif sera visible sur la page des événements du cluster. Ces limites peuvent changer pour des raisons opérationnelles sans avertissement préalable. Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Le faire avant d'essayer de procéder à la mise à niveau peut aider à abaisser le seuil `UndoLogListSize` en dessous du seuil applicable. L'augmentation de la taille du dispositif d'écriture dans un type d'instance 24XL peut accroître le taux de purge, permettant ainsi de traiter plus d'un million d'enregistrements par heure. Si la `UndoLogListSize` CloudWatch métrique est extrêmement importante, l'ouverture d'un dossier de support peut vous aider à explorer des stratégies supplémentaires pour la ramener en dessous de la limite requise. + Enfin, une modification majeure a été apportée à la version 1.2.0.0. Celle-ci concerne le code antérieur qui utilisait le protocole Bolt avec l'authentification IAM. À partir de la version 1.2.0.0, Bolt a besoin d'un chemin de ressources pour la signature IAM. En Java, la définition du chemin de ressources peut ressembler à ceci : `request.setResourcePath("/openCypher"));`. Dans d'autres langages, `/openCypher` peut être ajouté à l'URI du point de terminaison. Pour obtenir des exemples, consultez [Utilisation du protocole Bolt](access-graph-opencypher-bolt.md). # Utilisation d'un CloudFormation modèle pour mettre à jour la version du moteur de votre cluster de base de données Neptune Vous pouvez réutiliser le modèle CloudFormation Neptune que vous avez utilisé pour créer votre cluster de base de données Neptune afin de mettre à jour la version de son moteur. Les mises à niveau des versions du moteur Neptune peuvent être mineures ou majeures. L'utilisation d'un CloudFormation modèle peut faciliter les mises à niveau des versions majeures, qui contiennent souvent des modifications importantes. Comme les mises à niveau de version majeures peuvent contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes, vous devrez peut-être également apporter des modifications à vos applications lors de la mise à niveau. [Effectuez toujours des tests avant la mise à niveau](engine-maintenance-management.md#always-test-before-upgrading). Nous vous recommandons aussi vivement de toujours créer un instantané manuel de votre cluster de bases de données avant la mise à niveau. Notez que vous devez effectuer une mise à niveau du moteur distincte pour chaque version majeure. Vous ne pouvez pas ignorer une version majeure et passer directement à la version majeure suivante. Avant le 17 mai 2023, si vous utilisiez la CloudFormation pile Neptune pour mettre à niveau la version de votre moteur, elle créait simplement un nouveau cluster de base de données vide à la place de votre cluster actuel. Cependant, depuis le 17 mai 2023, la suite Neptune prend désormais en charge les mises CloudFormation à niveau du moteur sur place qui préservent vos données existantes. **Note** Si vous utilisez le AWS Cloud Development Kit (AWS CDK), assurez-vous que la AWS CDK version utilisée est 2.82.0 ou ultérieure. Les versions antérieures à 2.82.0 ne prennent pas en charge les mises à niveau sur place du moteur Neptune. Pour une mise à niveau de version majeure, votre modèle doit définir les propriétés suivantes dans `DBCluster` : + `DBClusterParameterGroup` (personnalisé ou par défaut) + `DBInstanceParameterGroupName` + `EngineVersion` De même, pour DBInstances attached to, DBCluster vous devez définir : + `DBParameterGroup` (personnalisé/par défaut) Assurez-vous que tous vos groupes de paramètres sont définis dans le modèle, qu'ils soient par défaut ou personnalisés. Dans le cas d'un groupe de paramètres personnalisé, assurez-vous que la famille de votre groupe de paramètres personnalisé existant est compatible avec la nouvelle version du moteur. Les versions du moteur antérieures à [1.2.0.0](engine-releases-1.2.0.0.md) utilisaient une famille de groupes de paramètres `neptune1`, tandis que les versions du moteur à compter de la version 1.2.0.0 nécessitent une famille de groupes de paramètres `neptune1.2`. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md). Pour les mises à niveau majeures des versions du moteur, spécifiez un groupe de paramètres avec la famille appropriée dans le champ `DBInstanceParameterGroupName` de `DBCluster`. Un groupe de paramètres par défaut doit être mis à niveau vers un groupe compatible avec la nouvelle version du moteur. Notez que Neptune redémarre automatiquement les instances de base de données après une mise à niveau du moteur. **Topics** + [ # Exemple : mise à niveau mineure du moteur de la version 1.2.0.1 vers la version 1.2.0.2 ](cfn-engine-update-1201-1202.md) + [ # Exemple : mise à niveau majeure de la version 1.1.1.0 vers 1.2.0.2 avec des groupes de paramètres par défaut ](cfn-engine-update-1110-1202-default.md) + [ # Exemple : mise à niveau majeure de la version 1.1.1.0 vers 1.2.0.2 avec des groupes de paramètres personnalisés ](cfn-engine-update-1110-1202-custom.md) + [ # Exemple : mise à niveau majeure de la version 1.1.1.0 vers 1.2.0.2 avec une combinaison de groupes de paramètres par défaut et de groupes de paramètres personnalisés ](cfn-engine-update-1110-1202-mixed.md) # Exemple : mise à niveau mineure du moteur de la version 1.2.0.1 vers la version 1.2.0.2 Recherchez le cluster de bases de données que vous souhaitez mettre à niveau, ainsi que le modèle que vous avez utilisé pour le créer. Par exemple : ``` Description: Base Template to create Neptune Stack with Engine Version 1.2.0.1 using custom Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Family: neptune1.2 Description: test-cfn-neptune-db-cluster-parameter-group-description Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Family: neptune1.2 Description: test-cfn-neptune-db-parameter-group-description Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.1 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DependsOn: - NeptuneDBClusterParameterGroup NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` Mettez à jour la propriété `EngineVersion` en remplaçant `1.2.0.1` par `1.2.0.2` : ``` Description: Template to upgrade minor engine version to 1.2.0.2 Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Family: neptune1.2 Description: test-cfn-neptune-db-cluster-parameter-group-description Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Family: neptune1.2 Description: test-cfn-neptune-db-parameter-group-description Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.2 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DependsOn: - NeptuneDBClusterParameterGroup NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` Utilisez-le maintenant CloudFormation pour exécuter le modèle révisé. # Exemple : mise à niveau majeure de la version 1.1.1.0 vers 1.2.0.2 avec des groupes de paramètres par défaut Recherchez le `DBCluster` que vous souhaitez mettre à niveau, ainsi que le modèle que vous avez utilisé pour le créer. Par exemple : ``` Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using default Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.1.1.0 NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DependsOn: - NeptuneDBCluster Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` + Remplacez la valeur `DBClusterParameterGroup` par défaut par celle de la famille de groupes de paramètres utilisée par la nouvelle version du moteur (ici `default.neptune1.2`). + Pour chaque élément `DBInstance` rattaché au `DBCluster`, remplacez la valeur `DBParameterGroup` par défaut par celle de la famille utilisée par la nouvelle version du moteur (ici `default.neptune1.2`). + Définissez la propriété `DBInstanceParameterGroupName` sur le groupe de paramètres par défaut de cette famille (ici `default.neptune1.2`). + Mettez à jour la propriété `EngineVersion` en remplaçant `1.1.0.0` par `1.2.0.2`. Le modèle devrait se présenter comme suit : ``` Description: Template to upgrade major engine version to 1.2.0.2 by using upgraded default parameter groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.2 DBClusterParameterGroupName: default.neptune1.2 DBInstanceParameterGroupName: default.neptune1.2 NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: default.neptune1.2 DependsOn: - NeptuneDBCluster Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: ``` Utilisez-le maintenant CloudFormation pour exécuter le modèle révisé. # Exemple : mise à niveau majeure de la version 1.1.1.0 vers 1.2.0.2 avec des groupes de paramètres personnalisés Recherchez le `DBCluster` que vous souhaitez mettre à niveau, ainsi que le modèle que vous avez utilisé pour le créer. Par exemple : ``` Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using custom Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Name: engineupgradetestcpg Family: neptune1 Description: 'NeptuneDBClusterParameterGroup with family neptune1' Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Name: engineupgradetestpg Family: neptune1 Description: 'NeptuneDBParameterGroup1 with family neptune1' Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.1.1.0 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DependsOn: - NeptuneDBClusterParameterGroup NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` + Mettez à jour la `DBClusterParameterGroup` famille personnalisée avec celle utilisée par la nouvelle version du moteur `default.neptune1.2` (ici). + Pour chaque `DBInstance` élément attaché au`DBCluster`, mettez à jour la `DBParameterGroup` famille personnalisée en fonction de celle utilisée par la nouvelle version du moteur (ici`default.neptune1.2`). + Définissez la propriété `DBInstanceParameterGroupName` sur le groupe de paramètres de cette famille (ici `default.neptune1.2`). + Mettez à jour la propriété `EngineVersion` en remplaçant `1.1.0.0` par `1.2.0.2`. Le modèle devrait se présenter comme suit : ``` Description: Template to upgrade major engine version to 1.2.0.2 by modifying existing custom parameter groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Name: engineupgradetestcpgnew Family: neptune1.2 Description: 'NeptuneDBClusterParameterGroup with family neptune1.2' Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Name: engineupgradetestpgnew Family: neptune1.2 Description: 'NeptuneDBParameterGroup1 with family neptune1.2' Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.2 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DBInstanceParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBClusterParameterGroup NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` Utilisez-le maintenant CloudFormation pour exécuter le modèle révisé. # Exemple : mise à niveau majeure de la version 1.1.1.0 vers 1.2.0.2 avec une combinaison de groupes de paramètres par défaut et de groupes de paramètres personnalisés Recherchez le `DBCluster` que vous souhaitez mettre à niveau, ainsi que le modèle que vous avez utilisé pour le créer. Par exemple : ``` Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using custom Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Family: neptune1 Description: 'NeptuneDBClusterParameterGroup with family neptune1' Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Family: neptune1 Description: 'NeptuneDBParameterGroup with family neptune1' Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.1.1.0 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DependsOn: - NeptuneDBClusterParameterGroup CustomNeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup DefaultNeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DependsOn: - NeptuneDBCluster Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` + Pour un groupe de paramètres de cluster personnalisé, mettez à jour la famille `DBClusterParameterGroup` en utilisant celle correspondant à la nouvelle version du moteur, à savoir `neptune1.2`. + Pour un groupe de paramètres de cluster par défaut, mettez à jour la valeur `DBClusterParameterGroup` en utilisant la valeur par défaut correspondant à la nouvelle version du moteur, à savoir `default.neptune1.2`. + Pour chaque élément `DBInstance` attaché au `DBCluster`, remplacez un élément `DBParameterGroup` par défaut par celui de la famille utilisée par la nouvelle version du moteur (ici `default.neptune1.2`), et un groupe de paramètres personnalisé par celui qui utilise la famille prise en charge par la nouvelle version du moteur (ici `neptune1.2`). + Définissez la propriété `DBInstanceParameterGroupName` sur le groupe de paramètres de la famille, pris en charge par la nouvelle version du moteur. Le modèle devrait se présenter comme suit : ``` Description: Template to update Neptune Stack to Engine Version 1.2.0.1 using custom and default Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Family: neptune1.2 Description: 'NeptuneDBClusterParameterGroup with family neptune1.2' Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Family: neptune1.2 Description: 'NeptuneDBParameterGroup1 with family neptune1.2' Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.2 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DBInstanceParameterGroupName: default.neptune1.2 DependsOn: - NeptuneDBClusterParameterGroup CustomNeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup DefaultNeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: default.neptune1.2 DependsOn: - NeptuneDBCluster Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` Utilisez-le maintenant CloudFormation pour exécuter le modèle révisé. # Clonage de bases de données dans Neptune Le clonage de base de données vous permet de créer de façon rapide et économique des clones de toutes vos bases de données dans Amazon Neptune. Les bases de données clone n'ont besoin que d'un espace supplémentaire minime au moment où elles sont créées. Le clonage de base de données utilise un *copy-on-write protocole*. Les données sont copiées au moment où elles sont modifiées, que ce soit dans les bases de données source ou les bases de données clone. Vous pouvez créer plusieurs clones du même cluster de base de données. Vous pouvez également créer des clones supplémentaires à partir d'autres clones. Pour plus d'informations sur le fonctionnement copy-on-write du protocole dans le contexte du stockage Neptune, consultez. [Copy-on-Write Protocole](#manage-console-cloning-protocol) Vous pouvez utiliser le clonage de base de données dans divers cas d'utilisation, notamment lorsque vous ne voulez pas affecter votre environnement de production, comme dans les exemples suivants : + Expérimentation et évaluation de l'impact de modifications, telles que des modifications du schéma ou des modifications du groupe de paramètres. + Réalisation d'opérations imposant une charge de travail élevée, telles que l'exportation de données ou l'exécution de requêtes analytiques. + Création d'une copie d'un cluster de base de données de production dans un environnement autre que de production pour le développement ou les tests. **Pour créer un clone d'un cluster de base de données à l'aide du AWS Management Console** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, choisissez **Instances**. Choisissez l'instance principale pour le cluster de base de données dont vous voulez créer un clone. 1. Choisissez **Instance actions (Actions d'instance)**, puis **Create clone (Créer un clone)**. 1. Dans la page **Create Clone (Créer un clone)**, entrez un nom pour l'instance principale du cluster de base de données clone dans le champ **DB instance identifier (Identifiant d'instance DB)**. Configurez éventuellement d'autres paramètres pour le cluster de base de données clone. Pour plus d'informations sur les différents paramètres de cluster de base de données, consultez [Lancement à l'aide de la console](manage-console-launch-console.md). 1. Choisissez **Create Clone (Créer un clone)** pour lancer le cluster de base de données clone. **Pour créer un clone d'un cluster de base de données à l'aide du AWS CLI** + Appelez la point-in-time AWS CLI commande Neptune [restore-db-cluster-to-](api-snapshots.md#RestoreDBClusterToPointInTime) et saisissez les valeurs suivantes : + `--source-db-cluster-identifier` : nom du cluster de bases de données source à partir duquel un clone doit être créé. + `--db-cluster-identifier` : nom du cluster de bases de données clone. + `--restore-type copy-on-write` : la valeur `copy-on-write` indique qu'un cluster de bases de données clone doit être créé. + `--use-latest-restorable-time` : précise que la dernière heure de sauvegarde restaurable doit être utilisée. **Note** La point-in-time AWS CLI commande [restore-db-cluster-to-](api-snapshots.md#RestoreDBClusterToPointInTime) clone uniquement le cluster de base de données, et non les instances de base de données pour ce cluster de base de données. L' Linux/UNIX exemple suivant crée un clone à partir du `source-db-cluster-id` cluster de base de données et le nomme`db-clone-cluster-id`. ``` aws neptune restore-db-cluster-to-point-in-time \ --region us-east-1 \ --source-db-cluster-identifier source-db-cluster-id \ --db-cluster-identifier db-clone-cluster-id \ --restore-type copy-on-write \ --use-latest-restorable-time ``` Le même exemple fonctionne sur Windows si le caractère d'échappement de fin de ligne `\` est remplacé par l'équivalent Windows `^` : ``` aws neptune restore-db-cluster-to-point-in-time ^ --region us-east-1 ^ --source-db-cluster-identifier source-db-cluster-id ^ --db-cluster-identifier db-clone-cluster-id ^ --restore-type copy-on-write ^ --use-latest-restorable-time ``` ## Limites Le clonage de base de données dans Neptune présente les limites suivantes : + Vous ne pouvez pas créer de bases de données AWS clonées dans différentes régions. Les bases de données clone doivent être créées dans la même région que les bases de données source. + Une base de données clonée utilise toujours le correctif le plus récent de la version du moteur Neptune utilisée par la base de données à partir de laquelle elle a été clonée. Ceci est vrai même si la base de données source n'a pas encore été mise à niveau vers cette version de correctif. Cependant, la version du moteur elle-même ne change pas. + Actuellement, vous êtes limité à 15 clones par copie du cluster de bases de données Neptune, ce qui comprend les clones basés sur d'autres clones. Une fois cette limite atteinte, vous devez effectuer une autre copie de votre base de données plutôt que de la cloner. Cependant, si vous créez une autre copie, elle peut aussi avoir jusqu'à 15 clones. + Le clonage de base de données entre comptes n'est pas pris en charge actuellement. + Vous pouvez fournir un réseau Virtual Private Cloud (VPC) différent pour votre clone. Toutefois, les sous-réseaux qu'ils contiennent VPCs doivent correspondre au même ensemble de zones de disponibilité. ## Copy-on-Write Protocole pour le clonage de bases de données Les scénarios suivants illustrent le fonctionnement copy-on-write du protocole. + [Base de données Neptune avant le clonage](#manage-console-cloning-protocol-before) + [Base de données Neptune après le clonage](#manage-console-cloning-protocol-after) + [Lorsqu'une modification est apportée à la base de données source](#manage-console-cloning-protocol-source-write) + [Lorsqu'une modification est apportée à la base de données clone](#manage-console-cloning-protocol-clone-write) ### Base de données Neptune avant le clonage Les données figurant dans une base de données source sont stockées dans des pages. Dans le schéma ci-dessous, la base de données source comporte quatre pages. ![\[Base de données source Neptune avant le clonage de base de données avec 4 pages.\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/neptune-clone-1.png) ### Base de données Neptune après le clonage Comme le montre le schéma suivant, aucune modification n'a été apportée à la base de données source après le clonage de base de données. La base de données source et la base de données clone pointent toutes les deux sur les quatre mêmes pages. Aucune page n'a été copiée physiquement et aucun stockage supplémentaire n'est nécessaire. ![\[Base de données source Neptune et base de données clone pointant vers les mêmes pages après le clonage.\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/neptune-clone-2.png) ### Lorsqu'une modification est apportée à la base de données source Dans l'exemple suivant, la base de données source apporte une modification aux données de la `Page 1`. Au lieu d'écrire dans la `Page 1` d'origine, il utilise un stockage supplémentaire pour créer une nouvelle page, appelée `Page 1'`. La base de données source pointe maintenant sur la nouvelle `Page 1'`, ainsi que sur la `Page 2`, la `Page 3` et la `Page 4`. La base de données clone continue de pointer sur les `Page 1` à `Page 4`. ![\[Base de données source et base de données clone après une modification de la base de données source.\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/neptune-clone-3.png) ### Lorsqu'une modification est apportée à la base de données clone Dans le schéma ci-dessous, la base de données clone a également été modifiée, cette fois au niveau de la `Page 4`. Au lieu d'écrire dans la page `Page 4` d’origine, un stockage supplémentaire est utilisé pour créer une nouvelle page, appelée `Page 4'`. La base de données source continue à pointer vers la `Page 1'`, ainsi que vers les pages `Page 2` à `Page 4`, mais la base de données clone pointe maintenant vers les pages `Page 1` à `Page 3`, ainsi que vers la `Page 4'`. ![\[Base de données source Neptune et base de données clone, après une modification de la base de données clone.\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/neptune-clone-4.png) Comme le montre le deuxième scénario, après le clonage de base de données, aucun stockage supplémentaire n'est nécessaire au stade de la création du clone. Toutefois, lorsque des modifications interviennent dans la base de données source et la base de données clone, comme le montrent les troisième et quatrième scénarios, seules les pages modifiées sont créées. Lorsque des modifications supplémentaires interviennent au fil du temps dans la base de données source et la base de données clone, vous avez besoin de plus de stockage pour capturer et stocker ces modifications. ## Suppression d'une base de données source La suppression d'une base de données source n'affecte pas les bases de données clone qui lui sont associées. Les bases de données clones continuent de pointer sur les pages qui étaient précédemment la propriété de la base de données source. # Gestion des instances Amazon Neptune Les sections suivantes fournissent des informations sur les opérations réalisées au niveau de l'instance. **Topics** + [ # Classe d'instances extensible T3 Neptune ](manage-console-instances-t3.md) + [ # Modification d'une instance de base de données Neptune (et application immédiate) ](manage-console-instances-modify.md) + [ # Changement de nom d'une instance de base de données Neptune ](manage-console-instances-rename.md) + [ # Redémarrage d'une instance de base de données dans Amazon Neptune ](manage-console-instances-reboot.md) + [ # Suppression d'une instance de base de données dans Amazon Neptune ](manage-console-instances-delete.md) # Classe d'instances extensible T3 Neptune En plus des classes d'instances à performances fixes telles que `R5` et `R6`, Amazon Neptune offre la possibilité d'utiliser une instance `T3` à performances extensibles. Lorsque vous développez votre application orientée graphe, il est important que votre base de données soit rapide et réactive, mais vous n'avez pas besoin de l'utiliser en permanence. La classe d'instances `db.t3.medium` de Neptune est exactement ce que vous devez utiliser dans ce cas, à un coût nettement inférieur à celui de la classe d'instances à performances fixes la moins chère. Une instance extensible fonctionne à un niveau de base de performances de l’UC. Lorsqu’une charge de travail demande davantage, l’instance dépasse largement ce niveau de base aussi longtemps que nécessaire. Son prix horaire couvre les pics, à condition que l'utilisation moyenne de l'UC ne dépasse pas le niveau de base sur une période de 24 heures. Pour la plupart des situations de développement et de test, cela se traduit par de bonnes performances à faible coût. Si vous commencez par une classe d'`T3`instance, vous pouvez facilement passer ultérieurement à une classe d'instance à performances fixes lorsque vous serez prêt à passer en production, en utilisant le AWS Management Console AWS CLI, ou l'un des. AWS SDKs ## L'extension T3 est régie par les crédits d’UC Un crédit d’UC représente l'utilisation complète d'un cœur d’UC virtuelle (vCPU) pendant une minute. Cela peut également se traduire par une utilisation de 50 % d'un vCPU pendant deux minutes, ou une utilisation de 25 % de deux vCPU CPUs pendant deux minutes, etc. Une instance `T3` accumule des crédits d’UC lorsqu'elle est inactive et les utilise lorsqu'elle est active, selon une résolution de mesures en millisecondes. La classe d'`db.t3.medium`instance possède deux vCPUs, dont chacun rapporte 12 crédits CPU par heure lorsqu'il est inactif. Cela signifie que 20 % d'utilisation de chaque UC virtuelle se traduit par un solde égal à zéro UC. Les 12 crédits d’UC gagnés sont dépensés par les 20 % d'utilisation de l’UC virtuelle (20 % de 60 minutes étant égal à 12). Cette utilisation de 20 % correspond donc au taux d'utilisation *de base* qui produit un solde de crédit d’UC ni positif ni négatif. Le temps d'inactivité (utilisation de l’UC inférieure à 20 % du total disponible) entraîne le stockage des crédits d’UC dans un compartiment de solde de crédit, jusqu'à la limite de 576 pour une classe d'instance `db.t3.medium`(nombre maximal de crédits d’UC pouvant être accumulés en 24 heures, soit 2 x 12 x 24). Au-delà de cette limite, les crédits d’UC sont simplement éliminés. Si nécessaire, l'utilisation de l'UC peut atteindre 100 % aussi longtemps que nécessaire pour une charge de travail, même si le solde de crédits d'UC passe en dessous de zéro. Si l'instance conserve un solde négatif en continu pendant 24 heures, des frais supplémentaires équivalents à 0,05 USD par tranche de -60 crédits d’UC accumulés au cours de cette période seront facturés. Toutefois, pour la plupart des charges de travail de développement et de test, les pics sont généralement couverts par les temps d'inactivité avant ou après. **Note** La classe d'`T3`instance de Neptune est configurée comme le [mode Amazon EC2 unlimited.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) ## Utilisation du AWS Management Console pour créer une instance T3 Burstable Dans le AWS Management Console, vous pouvez créer une instance de cluster de base de données principale ou une instance en lecture qui utilise la classe d'`db.t3.medium`instance, ou vous pouvez modifier une instance existante pour utiliser la classe d'`db.t3.medium`instance. Par exemple, pour créer une instance principale de cluster de bases de données dans la console Neptune : + Choisissez **Create database** (Créer une base de données). + Choisissez une **version de moteur de base de données** égale ou ultérieure à `1.0.2.2`. + Sous **Purpose (Objet)**, choisissez **Development and Testing (Développement et Test)**. + Pour **DB instance class (Classe d'instance de base de données)**, acceptez la valeur par défaut : `db.t3.medium — 2 vCPU, 4 GiB RAM`. ## Utilisation du AWS CLI pour créer une instance T3 Burstable Vous pouvez également utiliser le AWS CLI pour faire la même chose : ``` aws neptune create-db-cluster \ --db-cluster-identifier (name for a new DB cluster) \ --engine neptune \ --engine-version "1.0.2.2" aws neptune create-db-instance \ --db-cluster-identifier (name of the new DB cluster) \ --db-instance-identifier (name for the primary writer instance in the cluster) \ --engine neptune \ --db-instance-class db.t3.medium ``` # Modification d'une instance de base de données Neptune (et application immédiate) Vous pouvez appliquer la plupart des modifications apportées à une instance de base de données Amazon Neptune immédiatement ou les reporter à la fenêtre de maintenance suivante. Certaines modifications, telles que les modifications d'un groupe de paramètres, nécessitent que vous redémarriez manuellement votre instance de base de données pour que la modification entre en vigueur. **Important** Les modifications entraînent une interruption si Neptune doit redémarrer votre instance de base de données pour qu'elles soient appliquées. Analysez l'impact sur votre base de données et les applications avant de modifier vos paramètres d'instance de base de données. ## Paramètres courants et implications sur les temps d'arrêt. Le tableau suivant contient des détails sur les paramètres que vous pouvez modifier, et indique quand les modifications peuvent être appliquées et si les modifications entraînent un temps d'arrêt pour l'instance de base de données. **** | Paramètres de l'instance de base de données | Remarques sur la durée d’indisponibilité | | --- | --- | | **Classe d'instances de base de données** | Une interruption a lieu lors de cette modification, qu'elle soit appliquée immédiatement ou lors de la fenêtre de maintenance suivante. | | **Identifiant d’instance de base de données** | L'instance de base de données est redémarrée, et une interruption a lieu lors de cette modification, qu'elle soit appliquée immédiatement ou lors de la fenêtre de maintenance suivante. | | **Groupe de sous-réseaux** | L'instance de base de données est redémarrée, et une interruption a lieu lors de cette modification, qu'elle soit appliquée immédiatement ou lors de la fenêtre de maintenance suivante. | | **Groupe de sécurité** | La modification est appliquée de manière asynchrone dès que possible, quelle que soit la date à laquelle vous spécifiez que les modifications doivent avoir lieu, et aucune interruption n'en résulte. | – | | **Autorité de certification** | Par défaut, l'instance de base de données est redémarrée lorsque vous attribuez une nouvelle autorité de certification. | | **Database Port** | La modification se produit toujours immédiatement, ce qui entraîne le redémarrage de l'instance de base de données et une interruption. | | **Groupe de paramètres de base de données** | La modification de ce paramètre n'entraîne pas d'interruption. Le nom du groupe de paramètres lui-même est immédiatement changé, mais les modifications réelles des paramètres ne prennent effet qu'après le redémarrage de l'instance, sans basculement. Dans ce cas, l'instance de base de données n'est pas automatiquement redémarrée, et les modifications de paramètre ne sont pas appliquées pendant la fenêtre de maintenance suivante. Toutefois, si vous modifiez des paramètres dynamiques dans le groupe de paramètres de base de données nouvellement associé, ces modifications sont appliquées immédiatement sans redémarrage. Pour de plus amples informations, veuillez consulter [Redémarrage d'une instance de base de données dans Amazon Neptune](manage-console-instances-reboot.md). | | **Groupe de paramètres de cluster de bases de données** | La modification du groupe de paramètres de base de données a lieu immédiatement. | | **Période de rétention des sauvegardes** | Si vous spécifiez que les modifications doivent intervenir immédiatement, cette modification a lieu immédiatement. Dans le cas contraire, si vous remplacez le paramètre d'une valeur non nulle par une autre valeur non nulle, la modification est appliquée de manière asynchrone dès que possible. Toute autre modification sera appliquée pendant la fenêtre de maintenance suivante. Une interruption se produit si vous passez de 0 à une valeur non nulle, ou d'une valeur non nulle à 0. | | **Journal d'audit** | Sélectionnez **Journal d'audit** si vous souhaitez utiliser la journalisation d'audit via CloudWatch Logs. Vous devez également définir le paramètre `neptune_enable_audit_log` du groupe de paramètres du cluster de bases de données sur `enable` (1) pour que la journalisation des audits soit activée. | | **Mise à niveau automatique de versions mineures** | Sélectionnez **Activer la mise à niveau automatique des versions mineures** si vous souhaitez que votre cluster de bases de données Neptune reçoive automatiquement les mises à niveau des versions mineures lors de leur publication. L'option *Mise à niveau automatique des versions mineures* s'applique uniquement aux mises à niveau des versions mineures pour votre cluster de bases de données Amazon Neptune. Elle ne s’applique pas aux correctifs réguliers appliqués pour maintenir la stabilité du système. | # Changement de nom d'une instance de base de données Neptune Vous pouvez renommer une instance de base de données Amazon Neptune à l'aide de la AWS Management Console. Renommer une instance de base de données peut avoir des effets à grande portée. La liste suivante correspond à ce que vous devez savoir avant de renommer une instance de base de données. + Lorsque vous renommez une instance de base de données, le point de terminaison de cette dernière change, parce que l'URL inclut le nom que vous avez attribué à l'instance de base de données. Vous devez toujours rediriger le trafic de l'ancienne URL vers la nouvelle. + Lorsque vous renommez une instance de base de données, l'ancien nom DNS qui a été utilisé par l'instance de base de données est immédiatement supprimé, mais peut rester dans le cache quelques minutes. Le nouveau nom DNS de l'instance de base de données renommée devient effectif après environ 10 minutes. L'instance de base de données renommée n'est pas disponible jusqu'à ce que le nouveau nom ne devienne effectif. + Vous ne pouvez pas utiliser un nom d'instance de base de données existant lorsque vous renommez une instance. + Tous les réplicas en lecture associés à une instance de base de données demeurent associés à cette instance une fois qu'elle a été renommée. Supposons par exemple que vous ayez une instance de base de données qui desserve votre base de données de production et que l'instance ait plusieurs réplicas en lecture associés. Si vous renommez l'instance de base de données, puis la remplacez dans l'environnement de production par un instantané de base de données, l'instance de base de données que vous avez renommée conserve les réplicas en lecture associés. + Les métriques et les événements associés au nom d'une instance de base de données sont conservés si vous réutilisez un nom d'instance de base de données. Par exemple, si vous effectuez la promotion d'un réplica en lecture et que vous remplacez son nom par celui de l'instance de base de données principale précédente, les événements et les métriques qui étaient associés à l'instance de base de données principale sont associés à l'instance renommée. + Les balises de l'instance de base de données demeurent avec l'instance de base de données, quel que soit le changement de nom. + Les snapshots DB sont conservés pour une instance de base de données renommée. **Pour renommer une instance de base de données à l'aide de la console Neptune** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**. 1. Cochez la case en regard de l'instance de base de données que vous voulez renommer. 1. Dans le menu **Instance Actions (Actions sur l'instance)**, sélectionnez **Modify (Modifier)**. 1. Saisissez un nouveau nom dans la zone de texte **DB Instance Identifier (Identifiant d’instance de base de données)**. Sélectionnez **Apply immediately (Appliquer immédiatement)**, puis choisissez **Continue (Continuer)**. 1. Choisissez **Modify DB instance (Modifier l'instance de base de données)** pour terminer la modification. # Redémarrage d'une instance de base de données dans Amazon Neptune Dans certains cas, si vous modifiez une instance de base de données Amazon Neptune, le groupe de paramètres de base de données associé à l'instance ou un paramètre de base de données statique dans un groupe de paramètres que l'instance utilise, vous devez redémarrer l'instance pour que ces modifications soient appliquées. Le redémarrage d'une instance de base de données entraîne celui du service du moteur de base de données. Un redémarrage applique également à l'instance de base de données toutes les modifications du groupe de paramètres de base de données associé qui étaient en attente. Le redémarrage d'une instance de base de données entraîne une interruption momentanée de l'instance, au cours de laquelle le statut de l'instance de base de données est défini sur *rebooting*. Si l'instance Neptune est configurée pour les déploiements multi-AZ, le redémarrage peut être effectué avec un basculement. Un événement Neptune est créé lorsque le redémarrage est terminé. Si votre instance de base de données est un déploiement Multi-AZ, vous pouvez forcer un basculement d'une zone de disponibilité vers une autre lorsque vous choisissez l'option **Reboot (Redémarrer)**. Lorsque vous forcez un basculement de votre instance de base de données, Neptune bascule automatiquement vers un réplica de secours dans une autre zone de disponibilité. Ensuite, elle met à jour l'enregistrement DNS pour que l'instance de base de données pointe vers l'instance de base de données en veille. Par conséquent, vous devez nettoyer et rétablir toutes les connexions existantes à votre instance de bases de données. **Reboot with failover (Redémarrer avec basculement)** présente un avantage lorsque vous souhaitez simuler une défaillance d'une instance de base de données à des fins de test, ou restaurer la zone de disponibilité d'origine des opérations après un basculement. Pour en savoir plus, consultez la section [Haute disponibilité (Multi-AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) dans le *Guide de l'utilisateur Amazon RDS*. Lorsque vous redémarrez un cluster de base de données, il bascule vers le réplica de secours. Le redémarrage d'un réplica Neptune ne déclenche pas de basculement. Le temps nécessaire au redémarrage est une fonction du processus de récupération sur incident. Pour améliorer le délai de redémarrage, nous vous recommandons de réduire les activités de bases de données autant que possible pendant le processus de redémarrage pour réduire l'activité de restauration pour les transactions en transit. Sur la console, l'option **Reboot (Redémarrer)** peut être désactivée si l'instance de base de données n'est pas dans l'état **Available (Disponible)**. Cela peut être dû à plusieurs raisons, par exemple une sauvegarde en cours, une modification demandée par le client ou encore une action du créneau de maintenance. **Note** Avant la [Sortie : 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), toutes les instances de réplica en lecture d'un cluster de bases de données étaient automatiquement redémarrées lors du redémarrage de l'instance (d'enregistreur) principale. À compter de la [Sortie : 1.2.0.0 (21/07/2022)](engine-releases-1.2.0.0.md), le redémarrage de l'instance principale n'entraîne le redémarrage d'aucun des réplicas. Dès lors, si vous modifiez un paramètre du cluster, vous devez redémarrer chaque instance séparément pour que cette modification de paramètre s'applique (voir [Groupes de paramètres](parameter-groups.md)). **Pour redémarrer une instance de base de données à l'aide de la console Neptune** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**. 1. Choisissez l'instance de base de données que vous souhaitez redémarrer. 1. Choisissez **Actions d'instance**, puis **Redémarrer**. 1. Pour forcer un basculement d'une zone de disponibilité à une autre, sélectionnez **Reboot with failover? (Redémarrer avec basculement ?)** dans la boîte de dialogue **Reboot DB Instance (Redémarrer l'instance de base de données)**. 1. Choisissez **Redémarrer**. Pour annuler le redémarrage, choisissez **Cancel (Annuler)**. # Suppression d'une instance de base de données dans Amazon Neptune Vous pouvez supprimer une instance de base de données Amazon Neptune dans n'importe quel état et à tout moment, tant que l'instance a été démarrée. **Avertissement** Si vous supprimez la dernière instance restante d'un cluster à l'aide de la **console Web**, le volume de stockage du cluster sous-jacent sera également supprimé. ## Prise d'un instantané final de votre instance de base de données avant de la supprimer Pour supprimer une instance de base de données, vous devez spécifier le nom de l'instance et préciser si vous voulez qu'il soit pris un instantané de base de données final de l'instance. Si l'instance de base de données que vous supprimez a le statut **Creating**, il n'est pas possible de prendre un instantané de base de données final. Si l'instance de base de données est dans un état d'échec avec le statut **failed**, **incompatible-restore** ou **incompatible-network**, vous pouvez uniquement supprimer l'instance quand le paramètre `SkipFinalSnapshot` a la valeur `true`. Si vous supprimez toutes les instances de base de données Neptune d'un cluster de base de données à l'aide de AWS Management Console, l'ensemble du cluster de base de données est automatiquement supprimé. Si vous utilisez le SDK AWS CLI ou le SDK, vous devez supprimer le cluster de base de données manuellement après avoir supprimé la dernière instance. **Important** Si vous supprimez un cluster de bases de données entier, toutes ses sauvegardes automatiques sont supprimées en même temps et ne peuvent pas être récupérées. En d'autres termes, si vous ne choisissez pas de créer manuellement un instantané de bases de données final, vous ne pourrez pas restaurer l'instance de base de données à son état final ultérieurement. Les instantanés manuels d'une instance ne sont pas supprimés lorsque vous supprimez un cluster. Si l'instance de base de données que vous souhaitez supprimer possède un réplica en lecture, vous devez promouvoir ce dernier ou le supprimer. Dans les exemples suivants, vous supprimez une instance de base de données avec et sans snapshot DB final. ## Suppression d'une instance de base de données sans snapshot final Si vous voulez supprimer rapidement une instance de base de données, vous pouvez ignorer la création d'un instantané de base de données final. Lorsque vous supprimez une instance de base de données, toutes les sauvegardes automatiques sont supprimées et ne peuvent pas être récupérées. Les instantanés manuels ne sont pas supprimés. **Pour supprimer une instance de base de données sans instantané de base de données final à l'aide de la console Neptune** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**. 1. Dans la liste **Instances**, sélectionnez la case d'option en regard de l'instance de base de données que vous souhaitez supprimer. 1. Choisissez **Actions d'instance)**, puis **Supprimer**. 1. Choisissez **Non** dans la case **Créer un instantané final ?**. 1. Sélectionnez **Delete (Supprimer)**. ## Suppression d'une instance de base de données avec snapshot final Si vous voulez pouvoir restaurer ultérieurement une instance de base de données supprimée, vous pouvez créer un instantané de base de données final. Toutes les sauvegardes automatiques sont également supprimées et ne peuvent pas être récupérées. Les instantanés manuels ne sont pas supprimés. **Pour supprimer une instance de base de données avec un instantané de base de données final à l'aide de la console Neptune** 1. [Connectez-vous à la console AWS de gestion et ouvrez la console Amazon Neptune à https://console.aws.amazon.com/neptune/ la maison.](https://console.aws.amazon.com/neptune/home) 1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**. 1. Dans la liste **Instances**, sélectionnez la case d'option en regard de l'instance de base de données que vous souhaitez supprimer. 1. Choisissez **Actions d'instance)**, puis **Supprimer**. 1. Choisissez **Oui** dans la case **Créer un instantané final ?**. 1. Dans la zone **Nom de l'instantané final**, saisissez le nom de votre instantané de base de données final. 1. Sélectionnez **Supprimer**. Vous pouvez vérifier l'état de santé d'une instance, déterminer son type, identifier la version du moteur actuellement installée et obtenir d'autres informations sur une instance à l'aide de l'[API instance-status](access-graph-status.md).