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.
# 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).