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.
# Versions du moteur pour Amazon Neptune
Amazon Neptune publie régulièrement des mises à jour du moteur.
Pour déterminer la version du moteur qui est actuellement installée, vous pouvez utiliser l'[API instance-status](access-graph-status.md) dans la console Neptune. Le numéro de version vous indique si vous exécutez une version majeure d’origine, une version mineure ou une version de correctif. Pour plus d'informations sur la numérotation des versions, consultez [Numéros de version du moteur](cluster-maintenance.md#engine-version-numbers).
Pour plus d’informations sur les mises à jour en général, consultez [Maintenance du cluster](cluster-maintenance.md).
À partir de la version 1.3.0.0 du moteur, les versions du moteur auront la structure indiquée dans le tableau ci-dessous. Le numéro de version mineure est celui qui sera évalué pour le traitement [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu).
| Version | Version de produit | Version majeure | Version mineure | Version de correctif | Statut | Libéré | Fin de vie | Mise à niveau vers : |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [1.4.7.0](engine-releases-1.4.7.0.md) | 1 | 4 | 7 | 0 | *actif* | 03/03/26/ | 03/06/2027/ | N/A |
| [1.4.6.3](engine-releases-1.4.6.3.md) | 1 | 4 | 6 | 3 | *actif* | 18/12/2025 | 03/06/2027/ | 1.4.7.0 |
| [1.4.6.2](engine-releases-1.4.6.2.md) | 1 | 4 | 6 | 2 | *actif* | 18/11/2025 | 03/06/2027/ | 1.4.7.0 |
| [1.4.6.1](engine-releases-1.4.6.1.md) | 1 | 4 | 6 | 1 | *actif* | 18/09/2025 | 06/03/2021 | 1.4.6.2 |
| [1.4.6.0](engine-releases-1.4.6.0.md) | 1 | 4 | 6 | 0 | *actif* | 02/09/2025 | 06/03/2021 | 1.4.6.1 |
| [1.4.5.1](engine-releases-1.4.5.1.md) | 1 | 4 | 5 | 1 | *actif* | 30/06/2025 | 06/03/2021 | 1.4.6.0 |
| [1.4.5.0](engine-releases-1.4.5.0.md) | 1 | 4 | 5 | 0 | *actif* | 09/04/2025-04 | 06/03/2021 | 1.4.5.1 |
| [1.4.4.0](engine-releases-1.4.4.0.md) | 1 | 4 | 4 | 0 | *actif* | 24/02/2025 | 06/03/2021 | 1.4.5.0 |
| [1.4.3.0](engine-releases-1.4.3.0.md) | 1 | 4 | 3 | 0 | *actif* | 21/01/2025 | 06/03/2021 | 1.4.4.0 |
| [1.4.2.0](engine-releases-1.4.2.0.md) | 1 | 4 | 2 | 0 | *actif* | 19-12-2024 | 06/03/2021 | 1.4.3.0 |
| [1.4.1.0](engine-releases-1.4.1.0.md) | 1 | 4 | 1 | 0 | *actif* | 21/11/2024 | 06/03/2021 | 1.4.2.0 |
| [1.4.0.0](engine-releases-1.4.0.0.md) | 1 | 4 | 0 | 0 | *actif* | 06/11/2024 | 06/03/2021 | 1.4.1.0 |
| [1.3.4.0](engine-releases-1.3.4.0.md) | 1 | 3 | 4 | 0 | *actif* | 2024-10-01 | 06/03/2021 | 1.4.0.0 |
| [1.3.3.0](engine-releases-1.3.3.0.md) | 1 | 3 | 3 | 0 | *actif* | 2024-08-05 | 06/03/2021 | 1.3.4.0 |
| [1.3.2.1](engine-releases-1.3.2.1.md) | 1 | 3 | 2 | 1 | *actif* | 20/06/2024 | 06/03/2021 | 1.3.3.0 |
| [1.3.2.0](engine-releases-1.3.2.0.md) | 1 | 3 | 2 | 0 | *actif* | 10/06/2022 | 06/03/2027/ | 1.3.2.1 |
| [1.3.1.0](engine-releases-1.3.1.0.md) | 1 | 3 | 1 | 0 | *actif* | 06/03/2024 | 06/03/2027/ | 1.3.2.1 |
| [1.3.0.0](engine-releases-1.3.0.0.md) | 1 | 3 | 0 | 0 | *actif* | 15/11/2023 | 06/03/2027/ | 1.3.2.1 |
Le tableau ci-dessous répertorie toutes les versions du moteur depuis la version 1.0.1.0, ainsi que des informations sur les versions end-of-life. Vous pouvez utiliser les dates suivantes pour planifier vos cycles de test et de mise à niveau.
| Version | Version majeure | Version mineure | Statut | Libéré | Fin de vie | Mise à niveau vers : |
| --- | --- | --- | --- | --- | --- | --- |
| [1.2.1.2](engine-releases-1.2.1.2.md) | 1.2 | 1.2 | *actif* | 2024-08-05 | 30/06/2026/ | 1.3.0.0 |
| [1.2.1.1](engine-releases-1.2.1.1.md) | 1.2 | 1.1 | *actif* | 11/03/2024 | 30/06/2026/ | 1.3.0.0 |
| [1.2.1.0](engine-releases-1.2.1.0.md) | 1.2 | 1.0 | *actif* | 2023-03-08 | 30/06/2026/ | 1.3.0.0 |
| [1.2.0.2](engine-releases-1.2.0.2.md) | 1.2 | 0.2 | *actif* | 16 novembre | 30/06/2026/ | 1.3.0.0 |
| [1.2.0.1](engine-releases-1.2.0.1.md) | 1.2 | 0.1 | *actif* | 26/10 | 30/06/2026/ | 1.3.0.0 |
| [1.2.0.0](engine-releases-1.2.0.0.md) | 1.2 | 0.0 | *actif* | 07-21 | 30/06/2026/ | 1.3.0.0 |
| [1.1.1.0](engine-releases-1.1.1.0.md) | 1.1 | 1.0 | *actif* | 19/04/2018 | 30/06/2026/ | 1.2.1.0 |
| [1.1.0.0](engine-releases-1.1.0.0.md) | 1.1 | 0.0 | *obsolète* | 2021-11-19 | 15/03/2025 | 1.1.1.0 |
| [1.0.5.1](engine-releases-1.0.5.1.md) | 1.0 | 5.1 | *obsolète* | 2021-10-01 | 30/01/2023 | 1.1.0.0 |
| [1.0.5.0](engine-releases-1.0.5.0.md) | 1.0 | 5.0 | *obsolète* | 2021-07-27 | 30/01/2023 | 1.1.0.0 |
| [1.0.4.2](engine-releases-1.0.4.2.md) | 1.0 | 4.2 | *obsolète* | 01-06-2021 | 30/01/2023 | 1.1.0.0 |
| [1.0.4.1](engine-releases-1.0.4.1.md) | 1.0 | 4.1 | *obsolète* | 2020-12-08 | 30/01/2023 | 1.1.0.0 |
| [1.0.4.0](engine-releases-1.0.4.0.md) | 1.0 | 4.0 | *obsolète* | 2020-10-12 | 30/01/2023 | 1.1.0.0 |
| [1.0.3.0](engine-releases-1.0.3.0.md) | 1.0 | 3.0 | *obsolète* | 2020-08-03 | 30/01/2023 | 1.1.0.0 |
| [1.0.2.2](engine-releases-1.0.2.2.md) | 1.0 | 2.2 | *obsolète* | 09 mars 2020 | 07-29 | 1.0.3.0 |
| [1.0.2.1](engine-releases-1.0.2.1.md) | 1.0 | 2.1 | *obsolète* | 22/11/2019 | 07-29 | 1.0.3.0 |
| [1.0.2.0](engine-releases-1.0.2.0.md) | 1.0 | 2.0 | *obsolète* | 08/11/2019 | 19/05/2020 | 1.0.3.0 |
| [1.0.1.2](engine-releases-1.0.1.2.md) | 1.0 | 1.2 | *obsolète* | 2019-10-15 | — | — |
| [1.0.1.1](engine-releases-1.0.1.1.md) | 1.0 | 1.1 | *obsolète* | 13/08/2019 | — | — |
| [1.0.1.0.\$1](engine-releases-1.0.1.0.md) | 1.0 | 1.0.\$1 | *obsolète* | 02/07/2021 et avant | — | — |
## end-of-lifePlanification des principales versions du moteur
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 ».
# Version 1.4.7.0 du moteur Amazon Neptune (03/03/2026/)
Depuis le 03/03/2020, la version 1.4.7.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**Mise à niveau temporairement indisponible**
Les mises à niveau vers la version 1.4.7.0 du moteur Neptune ne sont pas disponibles pour le moment en raison de problèmes connus liés aux mises à niveau des clusters de bases de données mondiales (GDB). Nous prévoyons d'activer les mises à niveau dans quelques semaines.
## Nouvelles fonctionnalités pour cette version du moteur
+ OpenCypher est lu depuis le support S3 pour les fichiers Parquet et CSV via OC. Consultez la [neptune.read ()](access-graph-opencypher-21-extensions-s3-read.md) documentation.
+ Fonctions de requête géospatiales OpenCypher. Cette version inclut 12 fonctions de types spatiaux basées sur la norme ISO/IEC 13249-3:2016, un nouveau type de propriété de géométrie pour POINT stocké dans un nouvel index géopétrique pour une récupération rapide, et la prise en charge du format Known Text (WKT). Consultez le [Données spatiales](access-graph-opencypher-22-spatial-data.md) et la [Fonctions spatiales](access-graph-opencypher-22-spatial-functions.md) documentation.
## Améliorations de cette version du moteur
+ Performances de requête améliorées pour les sous-requêtes SPARQL qui renvoient de petits ensembles de résultats, y compris ceux dont les valeurs LIMIT sont faibles
+ Performances de requête améliorées dans les cas où les variables sont limitées par un très grand nombre de valeurs constantes (par exemple, par une clause SPARQL VALUES ou une clause OpenCypher UNWIND)
+ Améliorations apportées aux requêtes d'insertion à faible latence grâce à certaines optimisations des insertions dans les dictionnaires
+ De nouvelles étapes du langage G705 ont été ajoutées au moteur DFE (voir la [couverture des étapes Gremlin dans](gremlin-step-coverage-in-DFE.md) DFE).
+ Trajectoire et étapes de traversée : `order(local)`
+ Étapes d'agrégation et de collecte : `dedup(local)`
+ Amélioration des performances pour les OpenCypher requêtes, notamment`COLLECT(DISTINCT ...)`. La réécriture décrite dans [Réécriture des requêtes COLLECT (DISTINCT...)](best-practices-content-11.md) n'est plus nécessaire lors de l'utilisation de la version 1.4.7.0 ou ultérieure du moteur.
## Défauts corrigés dans cette version du moteur
Correctifs généraux :
+ Correction du fait que le chargement en masse ne répondait pas lors du chargement d'un grand nombre de fichiers Edge
+ Correction d'un problème global d'application de correctifs aux clusters de bases de données qui affectait les mises à jour des clusters secondaires à partir des versions 1.4.0.0, 1.4.1.0 et 1.4.2.0.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.7.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.7.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.7.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.7.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.6.3 du moteur Amazon Neptune (18/12/2025)
Depuis le 18 décembre 2025, la version 1.4.6.3 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur (1.4.6.3)
**Corrections générales**
+ Certaines exceptions classées par erreur comme des erreurs internes au serveur sont désormais correctement signalées comme des exceptions de mémoire insuffisante lors de l'exécution du moteur de flux de données (DFE).
+ Correction d'un problème qui pouvait entraîner l'échec des instances de la base de données Neptune au démarrage lorsque la validation intégrée de l'identifiant Edge rencontrait des types d'entrées de dictionnaire inattendus. La validation intégrée de l'identifiant Edge ne s'exécute désormais que pour les configurations du moteur de requête Gremlin et gère de manière élégante les entrées du dictionnaire autres que les URI.
+ Correction d'un problème qui empêchait le chargeur groupé Neptune de se connecter à S3 dans certaines régions en raison d'une résolution incorrecte des points de terminaison.
**Correctifs apportés à openCypher**
+ Correction d'un crash moteur qui se produisait parfois lors de requêtes utilisant`CALL`.
+ Délai d'expiration et gestion des annulations fixes pour les requêtes de mutation.
+ Correction d'un bogue à cause duquel la `MERGE` clause donnait des résultats incorrects lorsque l'une des valeurs de propriété transmises `MERGE` avait une valeur nulle.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.6.3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.6.3 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.6.3 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.6.3 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.6.2 du moteur Amazon Neptune (18/11/2025)
Depuis le 18 novembre 2025, la version 1.4.6.2 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
**Corrections générales**
+ Certaines exceptions classées par erreur en tant qu'exceptions de défaillance interne (IFEs) sont désormais correctement signalées en tant qu'exceptions de modification simultanée (CMEs) lors de l'exécution du moteur de flux de données (DFE).
**Correctifs apportés à Gremlin**
+ Stabilité du moteur améliorée pour Gremlin par rapport au DFE
**Correctifs apportés à openCypher**
+ Correction d'un problème introduit dans la version 1.4.6.0 du moteur Neptune en raison duquel les requêtes OpenCypher MERGE géraient incorrectement les directions des relations entrantes (←). Les requêtes utilisant des modèles tels que MERGE (n) ← [:type] - (m) créent désormais des relations dans la bonne direction.
+ Correction d'un échec d'une opération de validation sur les transactions du rédacteur qui n'étaient pas correctement annulées.
+ Les plans de requêtes optimisés sont désormais pris en charge pour les requêtes MERGE qui font référence à des valeurs paramétrées.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.6.2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.6.2 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.6.2 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.6.2 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.6.1 du moteur Amazon Neptune (18/09/2025)
Depuis le 18/09/2025, la version 1.4.6.1 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
**Corrections générales**
+ Suppression des vérifications réseau pour les clusters utilisant des plages d'adresses IP privées non conformes à la RFC 1918 introduites dans la version. [Version 1.4.6.0 du moteur Amazon Neptune (02/09/2020)](engine-releases-1.4.6.0.md)
**Correctifs apportés à Gremlin**
+ Correction d'un problème de gestion des connexions Websocket avec les transactions.
+ Correction d'un rare problème de redémarrage d'instance lors de l'utilisation du mode DFE de gremlin
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.6.1, assurez-vous que votre projet est compatible avec les versions du langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.6.1 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.6.1 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.6.1 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.6.0 du moteur Amazon Neptune (02/09/2020)
Depuis le 02/09/2020, la version 1.4.6.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Avertissement**
La version du moteur 1.4.6.0 inclut de nouvelles vérifications réseau pour les clusters qui utilisent des plages d'adresses IP privées non conformes à la RFC 1918 pour les VPC de base de données sans authentification IAM. Si vous avez cette configuration VPC et IAM, vous devrez mettre à jour votre base de données VPC pour utiliser les plages d'adresses IP privées RFC 1918 et and/or activer l'authentification IAM afin d'éviter les erreurs lors des requêtes après la mise à niveau vers la version 1.4.6.0.
## Nouvelles fonctionnalités de cette version du moteur
+ Connectez-vous à Neptune à l'aide de points de terminaison publics. Pour plus d'informations, consultez la section Points de terminaison [publics de Neptune](neptune-public-endpoints.md).
## Améliorations apportées à cette version du moteur
**Améliorations générales**
+ Performances SPARQL améliorées pour les opérations de mise à jour.
+ OpenCypher Performances améliorées pour les opérations `CREATE``MERGE`, et `SET` (mutations).
+ OpenCypher Performances améliorées pour les opérations de sous-requête CALL.
**Améliorations d’openCypher**
+ Ajout d'un nouvel indice de requête pour prendre en charge le [délai d'expiration au niveau de la requête.](opencypher-query-hints-timeout-hint.md)
## Défauts corrigés dans cette version du moteur
**Correctifs apportés à Gremlin**
+ Les connexions aux sessions G705 doivent se faire sur le même canal qui les a créées, ce qui signifie qu'il n'est pas possible de connecter plusieurs instances clientes à la même session.
+ Les sessions G705 se sont toujours fermées lorsque le client ferme, mais elles se ferment désormais également en cas de fermeture de la connexion initiée par le serveur, ce qui empêche toute reconnexion involontaire ou inattendue.
+ Correction de fuites de mémoire pour les requêtes G705 lisant des données de type blob volumineux.
**Correctifs apportés à openCypher**
+ Correction de la gestion des variables après une `CALL` sous-requête.
+ Correction d'un problème lié à `reduce` la fonction permettant de gérer correctement les scénarios de dépassement arithmétique.
+ Correction d'une fuite de mémoire affectant les requêtes paramétrées lorsque le cache du plan de requête est activé.
+ Correction d'un problème lié à l'`NOT EXISTS`utilisation dans les `WHERE` clauses complexes.
+ Correction du fait que l'exception de mémoire simultanée (CMEs) était mal signalée comme. BadRequestException
**Correctifs apportés à SPARQL**
+ Correction d'un message d'erreur pour SPARQL `LOAD/UNLOAD` lorsque la source distante n'est pas disponible.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.6.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.6.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.6.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.6.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.5.1 du moteur Amazon Neptune (30/06/2020)
Au 30 juin 2020, la version 1.4.5.1 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
**Corrections générales**
+ Correction d'un problème lié au dimensionnement sans serveur qui avait un impact sur tous les langages de requête.
+ Correction d'un problème en raison duquel une erreur interne était renvoyée sur certaines OpenCypher requêtes lors de l'exécution `collect(distinct())` d'une liste.
+ Correction d'un problème en raison duquel une requête FTS simultanée entraînait l'arrêt d'autres requêtes FTS simultanées en cas d'utilisation OpenSearch sans serveur.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.5.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.5.1 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.5.1 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.5.1 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.5.0 du moteur Amazon Neptune (2025-04-09)
Depuis le 2025-04-09, la version 1.4.5.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Avertissement**
Nous avons temporairement suspendu les mises à niveau vers la version 1.4.5.0 en raison de problèmes pouvant survenir dans certaines configurations sans serveur. Nous vous recommandons de passer à la version du moteur 1.4.5.1. Les mises à niveau vers la version 1.4.5.0 ont été temporairement désactivées.
## Nouvelles fonctionnalités de cette version du moteur
+ De nouvelles étapes du langage G705 ont été ajoutées au moteur DFE.
+ **Chemin et étapes de traversée :** AsDate (), DateAdd (), DateDiff (), fail (), Inject (), label (), chemin (), projet (), repeat (), sack (), select (), unfold (), disjonct (), drop (), identité (), intersection (), longueur (), boucles (), barrière (), ordre (), range (), reverse (), sample (), cap (), split (), filter (), flatMap (), map (), sideEffect (), union (), index ()
+ **Étapes d'agrégation et de collecte :** agrégation (globale), combinaison (), compte (), déduplication (globale), pliage (), groupe (), groupCount ()
+ **Étapes mathématiques :** max (), moyenne (), min (), somme ()
+ **Étapes des éléments :** otherV (), ElementMap (), élément (), V (), out (), in (), both (), outE (), iNE (), bothe (), outV (), inV (), bothV (), otherV ()
+ **Étapes relatives aux propriétés :** propriétés (), clé (), valueMap (), valeur ()
+ **Étapes de filtrage :** and (), coalesce (), coin (), is (), local (), none (), not () ou (), where ()
+ **Étapes de manipulation des chaînes :** concat (), LTrim (), RTrim (), substring (), toLower (), toUpper (), trim ()
+
**Prédicats :**
+ Comparez : eq, neq, lt, lte, gt, gte
+ Contient : dedans, sans
+ texTP : se terminant par, contenant,,, notStartingWith non contenant notEndingWith
+ P : et, ou, entre, à l'extérieur, à l'intérieur
Pour plus de détails sur toutes les étapes G705 disponibles dans DFE, reportez-vous à. [Couverture des étapes de Garmlin en PDF](gremlin-step-coverage-in-DFE.md)
## Améliorations apportées à cette version du moteur
**Améliorations générales**
+ Amélioration de la lenteur du temps d'attente pour le verrouillage du journal des requêtes. Les journaux de requêtes lents incluent désormais des mesures de temps d'attente pour les verrous partagés et exclusifs. Ils sont stockés dans le cadre de chaque transaction en cas de promotion paresseuse en lecture-écriture. Ces métriques apparaissent dans la section StorageCounters des journaux des requêtes lentes.
+ Suppression du support pour les suites de chiffrement suivantes :
+ TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256
+ TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384
+ TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256
+ TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384
**Améliorations de Gremlin**
+ De nombreuses nouvelles étapes ont été ajoutées au langage Gremlin. Pour de plus amples informations, veuillez consulter [Couverture des étapes de Garmlin en PDF](gremlin-step-coverage-in-DFE.md).
**Améliorations d’openCypher**
+ Améliorations des performances CREATE, MERGE et SET (mutations).
+ Améliorations des performances des sous-requêtes CALL.
+ Support de l'en-tête de suivi HTTP pour les réponses OpenCypher en plusieurs parties. Pour plus d'informations, consultez la section [En-têtes de suivi HTTP facultatifs](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-opencypher-queries.html#optional-http-trailing-headers).
+ Ajout de la fonction temporelle du jour, du mois et de l'année à OpenCypher. Pour plus d'informations, consultez la section [Fonctions temporelles](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-opencypher-extensions.html#temporal-functions).
```
RETURN day(datetime('2021-06-03T01:48:14Z'))
{
"results": [{
"day(datetime('2021-06-03T01:48:14Z'))": 3
}]
}
```
## Défauts corrigés dans cette version du moteur
**Corrections générales**
+ Correction d'un problème qui entraînait la Audit/SlowQueryLog suppression des fichiers journaux.
**Correctifs apportés à Gremlin**
+ Correction d'un problème lié à l'exécution de requêtes G705 alors que la fonctionnalité Result Cache était désactivée. Une requête se terminant par iterate () renvoyait des résultats au lieu de renvoyer une réponse vide.
+ Correction d'un problème lié au cache de résultats G705 causé par des requêtes simultanées avec la même clé. L'une des requêtes exécutées simultanément a renvoyé des résultats incorrects au lieu de renvoyer des résultats vides.
+ Correction d'un problème lié aux requêtes d'exportation Amazon S3 qui entraînait l'échec d'une requête lors d'un téléchargement en plusieurs parties d'Amazon S3 en raison d'un délai d'expiration ou d'une annulation, en allongeant le temps de nettoyage.
+ Correction d'un problème d'autorisation lié à l'exportation vers Amazon S3 par Gremlin.
**Correctifs apportés à SPARQL**
+ Correction d'un problème dans le traitement des requêtes SPARQL qui déclaraient plusieurs bases, IRIs ce qui entraînait l'utilisation de la seule déclaration initiale.
+ Correction d'un problème lié à la gestion des `REPLACE` fonctions SPARQL utilisant des chaînes de modèles non valides qui provoquaient le renvoi d'une erreur.
+ Correction d'un problème lié à la gestion des `REPLACE` fonctions SPARQL à l'aide de l'indicateur case-insensitivity (`"i"`) avec les données Unicode.
+ Correction d'un problème lié à l'analyse des requêtes SPARQL à l'aide de séquences d'échappement non valides `\u` et de `\U` points de code qui pouvait entraîner l'absence de réponse.
+ Correction d'un problème dans la `IRI` fonction SPARQL qui ne résolvait pas toujours correctement la relation par IRIs rapport à l'IRI de base actuel.
+ Correction d'un problème en raison duquel `SPARQL INSERT DATA` les `DELETE DATA` mises à jour utilisant des noms préfixés ne parvenaient pas à résoudre correctement la relation par IRIs rapport à l'IRI de base actuel.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.5.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.5.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.5.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.5.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.4.0 du moteur Amazon Neptune (24/02/2025)
Au 24/02/2025, la version 1.4.4.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Avertissement**
Le cache du plan de requêtes n'est temporairement pas pris en charge pour l'exécution de requêtes paramétrées impliquant des valeurs de paramètres numériques, en raison d'un bogue dans la gestion des utilisations dupliquées d'un paramètre de type numérique dans la requête. Par exemple :
```
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$minutes RETURN n
parameters={"minutes":130}
```
Les requêtes qui effectuent de nombreuses recherches d'index sur des déclarations ou des indices de dictionnaire peuvent entraîner une régression des performances de 5 %. Par exemple, le fait de compter tous les sommets ou d'obtenir le nombre `id` de tous les sommets ne serait pas affecté. L'obtention de toutes les propriétés de tous les sommets peut entraîner une régression allant jusqu'à 5 %.
## Défauts corrigés dans cette version du moteur
**Corrections générales**
+ Correction d'un problème en raison duquel la `WITH` clause contenant un astérisque (`*`) et des expressions d'alias provoquait une analyse incorrecte des requêtes dans OpenCypher.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.4.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.4.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.4.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.4.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.3.0 du moteur Amazon Neptune (21/01/2021)
Depuis le 21/01/2021, la version 1.4.3.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Avertissement**
Le cache du plan de requêtes n'est temporairement pas pris en charge pour l'exécution de requêtes paramétrées impliquant des valeurs de paramètres numériques, en raison d'un bogue dans la gestion des utilisations dupliquées d'un paramètre de type numérique dans la requête. Par exemple :
```
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$minutes RETURN n
parameters={"minutes":130}
```
Les requêtes qui effectuent de nombreuses recherches d'index sur des déclarations ou des indices de dictionnaire peuvent entraîner une régression des performances de 5 %. Par exemple, le fait de compter tous les sommets ou d'obtenir le nombre `id` de tous les sommets ne serait pas affecté. L'obtention de toutes les propriétés de tous les sommets peut entraîner une régression allant jusqu'à 5 %.
## Nouvelles fonctionnalités de cette version du moteur
+ [Exportation des résultats de requêtes Gremlin vers Amazon S3](exporting-gremlin.md). Exportation des résultats des requêtes G705 directement vers Amazon S3. Cette fonctionnalité vous permet de gérer efficacement les résultats de requêtes volumineux en les exportant vers un compartiment Amazon S3, au lieu de les renvoyer sous forme de réponse à une requête.
```
g.V().
hasLabel('Comment').
valueMap().
call('neptune.query.exportToS3', [
'destination': 's3://your-bucket/path/result.json',
'format': 'GraphSONv3',
'keyArn': 'optional-kms-key-arn'
])
```
+ **Instances R7i**. La famille d'instances R7i, d'une taille maximale de 48 fois, est désormais disponible dans les régions suivantes :
+ ap-northeast-1 - Asie-Pacifique (Tokyo)
+ ap-northeast-2 - Asie-Pacifique (Séoul)
+ ap-south-1 - Asie-Pacifique (Mumbai)
+ ap-southeast-1 - Asie-Pacifique (Singapour)
+ ap-southeast-2 - Asie-Pacifique (Sydney)
+ ap-southeast-3 - Asie-Pacifique (Jakarta)
+ ca-central-1 - Canada (Centre)
+ eu-central-1 - Europe (Francfort)
+ eu-north-1 - Europe (Stockholm)
+ eu-south-2 - Europe (Espagne)
+ eu-west-1 - Europe (Irlande)
+ eu-west-2 - Europe (Londres)
+ eu-west-3 - Europe (Paris)
+ us-east-1 - USA Est (Virginie du Nord)
+ us-east-2 - Est des États-Unis (Ohio)
+ us-west-1 - USA Ouest (Californie du Nord)
+ us-west-2 - Ouest des États-Unis (Oregon)
## Améliorations apportées à cette version du moteur
**Améliorations générales**
+ Support en mode laboratoire pour la collecte des déchets dans les dictionnaires (GC).
Lorsque cette option est activée, les entrées de dictionnaire inutilisées sont nettoyées par une tâche en arrière-plan. Il ne réduit pas`VolumeBytesUsed`, il libère de l'espace dans l'index pour de nouvelles insertions. Le taux de croissance `VolumeBytesUsed` est susceptible d'être inférieur lorsque le dictionnaire GC est activé par rapport à lorsqu'il ne l'est pas. Cela fonctionne pour les données du graphe de propriétés (insérées via Gremlin ou OpenCypher) lorsque le `neptune_streams` paramètre n'est pas activé. Pour de plus amples informations, consultez [Collecte des déchets du dictionnaire Neptune](storage-gc.md).
## Défauts corrigés dans cette version du moteur
**Corrections générales**
+ Correction de deux problèmes de fuite de mémoire affectant FreeableMemory l'utilisation du moteur DFE.
**Correctifs apportés à openCypher**
+ Résolvez le problème avec MERGE ON MATCH/ON CREATE pour les lignes dupliquées.
```
UNWIND [1, 1] AS id
MERGE (n:Person {id: id})
ON CREATE SET n.p = 5
ON MATCH SET n.p = 6
```
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.3.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.3.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.3.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.3.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.2.0 du moteur Amazon Neptune (1912-2024)
Depuis le 19 décembre 2024-12, la version 1.4.2.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Avertissement**
Le cache du plan de requêtes n'est temporairement pas pris en charge pour l'exécution de requêtes paramétrées impliquant des valeurs de paramètres numériques, en raison d'un bogue dans la gestion des utilisations dupliquées d'un paramètre de type numérique dans la requête. Par exemple :
```
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$minutes RETURN n
parameters={"minutes":130}
```
Les requêtes qui effectuent de nombreuses recherches d'index sur des déclarations ou des indices de dictionnaire peuvent entraîner une régression des performances de 5 %. Par exemple, le fait de compter tous les sommets ou d'obtenir le nombre `id` de tous les sommets ne serait pas affecté. L'obtention de toutes les propriétés de tous les sommets peut entraîner une régression allant jusqu'à 5 %.
## Défauts corrigés dans cette version du moteur
**Corrections générales**
+ Plan d'exécution et performances fixes pour les requêtes avec accès à plusieurs propriétés sur la même variable dans OPTIONAL MATCH et compréhension de liste. Par exemple :
```
MATCH (n)
WHERE n.name = 'A'
OPTIONAL MATCH (n)-[:knows]->(m)
WHERE m.name = 'C' or m.city = 'B'
RETURN m
```
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.2.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.2.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.2.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.2.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.1.0 du moteur Amazon Neptune (21/11/2021)
Depuis le 21/11/2021, la version 1.4.1.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Avertissement**
Le cache du plan de requêtes n'est temporairement pas pris en charge pour l'exécution de requêtes paramétrées impliquant des valeurs de paramètres numériques, en raison d'un bogue dans la gestion des utilisations dupliquées d'un paramètre de type numérique dans la requête. Par exemple :
```
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$minutes RETURN n
parameters={"minutes":130}
```
Les requêtes qui effectuent de nombreuses recherches d'index sur des déclarations ou des indices de dictionnaire peuvent entraîner une régression des performances de 5 %. Par exemple, le fait de compter tous les sommets ou d'obtenir le nombre `id` de tous les sommets ne serait pas affecté. L'obtention de toutes les propriétés de tous les sommets peut entraîner une régression allant jusqu'à 5 %.
## Nouvelles fonctionnalités de cette version du moteur
+ Ajout de la prise en charge des `CALL` sous-requêtes avec une sous-requête en lecture seule, permettant l'exécution d'opérations dans un périmètre défini. Une `CALL` sous-requête est exécutée une fois pour chaque ligne entrante et les variables renvoyées dans une sous-requête sont disponibles dans toute la portée de la requête englobante. Les variables d'une portée externe peuvent être importées dans une `CALL` sous-requête à l'aide d'une `WITH` clause d'importation. Pour plus d'informations, consultez la section Prise en [charge des sous-requêtes CALL dans Neptune](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-opencypher-extensions.html#call-subquery-support).
```
MATCH (origin:airport {code:"AUS"})-[:route]->(stopover)
CALL {
WITH stopover
MATCH (stopover)-[r:route]->(destination)
RETURN destination
ORDER BY r.dist DESC LIMIT 2
}
RETURN stopover, destination
```
+ Fonctions OpenCypher ajoutées. Nous introduisons huit nouvelles fonctions pour faciliter les chaînes, les opérations de collecte et le tri des collections. Il s'agit notamment de : `textIndexOf` `collToSet``collSubtract`,`collIntersection`,`collSort`,`collSortMaps`,,`collSortMulti`, et`collSortNodes`. Voir les [fonctions Neptune OpenCypher pour](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-opencypher-extensions.html#opencypher-compliance-new-functions) la description, les paramètres d'entrée, la sortie et des exemples.
## Améliorations apportées à cette version du moteur
**Améliorations de Gremlin**
+ Nouveau paramètre du mode laboratoire`AccurateQRCMemoryEstimation`. Lorsqu'il [est activé, le cache des résultats des requêtes G705](https://docs.aws.amazon.com//neptune/latest/userguide/gremlin-results-cache.html) permet de mettre en cache les résultats des requêtes dans la base de données. Par défaut, une estimation approximative est utilisée pour déterminer la taille du résultat mis en cache. Lorsque ce paramètre en mode laboratoire `AccurateQRCMemoryEstimation` est activé, l'estimation de la taille des résultats mis en cache utilisera une estimation de taille précise au lieu d'une estimation approximative.
+ Correction d'un problème lié à l'optimisation « non » du filtre dans les requêtes G705 exécutées sur le moteur d'exécution par défaut. Ce problème affectait les requêtes lorsque les contours étaient filtrés à l'aide de l'étape not () combinée à l'une des étapes OutV () /inv () /otherV (). Les exemples de requêtes incluent :
+ `g.E().hasLabel("knows").not(outV().hasId("5"))`
+ `g.V().has('airport','code','SDF').outE().where(not(otherV().has(id, within('1','5','7')))).count()`
**Améliorations d’openCypher**
+ Performances améliorées pour les requêtes utilisant de grandes listes statiques ou des cartes. Certaines requêtes effectuées avec UNWIND sur une longue liste de cartes imbriquées utilisées pour insérer/déplacer un nœud doté de propriétés permettent d'améliorer considérablement les performances.
+ Introduit un nouvel indice de requête OpenCypher pour indiquer au moteur de supposer que les types de données sont cohérents pour les valeurs utilisées dans la requête. Consultez [AssumeConsistentDataTypes](https://docs.aws.amazon.com//neptune/latest/userguide/opencypher-query-hints-AssumeConsistentDataTypes.html)pour plus de détails sur le nouvel indice de requête OpenCypher.
+ Introduit un ensemble de [nouvelles fonctions OpenCypher](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-opencypher-extensions.html#opencypher-compliance-new-functions) pour gérer le texte et les valeurs de collection.
## Défauts corrigés dans cette version du moteur
**Correctifs apportés à Gremlin**
+ Correction d'un problème dans le chemin du code TinkerPop OSS qui permettait de créer une représentation en bytecode d'une requête de traversée lorsque l'une des `withStrategies()/withoutStrategies()/with()` étapes était utilisée sur un objet `GraphTraversalSource` « g ». Le problème a incorrectement ajouté de nouvelles instructions au Bytecode au lieu de remplacer les instructions existantes pour la même stratégie et a provoqué une incompatibilité des clés de cache lors de l'invalidation du cache de résultats pour effacer les résultats stockés.
**Correctifs apportés à openCypher**
+ Comportement corrigé pour ``~id`match` les CREATE/MERGE/MATCH clauses in. Lorsque vous utilisez une ``~id`` valeur non valide, telle que des types nuls ou autres que des chaînes, une exception correcte est désormais émise pour les CREATE/MERGE clauses et aucun résultat n'est renvoyé pour une `MATCH` clause.
+ IFE fixe lorsque l'utilisateur utilise une valeur d'un type non pris en charge avec des fonctions d'agrégation (par exemple sum ()).
+ Correction d'un problème en raison duquel certaines requêtes de mutation à faible latence provenant d'une charge de travail importante échouaient avec une OutOfMemory erreur.
**Correctifs apportés à SPARQL**
+ Correction d'un problème de journal d'audit lors de la gestion des requêtes SPARQL contenant le `'%'` caractère.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.1.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.1.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.1.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.1.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.4.0.0 du moteur Amazon Neptune (06/11/2021)
Depuis le 06/11/2021, la version 1.4.0.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
La [version 1.3.0.0 du moteur](engine-releases-1.3.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 du moteur antérieure à la version 1.3.0.0 ou supérieure, vous devez 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.3` Les versions antérieures utilisaient une famille de groupes de paramètres `neptune1` ou `neptune1.2`, lesquels ne sont pas compatibles avec les versions 1.3.0.0 et supérieures. De même, vous devez utiliser des groupes de paramètres de cluster 1.4.0.0 pour les versions de moteur 1.4.0.0 et supérieures. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md).
**Avertissement**
Le cache du plan de requêtes n'est temporairement pas pris en charge pour l'exécution de requêtes paramétrées impliquant des valeurs de paramètres numériques, en raison d'un bogue dans la gestion des utilisations dupliquées d'un paramètre de type numérique dans la requête. Par exemple :
```
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$minutes RETURN n
parameters={"minutes":130}
```
Les requêtes qui effectuent de nombreuses recherches d'index sur des déclarations ou des indices de dictionnaire peuvent entraîner une régression des performances de 5 %. Par exemple, le fait de compter tous les sommets ou d'obtenir le nombre `id` de tous les sommets ne serait pas affecté. L'obtention de toutes les propriétés de tous les sommets peut entraîner une régression allant jusqu'à 5 %.
## Nouvelles fonctionnalités de cette version du moteur
+ Lorsqu'une arête est ajoutée à un graphe de propriétés sans identifiant explicite, le serveur attribue par défaut un identifiant de bord basé sur l'UUID, qui est stocké dans le dictionnaire. Désormais, en définissant un nouveau paramètre de cluster`neptune_enable_server_generated_edge_id = 1`, le serveur attribuera IDs en utilisant un entier de 8 octets géré en interne, sans aucune surcharge du dictionnaire. Cela permet de réaliser des économies de stockage et d'améliorer les performances des requêtes sans aucune modification des requêtes. Cette fonctionnalité n'est actuellement prise en charge que pour les insertions via le langage de requête Gremlin.
+ Ajout de la prise en charge de l'exécution des étapes Gremlin limit () dans les traversées imbriquées pour le moteur DFE.
```
g.V().project("foo").by(out().order().by(T.id).limit(1))
```
## Améliorations apportées à cette version du moteur
**Améliorations générales**
+ Neptune récupérera automatiquement l'espace d'annulation détenu par les transactions importantes une fois que la transaction sera terminée et que les journaux ne seront plus nécessaires pour la restauration.
+ Support pour les répliques survivables de bases de données globales. Cette fonctionnalité permet au cluster secondaire de continuer à traiter les demandes de lecture lors du redémarrage d'une instance d'écriture sur le cluster principal. Auparavant, lorsqu'une instance d'enregistreur redémarrait, toutes les instances de lecteur d'un cluster secondaire redémarraient également. Avec cette version, les instances de lecteur de cluster secondaires continuent de traiter les demandes de lecture lors du redémarrage d'une instance d'écriture, ce qui améliore la disponibilité de lecture dans le cluster.
+ Les journaux d'audit sont désormais écrits de manière synchrone, ce qui garantit que chaque requête est enregistrée. Cela peut affecter les performances pour les requêtes particulièrement volumineuses (> 100 Ko) ou les charges de travail à haut débit (> 1 000 qps).
**Améliorations de Gremlin**
+ Le délai d'expiration par requête est imposé par défaut pour être inférieur au délai d'expiration au niveau du cluster. Dans une version précédente, cette vérification avait été introduite mais devait être explicitement activée via le paramètre lab-mode « ». StrictTimeoutValidation Dans cette version, « StrictTimeoutValidation » sera activé par défaut et devra être désactivé explicitement pour conserver l'ancien comportement.
**Améliorations d’openCypher**
+ Dans une version précédente, nous avons introduit la prise en [charge étendue du format datetime](https://docs.aws.amazon.com//neptune/latest/userguide/feature-opencypher-compliance.html#opencypher-compliance-time-na), activée via un paramètre `DatetimeMillisecond` du mode laboratoire. Cette prise en charge étendue du format date/heure est désormais activée par défaut.
**Améliorations de SPARQL**
+ Nouvelles actions IAM explicites pour les autorisations de requête.
```
Previously:
COPY: WriteDataViaQuery & ReadDataViaQuery
MOVE: WriteDataViaQuery & DeleteDataViaQuery
DELETEINSERT: ReadDataViaQuery & DeleteDataViaQuery
Now,
COPY: WriteDataViaQuery & ReadDataViaQuery & DeleteDataViaQuery
MOVE: WriteDataViaQuery & ReadDataViaQuery & DeleteDataViaQuery
DELETEINSERT: ReadDataViaQuery, WriteDataViaQuery if there is INSERT clause, DeleteDataViaQuery if there is DELETE clause.
```
## Défauts corrigés dans cette version du moteur
**Corrections générales**
+ Correction d'un problème lié aux instances sans serveur qui pouvait entraîner le redémarrage de la base de données lors de la mise à l'échelle.
+ Correction d'un problème lié à la gestion des fichiers journaux d'audit qui pouvait rendre les fichiers journaux inaccessibles pour le téléchargement ou la rotation et, dans certains cas, augmenter l'utilisation du processeur.
+ Correction d'un problème de requête lié à l'optimisation qui retardait la génération de la sortie cartographique dans le moteur DFE.
+ Correction d'un problème qui provoquait des horodatages différents entre les journaux d'audit et la lenteur des journaux de requêtes.
**Correctifs apportés à Gremlin**
+ Résolution d'un problème lié à la gestion des WebSocket connexions Gremlin, à savoir que les requêtes exécutées pendant une durée supérieure au délai d'inactivité de la connexion étaient interrompues prématurément. Cela a spécifiquement affecté les clients Python G705 utilisant le transport AIOHTTP.
**Correctifs apportés à openCypher**
+ Correction d'un problème dans l'étape de collecte qui provoquait une exception de défaillance interne lorsque des valeurs nulles étaient présentes lors de la construction de la requête collect (distinct (n)).
+ Correction d'un problème `NullPointerException` qui pouvait apparaître dans les requêtes lorsque le cache du plan de requêtes était activé.
+ Correction d'un problème qui évaluait plus de données que nécessaire lorsqu'une requête contenait une clause LIMIT.
+ Correction d'un problème en raison duquel l'utilisation d'opérations de plage (<, <=, >, >=) dans une requête paramétrée avec un cache de plan de requête produisait des résultats dupliqués.
+ Correction d'un problème qui transposait les colonnes de résultats lorsque les opérations UNION et UNION ALL étaient effectuées à l'aide de connexions par boulon.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.4.0.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.4.0.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.4.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.4.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.3.4.0 du moteur Amazon Neptune (2024-10-01)
Depuis le 2024-10-01, la version 1.3.4.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
La [version 1.3.0.0 du moteur](engine-releases-1.3.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 du moteur antérieure à la version 1.3.0.0 ou supérieure, vous devez 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.3` Les versions antérieures utilisaient une famille de groupes de paramètres `neptune1` ou `neptune1.2`, lesquels ne sont pas compatibles avec les versions 1.3.0.0 et supérieures. De même, vous devez utiliser des groupes de paramètres de cluster 1.4.0.0 pour les versions de moteur 1.4.0.0 et supérieures. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md).
**Avertissement**
Un problème a été détecté concernant les opérations de mise à jour de SPARQL 1.1 qui peuvent être présentes dans certaines conditions lorsque des opérateurs de mise à jour sont utilisés avec des politiques d'autorisation basées sur des actions. Si vous utilisez les opérations de mise à jour de SPARQL 1.1 avec des politiques d'autorisation basées sur des actions, nous vous recommandons de passer à la dernière version mineure du moteur Neptune (au moins 1.3.4.0) qui inclut un correctif pour ce problème.
Le cache du plan de requêtes a été temporairement désactivé pour les requêtes paramétrées impliquant des valeurs de paramètres numériques en raison d'un problème lié à la gestion des utilisations dupliquées d'un paramètre de type numérique, comme dans la requête suivante :
```
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$minutes RETURN n
parameters={"minutes":130}
```
## Améliorations apportées à cette version du moteur
+ Ajout de la prise en charge de l'exécution des étapes Gremlin limit () dans les traversées imbriquées pour le moteur DFE.
+ Ajout de CloudWatch métriques liées au cache de résultats G705, comme indiqué ci-dessous, qui peuvent être utiles pour diagnostiquer et régler la latence du cache de résultats. Consultez [Neptune Metrics](https://docs.aws.amazon.com//neptune/latest/userguide/cw-metrics.html#cw-metrics-available) pour plus de détails.
```
NumResultCacheHit
NumResultCacheMiss
ResultCacheSizeInBytes
ResultCacheItemCount
ResultCacheOldestItemTimestamp
ResultCacheNewestItemTimestamp
```
## Défauts corrigés dans cette version du moteur
**Améliorations générales**
+ Correction d'un problème à cause duquel, dans de rares cas, le moteur se bloquait au lieu de renvoyer une erreur de requête.
**Correctifs apportés à Gremlin**
+ Nous avons amélioré le traitement des demandes et le signalement des erreurs lorsqu'un client ou un proxy envoie une demande de mise à niveau du Websocket via une connexion established/used HTTP (auparavant, 400 réponses contenant l'erreur « aucun script g705 fourni, code MissingParameterException » étaient renvoyées).
+ Optimisation de la gestion des `mergeV` étapes grâce à des mises à jour de la valeur des propriétés de cardinalité uniques. Par exemple, la requête ci-dessous est désormais prise en charge de manière native dans Neptune.
```
g.mergeV([(T.id): 1234]). option(onMatch, ['age': single(20), 'name': single('alice'), 'city': set('miami')])
```
+ Correction d'un problème d'évaluation des requêtes G705 DFE qui provoquait l'échec des requêtes avec un. `InternalFailureException` Cette erreur s'est produite avec certains modèles de`select`, comme indiqué dans l'exemple suivant :
```
g.V("1").as("a").as("b").select("a","b").dedup()
```
**Correctifs apportés à openCypher**
+ Correction d'un problème en raison duquel l'exécution `collect(distinct())` en présence de valeurs nulles provoquait le renvoi d'une erreur.
+ Problème résolu : l'exécution d'une requête paramétrée contenant un filtre de plage (/>= par rapport à la valeur du paramètre) produisait des résultats. duplicate/missing
+ Correction d'un bogue en raison duquel le moteur DFE produisait plus de résultats que ce qui était demandé dans les requêtes limites, ce qui pouvait entraîner des erreurs de mémoire insuffisante.
**Correctifs apportés à SPARQL**
+ Correction d'un problème en raison duquel l'exécution d'une requête de mise à jour SPARQL fédérée sur des clusters dotés de l'authentification IAM entraînait le renvoi d'une erreur.
+ Autorisations basées sur des actions fixes pour les opérations de mise à jour de SPARQL 1.1.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.3.4.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.3.4.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.3.4.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.3.4.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.3.3.0 du moteur Amazon Neptune (05/08/2021)
Depuis le 5 août 2021, la version 1.3.3.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
La [version 1.3.0.0 du moteur](engine-releases-1.3.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 du moteur antérieure à la version 1.3.0.0 ou supérieure, vous devez 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.3` Les versions antérieures utilisaient une famille de groupes de paramètres `neptune1` ou `neptune1.2`, lesquels ne sont pas compatibles avec les versions 1.3.0.0 et supérieures. De même, vous devez utiliser des groupes de paramètres de cluster 1.4.0.0 pour les versions de moteur 1.4.0.0 et supérieures. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md).
**Avertissement**
La version 1.3.3.0 du moteur a introduit des problèmes potentiels dont vous devez être conscient. Consultez la section ci-dessous [Atténuation des problèmes dans la version 1.3.3.0](#1.3.3.0-mitigation) pour plus d'informations.
## Défauts corrigés dans cette version du moteur
**Améliorations générales**
+ Correction d'un problème d'instabilité du moteur lorsque le cache de prédicats contient un grand nombre de prédicats.
**Correctifs apportés à openCypher**
+ Correction d'un problème qui empêchait l'exécution d'une requête après le déclenchement d'une exception interne.
+ Correction d'un problème en raison duquel une requête pouvait échouer avec une exception interne lors de l'utilisation du cache du plan de requête.
**Correctifs apportés à SPARQL**
+ Correction d'un problème lié au protocole HTTP SPARQL 1.1 Graph Store (GSP) qui pouvait être présent dans certaines conditions lorsque le GSP est utilisé avec des politiques d'autorisation basées sur des actions.
## Atténuation des problèmes dans la version 1.3.3.0
+ Les requêtes utilisant des valeurs de filtre numériques peuvent renvoyer des résultats incorrects lors de l'utilisation du cache du plan de requêtes. Pour éviter ce problème, utilisez l'indice de requête `QUERY:PLANCACHE "disabled"` pour ignorer le cache du plan de requête. Par exemple, utilisez :
```
USING QUERY:PLANCACHE "disabled"
MATCH (n:person)
WHERE n.yearOfBirth > $year
RETURN n
parameters={"year":1950}
```
+ Les requêtes utilisant le même nom de paramètre plusieurs fois peuvent échouer avec l'erreur`Parameter name should not be a number and/or contain _internal_ or _modified_user_ string within it. These are reserved for planCache. Otherwise, rerun with HTTP parameter planCache=disabled`. Dans ce cas, ignorez le cache du plan de requête comme ci-dessus ou dupliquez les paramètres comme dans cet exemple :
```
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$minutes RETURN n
parameters={"minutes":130}
```
Utilisez le conseil `QUERY:PLANCACHE "disabled"` ou modifiez les paramètres :
```
MATCH (n:movie) WHERE n.runtime>=$rt_min RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$dur_min RETURN n
parameters={"rt_min":130, "dur_min":130}
```
+ Les requêtes exécutées avec le protocole Bolt peuvent produire des résultats incorrects s'il s'agit d'une requête UNION ou UNION ALL. Pour éviter ce problème, envisagez d'exécuter la requête en question avec le point de terminaison HTTP. Vous pouvez également exécuter chaque partie de l'union séparément lorsque vous utilisez le protocole Bolt.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.3.3.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.3.3.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.3.3.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.3.3.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.3.2.1 du moteur Amazon Neptune (20/06/2021)
Depuis le 2024-06-20, la version 1.3.2.1 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
La [version 1.3.0.0 du moteur](engine-releases-1.3.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 du moteur antérieure à la version 1.3.0.0 ou supérieure, vous devez 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.3` Les versions antérieures utilisaient une famille de groupes de paramètres `neptune1` ou `neptune1.2`, lesquels ne sont pas compatibles avec les versions 1.3.0.0 et supérieures. De même, vous devez utiliser des groupes de paramètres de cluster 1.4.0.0 pour les versions de moteur 1.4.0.0 et supérieures. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md).
**Avertissement**
La version 1.3.2.1 du moteur a introduit des problèmes potentiels dont vous devez être conscient. Consultez la section ci-dessous [Atténuation des problèmes dans la version 1.3.2.1](#1.3.2.1-mitigation) pour plus d'informations.
## Défauts corrigés dans cette version du moteur
**Correctifs apportés à openCypher**
+ Un bogue a été détecté dans la fonctionnalité de cache du plan de requêtes pour les requêtes paramétrées contenant une `WITH` clause interne ayant `SKIP` et en `LIMIT` tant que paramètres. Les SKIP/LIMIT valeurs n'étaient pas correctement paramétrées et, par conséquent, les exécutions ultérieures du même plan de requête mis en cache avec des valeurs de paramètres différentes renverraient toujours les mêmes résultats que lors de la première exécution. Cela a été corrigé.
```
# insert some nodes
UNWIND range(1, 10) as i CREATE (s {name: i}) RETURN s
# sample query
MATCH (p)
WITH p ORDER BY p.name SKIP $s LIMIT $l
RETURN p.name as res
# first time executing with {"s": 2, "l": 1}
{
"results" : [ {
"res" : 3
} ]
}
# second time executing with {"s": 2, "l": 10}
# due to bug, produces
{
"results" : [ {
"res" : 3
} ]
}
# with fix, produces correct results:
{
"results" : [ {
"res" : 3
}, {
"res" : 4
}, {
"res" : 5
}, {
"res" : 6
}, {
"res" : 7
}, {
"res" : 8
}, {
"res" : 9
}, {
"res" : 10
} ]
}%
```
+ Correction d'un bogue où les requêtes de mutation paramétrées lançaient un `InternalFailureException` message lorsque le paramètre passé n'était pas déjà présent dans la base de données.
+ Correction d'un bug à cause duquel les requêtes Bolt paramétrées restaient bloquées après avoir atteint une condition de course lors du nettoyage des ressources de requête.
## Les modifications apportées au 1.3.2.1 sont reportées du 1.3.2.0
### Améliorations apportées depuis la version 1.3.2.0 du moteur
**Améliorations générales**
+ Support de la version 1.3 de TLS, y compris les suites de chiffrement TLS\$1AES\$1128\$1GCM\$1 et TLS\$1AES\$1256\$1GCM\$1SHA256 . SHA384 Le protocole TLS 1.3 est une option, le protocole TLS 1.2 reste le minimum.
+ Le support étendu d'OpenCypher pour le format datetime est disponible en mode lab\$1pour cette version. Nous vous encourageons à le tester.
**Améliorations apportées à Gremlin**
+ TinkerPop Mise à niveau 3.7.x
+ Fournit une extension importante du langage Gremlin.
+ Nouvelles étapes pour le traitement des chaînes, des listes et des dates.
+ Nouvelle syntaxe pour spécifier la cardinalité au sein de l'`mergeV()`étape.
+ `union()`peut désormais être utilisé comme étape de départ.
+ Pour en savoir plus sur les modifications apportées à la version 3.7.x, consultez la documentation de [TinkerPop mise à niveau](https://tinkerpop.apache.org/docs/3.7.1/upgrade/#_tinkerpop_3_7_1).
+ [Lors de la mise à niveau des pilotes de langage Gremlin du client pour Java, notez que les classes du sérialiseur n'ont pas été renommées.](https://tinkerpop.apache.org/docs/3.7.1/upgrade/#_serializer_renaming) Vous devrez mettre à jour le nom des packages et des classes dans vos fichiers de configuration et dans le code, si cela est spécifié.
+ `StrictTimeoutValidation`(uniquement lorsqu'il est activé via labmode `StrictTimeoutValidation` en incluant`StrictTimeoutValidation=enabled`) : Lorsque le `StrictTimeoutValidation` paramètre a une valeur de`enabled`, une valeur de délai par requête spécifiée en tant qu'option de demande ou indice de requête ne peut pas dépasser la valeur définie globalement dans le groupe de paramètres. Dans ce cas, Neptune lancera un. `InvalidParameterException` Ce paramètre peut être confirmé dans une réponse sur le `/status` terminal lorsque la valeur est`disabled`, et dans les versions 1.3.2.0 et 1.3.2.1 de Neptune, la valeur par défaut de ce paramètre est. `Disabled`
**Améliorations d’openCypher**
+ La version 1.3.2.0 du moteur Amazon Neptune fournit un débit jusqu'à 9 fois plus rapide et 10 fois plus élevé pour les performances des requêtes OpenCypher par rapport aux versions précédentes du moteur.
+ Requêtes à faible latence et amélioration des performances de débit : améliorations des performances globales pour les requêtes OpenCypher à faible latence. La nouvelle version améliore également le débit de ces requêtes. Les améliorations sont plus importantes lorsque des requêtes paramétrées sont utilisées.
+ Support pour le cache du plan de requête : lorsqu'une requête est soumise à Neptune, la chaîne de requête est analysée, optimisée et transformée en un plan de requête, qui est ensuite exécuté par le moteur. Les applications sont souvent soutenues par des modèles de requête courants instanciés avec des valeurs différentes. Le cache des plans de requêtes peut réduire la latence globale en mettant en cache les plans de requêtes et en évitant ainsi l'analyse et l'optimisation pour de tels modèles répétés. Pour plus d’informations, consultez [Cache du plan de requête dans Amazon Neptune](access-graph-qpc.md).
+ Amélioration des performances pour les requêtes d'agrégation DISTINCTES.
+ Amélioration des performances pour les jointures impliquant des variables nullables.
+ Amélioration des performances pour les requêtes impliquant un prédicat non égal au prédicat id (node/relation).
+ Support étendu pour la fonctionnalité date/heure (uniquement activée en mode laboratoire `DatetimeMillisecond` en incluant`DatetimeMillisecond=enabled`. Pour de plus amples informations, veuillez consulter [Support temporel dans l'implémentation de Neptune OpenCypher (Neptune Analytics et Neptune Database 1.3.2.0 et versions ultérieures)](feature-opencypher-compliance.md#opencypher-compliance-time-na).
### Corrections de défauts reportées depuis la version 1.3.2.0 du moteur
**Améliorations générales**
+ Le message d'erreur NeptuneML a été mis à jour lors de la validation de l'accès aux compartiments Graphlytics.
**Correctifs apportés à Gremlin**
+ Correction d'informations d'étiquette manquantes dans la traduction des requêtes DFE, pour les scénarios dans lesquels les étapes ne contribuant pas au chemin contiennent des étiquettes. Par exemple :
```
g.withSideEffect('Neptune#useDFE', true).
V().
has('name', 'marko').
has("name", TextP.regex("mark.*")).as("p1").
not(out().has("name", P.within("peter"))).
out().as('p2').
dedup('p1', 'p2')
```
+ Correction d'un `NullPointerException` bogue dans la traduction des requêtes DFE, qui se produit lorsqu'une requête est exécutée en deux fragments DFE et que le premier fragment est optimisé pour un nœud insatisfaisant. Par exemple :
```
g.withSideEffect('Neptune#useDFE', true).
V().
has('name', 'doesNotExists').
has("name", TextP.regex("mark.*")).
inject(1).
V().
out().
has('name', 'vadas')
```
+ Correction d'un bug en raison duquel Neptune pouvait lancer un modulateur `InternalFailureException` lorsqu'une requête contenait un modulateur ValueTraversal inside by () et que son entrée était Map. Par exemple :
```
g.V().
hasLabel("person").
project("age", "name").by("age").by("name").
order().by("age")
```
**Correctifs apportés à openCypher**
+ Amélioration des opérations UNWIND (par exemple, extension d'une liste de valeurs en valeurs individuelles) pour éviter les situations de manque de mémoire (OOM). Par exemple :
```
MATCH (n)-->(m)
WITH collect(m) AS list
UNWIND list AS m
RETURN m, list
```
+ Optimisation de l'identifiant personnalisé fixe en cas d'opérations MERGE multiples où l'identifiant est injecté via UNWIND. Par exemple :
```
UNWIND [{nid: 'nid1', mid: 'mid1'}, {nid: 'nid2', mid: 'mid2'}] as ids
MERGE (n:N {`~id`: ids.nid})
MERGE (m:M {`~id`: ids.mid})
```
+ Correction d'une explosion de mémoire lors de la planification de requêtes complexes avec accès aux propriétés et de sauts multiples associés à des relations bidirectionnelles. Par exemple :
```
MATCH (person1:person)-[:likes]->(res)-[:partOf]->(group)-[:knows]-(:entity {name: 'foo'}),
(person1)-[:knows]->(person2)-[:likes]-(res2), (comment)-[:presentIn]->(:Group {name: 'barGroup'}),
(person1)-[:commented]->(comment2:comment)-[:partOf]->(post:Post), (comment2)-[:presentIn]->(:Group {name: 'fooGroup'}),
(comment)-[:contains]->(info:Details)-[:CommentType]->(:CommentType {name: 'Positive'}),
(comment2)-[:contains]->(info2:Details)-[:CommentType]->(:CommentType {name: 'Positive'})
WHERE datetime('2020-01-01T00:00') <= person1.addedAfter <= datetime('2023-01-01T23:59') AND comment.approvedBy = comment2.approvedBy
MATCH (comment)-[:contains]->(info3:Details)-[:CommentType]->(:CommentType {name: 'Neutral'})
RETURN person1, group.name, info1.value, post.ranking, info3.value
```
+ Requêtes d'agrégation fixes avec null en tant que groupe par variables. Par exemple :
```
MATCH (n)
RETURN null AS group, sum(n.num) AS result
```
**Correctifs apportés à SPARQL**
+ Correction de l'analyseur SPARQL afin d'améliorer le temps d'analyse pour les requêtes volumineuses telles que INSERT DATA contenant de nombreux triplets et de gros jetons.
### Atténuation des problèmes dans la version 1.3.2.1
+ Les requêtes utilisant des valeurs de filtre numériques peuvent renvoyer des résultats incorrects lors de l'utilisation du cache du plan de requêtes. Pour éviter ce problème, utilisez l'indice de requête `QUERY:PLANCACHE "disabled"` pour ignorer le cache du plan de requête. Par exemple, utilisez :
```
USING QUERY:PLANCACHE "disabled"
MATCH (n:person)
WHERE n.yearOfBirth > $year
RETURN n
parameters={"year":1950}
```
+ Les requêtes utilisant le même nom de paramètre plusieurs fois peuvent échouer avec l'erreur`Parameter name should not be a number and/or contain _internal_ or _modified_user_ string within it. These are reserved for planCache. Otherwise, rerun with HTTP parameter planCache=disabled`. Ignorez le cache du plan de requête comme ci-dessus dans de tels cas ou dupliquez les paramètres comme dans cet exemple :
```
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$minutes RETURN n
parameters={"minutes":130}
```
Utilisez le conseil `QUERY:PLANCACHE "disabled"` ou modifiez les paramètres :
```
MATCH (n:movie) WHERE n.runtime>=$rt_min RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$dur_min RETURN n
parameters={"rt_min":130, "dur_min":130}
```
+ Les requêtes exécutées avec le protocole Bolt peuvent produire des résultats incorrects s'il s'agit d'une requête UNION ou UNION ALL. Pour éviter ce problème, envisagez d'exécuter la requête en question avec le point de terminaison HTTP. Vous pouvez également exécuter chaque partie de l'union séparément lorsque vous utilisez le protocole Bolt.
### Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.3.2.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.3.2.1 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.3.2.1 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.3.2.1 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.3.2.0 du moteur Amazon Neptune (10/06/2021)
Depuis le 10/06/2021, la version 1.3.2.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
La [version 1.3.0.0 du moteur](engine-releases-1.3.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 du moteur antérieure à la version 1.3.0.0 ou supérieure, vous devez 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.3` Les versions antérieures utilisaient une famille de groupes de paramètres `neptune1` ou `neptune1.2`, lesquels ne sont pas compatibles avec les versions 1.3.0.0 et supérieures. De même, vous devez utiliser des groupes de paramètres de cluster 1.4.0.0 pour les versions de moteur 1.4.0.0 et supérieures. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md).
**Avertissement**
La version 1.3.2.0 du moteur a introduit des problèmes potentiels dont vous devez être conscient. Consultez la section ci-dessous [Atténuation des problèmes dans la version 1.3.2.0](#1.3.2.0-mitigation) pour plus d'informations.
## Améliorations apportées à cette version du moteur
**Améliorations générales**
+ Support de la version 1.3 de TLS, y compris les suites de chiffrement TLS\$1AES\$1128\$1GCM\$1 et TLS\$1AES\$1256\$1GCM\$1SHA256 . SHA384 Le protocole TLS 1.3 est une option, le protocole TLS 1.2 reste le minimum.
**Améliorations apportées à Gremlin**
+ TinkerPop Mise à niveau 3.7.x
+ Fournit une extension importante du langage Gremlin.
+ Nouvelles étapes pour le traitement des chaînes, des listes et des dates.
+ Nouvelle syntaxe pour spécifier la cardinalité au sein de l'`mergeV()`étape.
+ `union()`peut désormais être utilisé comme étape de départ.
+ Pour en savoir plus sur les modifications apportées à la version 3.7.x, consultez la documentation de [TinkerPop mise à niveau](https://tinkerpop.apache.org/docs/3.7.1/upgrade/#_tinkerpop_3_7_1).
+ [Lors de la mise à niveau des pilotes de langage Gremlin du client pour Java, notez que les classes du sérialiseur n'ont pas été renommées.](https://tinkerpop.apache.org/docs/3.7.1/upgrade/#_serializer_renaming) Vous devrez mettre à jour le nom des packages et des classes dans vos fichiers de configuration et dans le code, si cela est spécifié.
+ `StrictTimeoutValidation`(uniquement lorsqu'il est activé via labmode `StrictTimeoutValidation` en incluant`StrictTimeoutValidation=enabled`) : Lorsque le `StrictTimeoutValidation` paramètre a une valeur de`enabled`, une valeur de délai par requête spécifiée en tant qu'option de demande ou indice de requête ne peut pas dépasser la valeur définie globalement dans le groupe de paramètres. Dans ce cas, Neptune lancera un. `InvalidParameterException` Ce paramètre peut être confirmé dans une réponse sur le `/status` terminal lorsque la valeur est`disabled`, et dans Neptune version 1.3.2.0, la valeur par défaut de ce paramètre est. `Disabled`
**Améliorations d’openCypher**
+ La version 1.3.2.0 du moteur Amazon Neptune fournit un débit jusqu'à 9 fois plus rapide et 10 fois plus élevé pour les performances des requêtes OpenCypher par rapport aux versions précédentes du moteur.
+ Requêtes à faible latence et amélioration des performances de débit : améliorations des performances globales pour les requêtes OpenCypher à faible latence. La nouvelle version améliore également le débit de ces requêtes. Les améliorations sont plus importantes lorsque des requêtes paramétrées sont utilisées.
+ Support pour le cache du plan de requête : lorsqu'une requête est soumise à Neptune, la chaîne de requête est analysée, optimisée et transformée en un plan de requête, qui est ensuite exécuté par le moteur. Les applications sont souvent soutenues par des modèles de requête courants instanciés avec des valeurs différentes. Le cache des plans de requêtes peut réduire la latence globale en mettant en cache les plans de requêtes et en évitant ainsi l'analyse et l'optimisation pour de tels modèles répétés.
+ Amélioration des performances pour les requêtes d'agrégation DISTINCTES.
+ Amélioration des performances pour les jointures impliquant des variables nullables.
+ Amélioration des performances pour les requêtes impliquant un prédicat non égal au prédicat id (node/relation).
+ Support étendu pour la fonctionnalité date/heure (uniquement activée en mode laboratoire `DatetimeMillisecond` en incluant`DatetimeMillisecond=enabled`. Pour de plus amples informations, veuillez consulter [Support temporel dans l'implémentation de Neptune OpenCypher (Neptune Analytics et Neptune Database 1.3.2.0 et versions ultérieures)](feature-opencypher-compliance.md#opencypher-compliance-time-na).
## Défauts corrigés dans cette version du moteur
**Améliorations générales**
+ Le message d'erreur NeptuneML a été mis à jour lors de la validation de l'accès aux compartiments Graphlytics.
**Correctifs apportés à Gremlin**
+ Correction d'informations d'étiquette manquantes dans la traduction des requêtes DFE, pour les scénarios dans lesquels les étapes ne contribuant pas au chemin contiennent des étiquettes. Par exemple :
```
g.withSideEffect('Neptune#useDFE', true).
V().
has('name', 'marko').
has("name", TextP.regex("mark.*")).as("p1").
not(out().has("name", P.within("peter"))).
out().as('p2').
dedup('p1', 'p2')
```
+ Correction d'un `NullPointerException` bogue dans la traduction des requêtes DFE, qui se produit lorsqu'une requête est exécutée en deux fragments DFE et que le premier fragment est optimisé pour un nœud insatisfaisant. Par exemple :
```
g.withSideEffect('Neptune#useDFE', true).
V().
has('name', 'doesNotExists').
has("name", TextP.regex("mark.*")).
inject(1).
V().
out().
has('name', 'vadas')
```
+ Correction d'un bug en raison duquel Neptune pouvait lancer un modulateur `InternalFailureException` lorsqu'une requête contenait un modulateur ValueTraversal inside by () et que son entrée était Map. Par exemple :
```
g.V().
hasLabel("person").
project("age", "name").by("age").by("name").
order().by("age")
```
**Correctifs apportés à openCypher**
+ Amélioration des opérations UNWIND (par exemple, extension d'une liste de valeurs en valeurs individuelles) pour éviter les situations de manque de mémoire (OOM). Par exemple :
```
MATCH (n)-->(m)
WITH collect(m) AS list
UNWIND list AS m
RETURN m, list
```
+ Optimisation de l'identifiant personnalisé fixe en cas d'opérations MERGE multiples où l'identifiant est injecté via UNWIND. Par exemple :
```
UNWIND [{nid: 'nid1', mid: 'mid1'}, {nid: 'nid2', mid: 'mid2'}] as ids
MERGE (n:N {`~id`: ids.nid})
MERGE (m:M {`~id`: ids.mid})
```
+ Correction d'une explosion de mémoire lors de la planification de requêtes complexes avec accès aux propriétés et de sauts multiples associés à des relations bidirectionnelles. Par exemple :
```
MATCH (person1:person)-[:likes]->(res)-[:partOf]->(group)-[:knows]-(:entity {name: 'foo'}),
(person1)-[:knows]->(person2)-[:likes]-(res2), (comment)-[:presentIn]->(:Group {name: 'barGroup'}),
(person1)-[:commented]->(comment2:comment)-[:partOf]->(post:Post), (comment2)-[:presentIn]->(:Group {name: 'fooGroup'}),
(comment)-[:contains]->(info:Details)-[:CommentType]->(:CommentType {name: 'Positive'}),
(comment2)-[:contains]->(info2:Details)-[:CommentType]->(:CommentType {name: 'Positive'})
WHERE datetime('2020-01-01T00:00') <= person1.addedAfter <= datetime('2023-01-01T23:59') AND comment.approvedBy = comment2.approvedBy
MATCH (comment)-[:contains]->(info3:Details)-[:CommentType]->(:CommentType {name: 'Neutral'})
RETURN person1, group.name, info1.value, post.ranking, info3.value
```
+ Requêtes d'agrégation fixes avec null en tant que groupe par variables. Par exemple :
```
MATCH (n)
RETURN null AS group, sum(n.num) AS result
```
**Correctifs apportés à SPARQL**
+ Correction de l'analyseur SPARQL afin d'améliorer le temps d'analyse pour les requêtes volumineuses telles que INSERT DATA contenant de nombreux triplets et de gros jetons.
## Atténuation des problèmes dans la version 1.3.2.0
+ Pour la version 1.3.2.0, nous avons détecté un problème dans le cache du plan de requête lorsque `skip` ou `limit` est utilisé dans une `WITH` clause interne et qu'il est paramétré. Par exemple :
```
MATCH (n:Person)
WHERE n.age > $age
WITH n skip $skip LIMIT $limit
RETURN n.name, n.age
parameters={"age": 21, "skip": 2, "limit": 3}
```
Dans ce cas, les valeurs des paramètres pour skip et limit du premier plan seront également appliquées aux requêtes suivantes, ce qui entraînera des résultats inattendus.
**Mitigation**
Pour éviter ce problème, ajoutez l'indice de requête `QUERY:PLANCACHE "disabled"` lorsque vous soumettez une requête qui inclut une sous-clause de and/or limite de saut paramétrée. Vous pouvez également coder les valeurs en dur dans la requête.
**Option 1 :** utilisation de l'indicateur de requête pour désactiver le cache du plan :
```
Using QUERY:PLANCACHE "disabled"
MATCH (n:Person) WHERE n.age > $age
WITH n skip $skip LIMIT $limit
RETURN n.name, n.age
parameters={"age": 21, "skip": 2, "limit": 3}
```
**Option 2 :** utilisation de valeurs codées en dur pour le saut et la limite :
```
MATCH (n:Person)
WHERE n.age > $age
WITH n skip 2 LIMIT 3
RETURN n.name, n.age
parameters={"age": 21}
```
+ Les requêtes utilisant des valeurs de filtre numériques peuvent renvoyer des résultats incorrects lors de l'utilisation du cache du plan de requêtes. Pour éviter ce problème, utilisez l'indice de requête `QUERY:PLANCACHE "disabled"` pour ignorer le cache du plan de requête. Par exemple, utilisez :
```
USING QUERY:PLANCACHE "disabled"
MATCH (n:person)
WHERE n.yearOfBirth > $year
RETURN n
parameters={"year":1950}
```
+ Les requêtes utilisant le même nom de paramètre plusieurs fois peuvent échouer avec l'erreur`Parameter name should not be a number and/or contain _internal_ or _modified_user_ string within it. These are reserved for planCache. Otherwise, rerun with HTTP parameter planCache=disabled`. Ignorez le cache du plan de requête comme ci-dessus dans de tels cas ou dupliquez les paramètres comme dans cet exemple :
```
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$minutes RETURN n
parameters={"minutes":130}
```
Utilisez le conseil `QUERY:PLANCACHE "disabled"` ou modifiez les paramètres :
```
MATCH (n:movie) WHERE n.runtime>=$rt_min RETURN n
UNION
MATCH (n:show) WHERE n.duration>=$dur_min RETURN n
parameters={"rt_min":130, "dur_min":130}
```
+ Les requêtes exécutées avec le protocole Bolt peuvent produire des résultats incorrects s'il s'agit d'une requête UNION ou UNION ALL. Pour éviter ce problème, envisagez d'exécuter la requête en question avec le point de terminaison HTTP. Vous pouvez également exécuter chaque partie de l'union séparément lorsque vous utilisez le protocole Bolt.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.3.2.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.7.1`
+ *Dernière version de Gremlin est prise en charge :* `3.7.1`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.3.2.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.3.2.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.3.2.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.3.1.0 du moteur Amazon Neptune (06/03/2021)
Depuis le 06/03/2021, la version 1.3.1.0 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
La [version 1.3.0.0 du moteur](engine-releases-1.3.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 du moteur antérieure à la version 1.3.0.0 ou supérieure, vous devez 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.3` Les versions antérieures utilisaient une famille de groupes de paramètres `neptune1` ou `neptune1.2`, lesquels ne sont pas compatibles avec les versions 1.3.0.0 et supérieures. De même, vous devez utiliser des groupes de paramètres de cluster 1.4.0.0 pour les versions de moteur 1.4.0.0 et supérieures. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md).
## Améliorations apportées à cette version du moteur
**Améliorations générales**
+ Neptune a amélioré l'avertissement affiché dans profile/explain.
+ Suppression des courbes NIST EC obsolètes des groupes nommés par défaut utilisés lors de la négociation TLS. Les courbes supprimées sont sect409k1, sect409r1 et sect571k1.
**Améliorations apportées à Gremlin**
+ Amélioration du calcul des statistiques DFE pour éviter un nombre très élevé NCUs d'instances sans serveur.
+ Amélioration des performances de G705 pour WITHIN.
## Défauts corrigés dans cette version du moteur
**Correctifs apportés à Gremlin**
+ Améliorations diverses apportées aux plans de requêtes Gremlin DFE.
+ Correction d'un bogue pour les requêtes Gremlin avec une traversée facultative, par exemple pour les requêtes de la forme « g.V () .hasLabel ('person') .group () .by (id ()) .by (\$1\$1.in ('friend') .id () .fold ()) `, où aucune personne n'ayant pas d'avantage d'amis n'était groupée.
+ Correction d'un bug à cause duquel les requêtes G705 contenant des étapes de fusion à l'intérieur des `by` modulateurs provoquaient le renvoi d'une erreur si elles étaient exécutées à l'aide du moteur DFE.
+ Correction d'un bogue qui empêchait les requêtes en lecture seule exécutées dans une session G705 de fonctionner lorsqu'elles étaient connectées à une réplique en lecture.
+ Correction d'un bogue en raison duquel l'ARN IAM n'était pas présent dans le journal d'audit en raison d'une demande initiale de connexion Websocket réussie pour G705.
+ Étape de fusion, identification de la couverture des étapes avec DFE.
+ Optimisation des ensembles de caractéristiques pour l'ensemble des plans DFE.
**Correctifs apportés à openCypher**
+ Corrections de bogues dans la clause OpenCypher SET pour autoriser le réglage sur une expression non variable (par exemple : match (n:Test) set (cas où n.prop = 2 puis n end) .prop = 3 renvoie n.prop.
+ Correction d'un bogue concernant l'échec des requêtes OpenCypher impliquant l'agrégation et le tri par.
+ Amélioration de la fonction UNWIND d'une grande liste contenant des cartes statiques.
+ Correction d'une requête OpenCypher MERGE utilisant un identifiant personnalisé avec des valeurs dupliquées.
**Correctifs apportés à SPARQL**
+ Correction d'un bogue SPARQL concernant la portée de la variable dans les modèles optionnels.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.3.1.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.5`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.3.1.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.3.1.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.3.1.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.3.0.0 du moteur Amazon Neptune (15-11-2023)
Depuis le 15-11-2023, la version 1.3.0.0 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
La [version 1.3.0.0 du moteur](#engine-releases-1.3.0.0) 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 du moteur antérieure à la version 1.3.0.0 ou supérieure, vous devez 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.3` Les versions antérieures utilisaient une famille de groupes de paramètres `neptune1` ou `neptune1.2`, lesquels ne sont pas compatibles avec les versions 1.3.0.0 et supérieures. De même, vous devez utiliser des groupes de paramètres de cluster 1.4.0.0 pour les versions de moteur 1.4.0.0 et supérieures. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md).
## Nouvelles fonctionnalités pour cette version du moteur
+ Publication de l'[API de données Neptune](data-api.md).
L’API de données Amazon Neptune fournit un support de kit SDK pour plus de 40 opérations de données de Neptune, notamment le chargement des données, l’exécution de requêtes, la recherche de données et le machine learning. Elle prend en charge les trois langages de requête Neptune (Gremlin, openCypher et SPARQL) et est disponible dans tous les langages de kit SDK. Elle signe automatiquement les demandes d’API et simplifie considérablement l’intégration de Neptune dans les applications.
+ Ajout de la prise en charge de l'intégration de [OpenSearchServerless](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-overview.html) à Neptune.
## Améliorations de cette version du moteur
**Améliorations apportées aux mises à jour du moteur Neptune**
Neptune a modifié la façon dont il publie les mises à jour du moteur afin que vous puissiez mieux contrôler le processus de mise à jour. Au lieu de publier des correctifs pour des modifications non majeures, Neptune publie désormais des versions mineures qui peuvent être contrôlées [à l’aide du champ d’instance `AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) et pour lesquelles vous pouvez recevoir des notifications en vous [abonnant](events-subscribing.md) à l’événement [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156).
Consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md) pour plus d’informations sur ces modifications.
**Amélioration du chiffrement en transit**
Neptune ne prend plus en charge les suites de chiffrement suivantes :
+ `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA`
+ `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA`
Neptune ne prend en charge que les suites de chiffrement puissantes suivantes avec TLS 1.2 :
+ `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
+ `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
+ `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384`
+ `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`
**Améliorations de Gremlin**
+ Ajout de support dans le moteur DFE pour les étapes Gremlin suivantes :
+ `FoldStep`
+ `GroupStep`
+ `GroupCountStep`
+ `TraversalMapStep `
+ `UnfoldStep`
+ `LabelStep`
+ `PropertyKeyStep`
+ `PropertyValueStep`
+ `AndStep`
+ `OrStep`
+ `ConstantStep`
+ `CountGlobalStep`
+ Plans de requête DFE optimisés pour éviter les analyses complètes des sommets lors de l’utilisation de la modulation `by()`.
+ Amélioration significative des performances des requêtes à faible cardinalité et à faible latence.
+ Ajout du support DFE pour les prédicats de TinkerPop `Or` filtre.
+ Support DFE amélioré de la traversée pour les filtres sur la même clé, pour des requêtes telles que les suivantes :
```
g.withSideEffect("Neptune#useDFE", true)
.V()
.has('name', 'marko')
.and(
or(
has('name', eq("marko")),
has('name', eq("vardas"))
)
)
```
+ Gestion des erreurs améliorée pour l’étape `fail()`.
**Améliorations d’openCypher**
+ Amélioration significative des performances des requêtes à faible cardinalité et à faible latence.
+ Amélioration des performances de planification des requêtes lorsque la requête contient de nombreux types de nœuds.
+ Latence réduite de toutes les requêtes VLP.
+ Performances améliorées en supprimant les jointures de pipeline redondantes pour les requêtes de modèle à nœud unique.
+ Performances améliorées pour les requêtes contenant des modèles à sauts multiples avec des cycles, comme celui-ci :
```
MATCH (n)-->()-->()-->(m)
RETURN n m
```
**Améliorations de SPARQL**
+ Ajout d’un nouvel opérateur SPARQL : `PipelineHashIndexJoin`.
+ Amélioration des performances de validation d’URI pour les requêtes SPARQL.
+ Amélioration des performances des requêtes de recherche en texte intégral SPARQL grâce à la résolution par lots des termes du dictionnaire.
## Défauts corrigés dans cette version du moteur
**Correctifs apportés à Gremlin**
+ Correction d’un bogue Gremlin qui provoquait une fuite de transaction lors de la vérification du point de terminaison de statut d’une requête Gremlin pour détecter les requêtes contenant des prédicats dans les traversées enfants pour les étapes qui ne sont pas traitées nativement dans le moteur DFE.
+ Correction d’un bogue Gremlin qui empêchait l’optimisation de `valueMap()` lors de traversées `by()` dans le moteur DFE.
+ Correction d’un bogue Gremlin qui empêchait la propagation d’une étiquette d’étape attachée à `UnionStep` au dernier élément de chemin de ses traversées enfants.
+ Correction d'un bogue Gremlin qui empêchait une requête d'échouer parce qu'elle contenait trop d' TinkerPop étapes et ne pouvait donc pas être nettoyée.
+ Correction d’un bug de Gremlin qui provoquait l’ajout d’une `NullPointerException` dans les étapes `mergeV` et `mergeE`.
+ Correction d'un bogue Gremlin en raison duquel `order()` empêchait de trier correctement les sorties de chaînes lorsque certaines d'entre elles contenaient un espace.
+ Correction d’un problème d’exactitude de Gremlin qui se produisait lorsque l’étape `valueMap` était traitée dans le moteur DFE.
+ Correction d’un problème d’exactitude de Gremlin qui se produisait lorsque `GroupStep` ou `GroupCountStep` était imbriqué dans une traversée de touches.
**Correctifs apportés à openCypher**
+ Correction d’un bogue openCypher impliquant la gestion des erreurs autour des caractères NULL.
+ Correction d’un bogue openCypher lié à la gestion des transactions Bolt.
**Correctifs apportés à SPARQL**
+ Correction d’un bogue SPARQL en raison duquel les valeurs contenues dans les fonctions récursives n’étaient pas correctement résolues.
+ Correction d’un bogue SPARQL en raison duquel un grand nombre de valeurs injectées via une clause `VALUES` pouvait entraîner une dégradation des performances.
+ Correction d’un bogue SPARQL qui empêchait l’opérateur `REGEX` d’aboutir lorsqu’il était appelé sur un littéral balisé dans un langage.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.3.0.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.3.0.0 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.3.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.3.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.1.2 du moteur Amazon Neptune (2024-08-05)
Depuis le 5 août 2021, la version 1.2.1.2 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau depuis une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
**Avertissement**
Un problème a été détecté avec le protocole HTTP SPARQL 1.1 Graph Store (GSP) qui peut être présent dans certaines conditions lorsque le GSP est utilisé avec des politiques d'autorisation basées sur l'action. Si vous utilisez le protocole HTTP SPARQL 1.1 Graph Store avec des politiques d'autorisation basées sur des actions, nous vous recommandons de passer à la dernière version mineure du moteur Neptune (au moins 1.2.1.2) qui inclut un correctif pour ce problème.
## Défauts corrigés dans cette version du moteur
**Correctifs apportés à SPARQL**
+ Correction d'un problème lié au protocole HTTP SPARQL 1.1 Graph Store (GSP) qui pouvait être présent dans certaines conditions lorsque le GSP est utilisé avec des politiques d'autorisation basées sur des actions.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.2.1.2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.2`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.2.1.2 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.2 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.2 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.1.1 du moteur Amazon Neptune (2024-03-11)
Depuis le 11/03/2021, la version 1.2.1.1 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau depuis une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
**Améliorations générales**
Neptune a amélioré l'avertissement affiché dans profile/explain.
**Améliorations de Gremlin**
+ Amélioration du calcul des statistiques DFE pour éviter un nombre très élevé NCUs d'instances sans serveur.
+ Amélioration des performances de Gremlin pour WITHIN.
## Défauts corrigés dans cette version du moteur
**Correctifs apportés à Gremlin**
+ Corrections de bogues concernant la commande du plan de requêtes du moteur Gremlin DFE.
+ Correction d'un bogue avec une out-of-memory erreur Gremlin signalée à l'origine sous la forme InternalFailureException.
+ Correction d'un bogue en raison duquel l'ARN IAM n'était pas présent dans le journal d'audit en raison d'une demande initiale de connexion Websocket réussie.
+ Correction d'un bogue pour les requêtes Gremlin avec TinkerPop session activée lorsque les requêtes d'une session échouent, même si elles sont toutes en lecture seule et se connectent à une instance de lecteur.
**Correctifs apportés à openCypher**
+ Corrections de bogues dans la clause OpenCypher SET pour autoriser le réglage sur une expression non variable (par exemple : match (n:Test) set (cas où n.prop = 2 puis n end) .prop = 3 renvoie n.prop.
+ Correction d'un bogue concernant l'échec des requêtes OpenCypher impliquant l'agrégation et le tri par.
+ Amélioration de la fonction UNWIND d'une grande liste contenant des cartes statiques.
+ Correction d'un bogue dans la requête OpenCypher MERGE utilisant un identifiant personnalisé avec des valeurs dupliquées.
**Correctifs apportés à SPARQL**
+ Corrections de bogues dans le planificateur de requêtes SPARQL DFE.
+ Correction d'un bogue pour SPARQL lorsqu'il est utilisé avec les mots clés BIND et OPTIONAL.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de base de données vers la version 1.2.1.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.2`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version 1.2.1.1 du moteur
Vous pouvez effectuer une mise à niveau vers cette version à partir de la [version 1.2.0.0 ou supérieure du moteur](engine-releases-1.2.0.0.md).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.1 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.1 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.0 du moteur Amazon Neptune (08/03/2023)
Depuis le 8 mars 2023, la version 1.2.1.0 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.2.1.0.R2 (02/05/2023)](engine-releases-1.2.1.0.R2.md)
+ [Sortie : 1.2.1.0.R3 (13/06/2023)](engine-releases-1.2.1.0.R3.md)
+ [Sortie : 1.2.1.0.R4 (10/08/2023)](engine-releases-1.2.1.0.R4.md)
+ [Sortie : 1.2.1.0.R5 (02/09/2023)](engine-releases-1.2.1.0.R5.md)
+ [Sortie : 1.2.1.0.R6 (12/09/2023)](engine-releases-1.2.1.0.R6.md)
+ [Version : 1.2.1.0.R7 (06-10-2023)](engine-releases-1.2.1.0.R7.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout du support pour la [TinkerPop version 3.6.2](https://tinkerpop.apache.org/docs/3.6.2-SNAPSHOT/dev/provider/), qui ajoute de nombreuses nouvelles fonctionnalités de Gremlin, telles que les nouveaux`mergeV()`, `mergeE()``element()`, et les `fail()` étapes. Les étapes `mergeV()` et `mergeE()` sont particulièrement intéressantes, car elles offrent une option déclarative tant attendue pour effectuer des opérations de type upsert. Cela devrait grandement simplifier les modèles de code existants et faciliter la lecture de Gremlin. La version 3.6.x a également ajouté des prédicats regex (expression régulière), une nouvelle surcharge à l'étape `property()` qui utilise un mappage (`Map`), ainsi qu'une révision majeure du comportement de modulation `by()` qui est beaucoup plus cohérente dans toutes les étapes qui l'utilisent.
Consultez le [journal des TinkerPop modifications](https://github.com/apache/tinkerpop/blob/3.6.0/CHANGELOG.asciidoc#release-3-6-0) et la [page de mise à niveau](https://tinkerpop.apache.org/docs/current/upgrade/) pour obtenir des informations sur les modifications apportées à la version 3.6 et les éléments à prendre en compte lors de la mise à niveau.
Si vous utilisez `fold().coalesce(unfold(), )` pour les insertions conditionnelles, nous vous recommandons de migrer vers la nouvelle syntaxe `mergeV/E()`, décrite [ici](https://tinkerpop.apache.org/docs/3.6.0/reference/#mergevertex-step) et [ici](https://tinkerpop.apache.org/docs/3.6.0/reference/#mergeedge-step). Neptune utilise un schéma de verrouillage plus étroit pour `Merge` que pour`Coalesce`, ce qui permet de réduire les exceptions de modification simultanées (). CMEs
Pour plus d'informations sur les nouvelles fonctionnalités disponibles dans cette TinkerPop version, consultez le blog de Stephen Mallette, [Exploring new features of Apache TinkerPop 3.6.x in Amazon Neptune](https://aws.amazon.com/blogs/database/exploring-new-features-of-apache-tinkerpop-3-6-x-in-amazon-neptune/).
+ Ajout de la prise en charge des [types d'instances R6i](https://aws.amazon.com/ec2/instance-types/r6i/), alimentés par des processeurs Intel Xeon Scalable de 3e génération. Elles sont parfaitement adaptées aux charges de travail gourmandes en mémoire et offrent des compute/price performances jusqu'à 15 % supérieures et une bande passante mémoire jusqu'à 20 % supérieure par vCPU par rapport aux types d'instances R5 comparables.
+ Ajout de points de terminaison d'[API de résumé de graphe](neptune-graph-summary.md) pour les graphes de propriétés et les graphes RDF, afin de vous permettre de générer un rapport récapitulatif rapide du graphe.
Pour les graphes de propriétés (PG), l'API de résumé de graphe fournit une liste en lecture seule des étiquettes et des clés de propriété des nœuds et des arêtes, ainsi que le nombre de nœuds, d'arêtes et de propriétés. Pour les graphes RDF, elle fournit une liste de classes et de clés de prédicat, ainsi que le nombre de quadruplets, de sujets et de prédicats.
Les modifications suivantes ont été apportées avec la nouvelle API de résumé de graphe :
+ Ajout d'une nouvelle action sur le [GetGraphSummary](iam-dp-actions.md#getgraphsummary)plan de données.
+ Ajout d'un nouveau point de terminaison `rdf/statistics` pour remplacer le point de terminaison `sparql/statistics`, qui est désormais obsolète.
+ Remplacement du nom du champ `summary` dans la réponse d'état des statistiques par `signatureInfo`, afin de ne pas le confondre avec les informations du résumé de graphe. Les versions précédentes du moteur continueront d'utiliser `summary` dans la réponse JSON.
+ La précision du champ `date` dans la réponse d'état des statistiques a été modifiée, passant de la minute à la milliseconde. Le format précédent était `2020-05-07T23:13Z` (précision à la minute), tandis que le nouveau format est `2023-01-24T00:47:43.319Z` (précision à la milliseconde). Ces deux formats sont conformes à la norme ISO 8601, mais cette modification peut corrompre le code existant, en fonction de la façon dont la date est analysée.
+ Une nouvelle magie linéaire [`%statistics`](notebooks-magics.md#notebooks-line-magics-statistics), qui vous permet de récupérer les statistiques du moteur DFE, a été ajoutée dans le workbench.
+ Une nouvelle magie linéaire [`%summary`](notebooks-magics.md#notebooks-line-magics-summary), qui vous permet de récupérer les informations du résumé de graphe, a été ajoutée dans le workbench.
+ Ajout de la [journalisation des requêtes lentes](slow-query-logs.md) pour enregistrer les requêtes dont l'exécution prend plus de temps qu'un seuil spécifié. Vous devez activer et contrôler la journalisation des requêtes lentes à l'aide des deux nouveaux paramètres dynamiques, à savoir [neptune\$1enable\$1slow\$1query\$1log](parameters.md#parameters-db-cluster-parameters-neptune_enable_slow_query_log) et [neptune\$1slow\$1query\$1log\$1threshold](parameters.md#parameters-db-cluster-parameters-neptune_slow_query_log_threshold).
+ Ajout de la prise en charge de deux [paramètres dynamiques](parameter-groups.md), à savoir les nouveaux paramètres de cluster [neptune\$1enable\$1slow\$1query\$1log](parameters.md#parameters-db-cluster-parameters-neptune_enable_slow_query_log) et [neptune\$1slow\$1query\$1log\$1threshold](parameters.md#parameters-db-cluster-parameters-neptune_slow_query_log_threshold). Lorsque vous modifiez un paramètre dynamique, il s'applique immédiatement, sans nécessiter de redémarrage de l'instance.
+ Ajout d'une fonction OpenCypher [removeKeyFromMap ()](access-graph-opencypher-extensions.md#opencypher-compliance-removeKeyFromMap-function) spécifique à Neptune qui supprime une clé spécifiée d'une carte et renvoie la nouvelle carte résultante.
## Améliorations de cette version du moteur
+ Prise en charge étendue de Gremlin DFE pour les étapes `limit` avec une portée locale.
+ Ajout de la prise en charge de la modulation `by()` pour l'étape Gremlin `DedupGlobalStep` dans le moteur DFE.
+ Ajout de la prise en charge DFE des étapes Gremlin `SelectStep` et `SelectOneStep`.
+ Amélioration des performances et corrections de divers opérateurs Gremlin, notamment `repeat`, `coalesce`, `store` et `aggregate`.
+ Amélioration des performances des requêtes openCypher impliquant `MERGE` et `OPTIONAL MATCH`.
+ Amélioration des performances des requêtes openCypher impliquant `UNWIND` pour une liste de mappages de valeurs littérales.
+ Amélioration des performances des requêtes openCypher dotées d'un filtre `IN` pour `id`. Par exemple :
```
MATCH (n) WHERE id(n) IN ['1', '2', '3'] RETURN n
```
+ Ajout de la possibilité de spécifier l'IRI de base pour les requêtes SPARQL à l'aide de l'instruction BASE (voir [IRI de base par défaut pour les requêtes et les mises à jour](feature-sparql-compliance.md#opencypher-compliance-default-iri)).
+ Réduction du temps d'attente pour le traitement des chargements en bloc spécifiques aux arêtes Gremlin et openCypher.
+ Les chargements en bloc reprennent désormais de manière asynchrone lorsque Neptune redémarre afin d'éviter un long délai d'attente causé par des problèmes de connectivité à Amazon S3 avant l'échec des tentatives de reprise.
+ Gestion améliorée des requêtes SPARQL DESCRIBE dont l'indicateur de requête [DescribeMode](sparql-query-hints-for-describe.md#sparql-query-hints-describeMode) est défini sur `"CBD"` (description CBD) et qui impliquent un grand nombre de nœuds vides.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue openCypher où les requêtes renvoyaient la chaîne `"null"` au lieu d'une valeur nulle dans Bolt et SPARQL-JSON.
+ Correction d'un bogue openCypher lié à la compréhension de liste, où une valeur nulle était générée au lieu des valeurs fournies pour les éléments de liste.
+ Correction d'un bogue openCypher en raison duquel les valeurs d'octets n'étaient pas correctement sérialisées.
+ Correction d'un bogue Gremlin dans l'étape `UnionStep` qui se produisait lorsqu'une entrée était une arête traversante vers un sommet dans une traversée enfant.
+ Correction d'un bogue Gremlin qui empêchait la propagation correcte d'une étiquette d'étape associée à `UnionStep` vers la dernière étape de chaque traversée enfant.
+ Correction d'un bogue Gremlin pour l'étape `dedup` avec des étiquettes suivant une étape `repeat`, bogue à cause duquel les étiquettes attachées à l'étape `dedup` n'étaient pas disponibles pour une utilisation ultérieure dans la requête.
+ Correction d'un bogue Gremlin qui empêchait la conversion d'une étape `repeat` dans une étape `union` en raison d'une erreur interne.
+ Correction des problèmes d'exactitude Gremlin pour les requêtes DFE utilisant `limit` comme traversée enfant des étapes autres que l'union en revenant à Tinkerpop. Les requêtes sous la forme suivante sont affectées :
```
g.withSideEffect('Neptune#useDFE', true).V().as("a").select("a").by(out().limit(1))
```
+ Correction d'un bogue SPARQL qui empêchait les modèles `SPARQL GRAPH` de prendre en compte le jeu de données fourni par une clause `FROM NAMED`.
+ Correction d'un bogue SPARQL en raison duquel le SPARQL, `DESCRIBE` avec certaines `FROM` and/or `FROM NAMED` clauses, n'utilisait pas toujours correctement les données du graphe par défaut et lançait parfois une exception. Consultez [Comportement de SPARQL DESCRIBE par rapport au graphe par défaut](sparql-default-describe.md).
+ Correction d'un bogue SPARQL qui renvoyait le message d'exception correct en cas de rejet de caractères null.
+ Correction d'un bogue d'[explication](sparql-explain.md) dans le SPARQL qui affectait les plans contenant un [PipelinedHashIndexJoin](sparql-explain-operators.md#sparql-explain-operator-pipeline-hash-index-join)opérateur.
+ Correction d'un bogue qui provoquait le déclenchement d'une erreur interne lorsqu'une requête renvoyant une valeur de constante était soumise.
+ Correction d'un problème lié à la logique du détecteur de blocage qui empêchait parfois le moteur de répondre.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.1.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.2`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.1`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.1.0
[Vous pouvez effectuer une mise à niveau manuelle vers cette version à partir de n'importe quelle version de moteur Neptune précédente supérieure ou égale à 1.1.0.0.](engine-releases-1.1.0.0.md)
**Note**
À partir de la [version 1.2.0.0 du moteur](engine-releases-1.2.0.0.md), tous les groupes de paramètres personnalisés et les groupes de paramètres de cluster personnalisés que vous utilisiez avec les versions de moteur antérieures à `1.2.0.0` doivent désormais être recréés à l'aide de la famille `neptune1.2` de groupes de paramètres. Les versions précédentes utilisaient une famille de groupes de paramètres `neptune1`, et ces groupes de paramètres ne fonctionnent pas avec les versions `1.2.0.0` et ultérieures. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md).
La mise à niveau vers cette version majeure n'est pas automatique.
## Mise à niveau vers cette version
Amazon Neptune 1.2.1.0 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.1.0.R7 du moteur Amazon Neptune (06-10-2023)
Depuis le 06-10-2023, la version 1.2.1.0.R7 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue au cours duquel une transaction ayant échoué n'était pas toujours correctement clôturée.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.1.0.R7, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.2`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Mise à niveau vers cette version
Amazon Neptune 1.2.1.0.R7 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.1.0.R6 du moteur Amazon Neptune (12/09/2023)
Depuis le 12 septembre 2023, la version 1.2.1.0.R6 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Nouvelles fonctionnalités pour cette version du moteur
+ Publication de l'[API de données Neptune](data-api.md).
L'API de données Amazon Neptune fournit une prise en charge de kit SDK pour le chargement de données, l'exécution de requêtes, l'obtention d'informations sur vos données et l'exécution d'opérations de machine learning. Elle prend en charge les langages de requête Gremlin et openCypher dans Neptune et est disponible dans tous les langages de kit SDK. Elle signe automatiquement les demandes d'API et simplifie considérablement l'intégration de Neptune dans les applications.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue qui pouvait provoquer des pics d'activité du CPU sous des charges élevées lorsque les journaux Slow Query étaient activés.
+ Correction d'un bogue Gremlin où l'ajout d'une arête et de ses propriétés suivi de `inV()` ou de `outV()` levait une exception `InternalFailureException`.
+ Correction de plusieurs problèmes liés au chaînage des rôles IAM, problèmes qui entraînaient une dégradation des performances des chargeurs en bloc dans certains cas.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.1.0.R6, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.2`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Mise à niveau vers cette version
Amazon Neptune 1.2.1.0.R6 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.1.0.R5 du moteur Amazon Neptune (02/09/2023)
Depuis le 2 septembre 2023, la version 1.2.1.0.R5 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Nouvelles fonctionnalités pour cette version du moteur
+ Publication de l'[API de données Neptune](data-api.md).
L'API de données Amazon Neptune fournit une prise en charge de kit SDK pour le chargement de données, l'exécution de requêtes, l'obtention d'informations sur vos données et l'exécution d'opérations de machine learning. Elle prend en charge les langages de requête Gremlin et openCypher dans Neptune et est disponible dans tous les langages de kit SDK. Elle signe automatiquement les demandes d'API et simplifie considérablement l'intégration de Neptune dans les applications.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin où l'ajout d'une arête et de ses propriétés suivi de `inV()` ou de `outV()` levait une exception `InternalFailureException`.
+ Correction de plusieurs problèmes liés au chaînage des rôles IAM, problèmes qui entraînaient une dégradation des performances des chargeurs en bloc dans certains cas.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.1.0.R5, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.2`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Mise à niveau vers cette version
Amazon Neptune 1.2.1.0.R5 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.1.0.R4 du moteur Amazon Neptune (10/08/2023)
Depuis le 10 août 2023, la version 1.2.1.0.R4 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
Les modifications apportées à cette version du moteur peuvent, dans certains cas, entraîner une dégradation des performances de chargement en bloc. Par conséquent, les mises à niveau de cette version ont été temporairement suspendues jusqu'à ce que le problème soit résolu.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
+ Ajout de la prise en charge de [Graphson-1.0](https://tinkerpop.apache.org/docs/3.4.1/dev/io/#graphson) pour Gremlin. Pour utiliser Graphson-1.0, transmettez `Accept header` avec la valeur :
```
application/vnd.gremlin-v1.0+json;types=false
```
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin qui provoquait une fuite de transaction lors de la vérification du point de terminaison de statut d'une requête Gremlin pour détecter les requêtes contenant des prédicats dans les traversées enfants pour les étapes qui ne sont pas traitées nativement.
+ Correction d'un bogue openCypher lié à la gestion des transactions Bolt.
+ Correction d'un problème de simultanéité sur la couche de stockage qui pouvait provoquer un plantage.
+ Correction d'un bogue dans les journaux de requêtes lentes afin de s'assurer qu'ils ne sont pas actifs lorsqu'ils sont désactivés.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.1.0.R4, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.5`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.1.0.R4
## Mise à niveau vers cette version
Amazon Neptune 1.2.1.0.R4 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.1.0.R3 du moteur Amazon Neptune (13/06/2023)
Depuis le 13 juin 2023, la version 1.2.1.0.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
Les modifications apportées à cette version du moteur peuvent, dans certains cas, entraîner une dégradation des performances de chargement en bloc. Par conséquent, les mises à niveau de cette version ont été temporairement suspendues jusqu'à ce que le problème soit résolu.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout de la prise en charge du chargement en bloc entre comptes à l'aide du [chaînage des rôles IAM](bulk-load-tutorial-chain-roles.md).
## Améliorations de cette version du moteur
+ Amélioration de l'étape `fail()` utilisée par Gremlin pour différencier l'exception produite à partir d'une exception `InternalFailureException` générique et pour garantir que tout message fourni par l'utilisateur soit retransmis à l'appelant.
+ Amélioration des optimisations du moteur de requêtes Gremlin pour `store`, `aggregate`, `cap`, `limit` et `hasLabel`.
+ Ajout de la prise en charge des fonctions trignométriques openCypher :
+ `acos()`
+ `asin()`
+ `atan()`
+ `atan2()`
+ `cos()`
+ `cot()`
+ `degrees()`
+ `pi()`
+ `radians()`
+ `sin()`
+ `tan()`
+ Ajout de la prise en charge de plusieurs fonctions d'agrégation openCypher :
+ `percentileDisc()`
+ `stDev()`
+ Ajout de la prise en charge de la fonction `epochmillis()` openCypher qui convertit un objet `datetime` en `epochmillis`. Par exemple :
```
MATCH (n) RETURN epochMillis(n.someDateTime)
1698972364782
```
+ Ajout de la prise en charge de l'opérateur modulo (`%`) openCypher.
+ Ajout de la prise en charge de l'outil openCypher Static Debug Explain.
+ Ajout de la prise en charge de la fonction openCypher `randomUUID()`.
+ Amélioration des performances d'openCypher :
+ Amélioration de l'analyseur et du planificateur de requêtes.
+ Utilisation améliorée du CPU dans le moteur DFE.
+ Amélioration des performances des requêtes contenant plusieurs clauses de mise à jour réutilisant les mêmes variables. Voici quelques exemples :
```
MERGE (n {name: 'John'})
or
MERGE (m {name: 'Jim'})
or
MERGE (n)-[:knows {since: 2023}]→(m)
```
+ Plans de requêtes optimisés pour les modèles de requêtes à sauts multiples tels que :
```
MATCH (n)-->()-->()-->(m)
RETURN n m
```
+ Amélioration des performances de l'injection de listes et de mappages grâce à des requêtes paramétrées. Par exemple :
```
UNWIND $idList as id MATCH (n {`~id`: id})
RETURN n.name
```
+ Amélioration de l'exécution des requêtes contenant `WITH` en en faisant une barrière appropriée.
+ Optimisation pour éviter la matérialisation redondante des valeurs `Unfold` et dans les fonctions d'agrégation.
+ Amélioration des performances des requêtes SPARQL qui contiennent un grand nombre d'entrées statiques dans la clause `VALUES`, telles que :
```
SELECT ?n WHERE { VALUES (?name) { ("John") ("Jim") ... many values ... } ?n a ?n_type . ?n ?name . }
```
+ Amélioration des performances des requêtes SPARQL CBD.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin à cause duquel les requêtes longues avec imbrication profonde entraînaient une utilisation élevée du CPU et l'expiration des requêtes pendant la phase de planification des requêtes.
+ Correction d'un bogue Gremlin où une exception `NullPointerException` non valide pouvait être levée lors de l'utilisation de `mergeV` ou `mergeE`.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.1.0.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.2`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.1.0.R3
## Mise à niveau vers cette version
Amazon Neptune 1.2.1.0.R3 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.1.0.R2 du moteur Amazon Neptune (02/05/2023)
Depuis le 2 mai 2023, la version 1.2.1.0.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau depuis une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
+ Ajout d'un `enableInterContainerTrafficEncryption` paramètre à tous les [Neptune ML APIs](machine-learning-api-reference.md), que vous pouvez utiliser pour activer et désactiver le chiffrement du trafic entre conteneurs dans le cadre de tâches d'entraînement ou de réglage d'hyperparamètres.
+ Ajout de la prise en charge de plusieurs étiquettes pour les étapes Gremlin `mergeV()` et `mergeE()`.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue openCypher en raison duquel les requêtes de mise à jour et de retour ne géraient pas `orderBy`, `limit` ni `skip` correctement.
+ Correction d'un bogue openCypher qui permettait de remplacer les paramètres contenus dans une requête par des paramètres contenus dans une autre requête simultanée.
+ Correction d'un bogue openCypher en raison duquel les journaux de requêtes lentes ne contenaient pas les durées correctes des requêtes.
+ Correction d'un bogue Gremlin qui provoquait une fuite de transaction lorsqu'une requête contenant `GroupCountStep` était soumise sous forme de chaîne.
+ Correction d'un bogue de Gremlin à cause duquel WebSocket les requêtes échouaient lorsque les journaux de requêtes lents étaient activés.
+ Correction d'un bogue de Gremlin en raison duquel les journaux de débogage du compteur de stockage manquaient dans les journaux de requêtes lents pour les requêtes. WebSocket
+ Correction de plusieurs bogues Gremlin impliquant `mergeV()` et `mergeE()`.
+ Correction d'un bogue SPARQL en raison duquel les coûts des requêtes de graphes nommés étaient mal estimés, ce qui entraînait des plans de requêtes sous-optimaux et des erreurs. out-of-memory
+ Correction d'un bogue concernant l'autorisation pour les requêtes Gremlin et openCypher sur un cluster compatible IAM.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.1.0.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.6.2`
+ *Dernière version de Gremlin est prise en charge :* `3.6.2`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.1.0.R2
## Mise à niveau vers cette version
Amazon Neptune 1.2.1.0.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.2 du moteur Amazon Neptune (20/11/2022)
Depuis le 20 novembre 2022, la version 1.2.0.2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.2.0.2.R2 (15/12/2022)](engine-releases-1.2.0.2.R2.md)
+ [Sortie : 1.2.0.2.R3 (27/03/2023)](engine-releases-1.2.0.2.R3.md)
+ [Sortie : 1.2.0.2.R4 (08/05/2023)](engine-releases-1.2.0.2.R4.md)
+ [Sortie : 1.2.0.2.R5 (16/08/2023)](engine-releases-1.2.0.2.R5.md)
+ [Sortie : 1.2.0.2.R6 (12/09/2023)](engine-releases-1.2.0.2.R6.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout de l'[inférence inductive en temps réel](machine-learning-overview-evolving-data.md#inductive-vs-transductive-inference) pour Gremlin dans Neptune ML.
+ Introduction d'une extension OpenCypher qui permet de spécifier des [valeurs d'identification personnalisées pour les entités](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) au lieu de celles que UUIDs Neptune génère autrement. La possibilité d'attribuer des options personnalisées IDs facilite la migration de Neo4j vers Neptune.
**Avertissement**
Cette extension de la spécification openCypher n'est pas rétrocompatible, car `~id` est désormais considéré comme un nom de propriété réservé. Si vous utilisez déjà `~id` en tant que propriété dans vos données et requêtes, vous devrez [migrer la propriété `~id` vers une nouvelle clé de propriété](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids-migrating) avant de passer à cette version.
+ Ajout de [plusieurs nouveaux modes `DESCRIBE` SPARQL](sparql-query-hints-for-describe.md) ainsi que d'indicateurs de requête pour les configurer.
## Améliorations de cette version du moteur
+ Amélioration des performances d'openCypher, en particulier pour les requêtes VLP.
+ Amélioration des performances du DFE pour les requêtes Gremlin avec des limites autres que celles du terminal, telles que :
```
g.withSideEffect('Neptune#useDFE',true).V().hasLabel('Student').limit(5).out('takesCourse')
```
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.2
## Mise à niveau vers cette version
Amazon Neptune 1.2.0.2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.2.R6 du moteur Amazon Neptune (12/09/2023)
Depuis le 12 septembre 2023, la version 1.2.0.2.R6 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue SPARQL qui empêchait l'opérateur `REGEX` d'aboutir lorsqu'il était appelé sur un littéral balisé dans un langage.
+ Résolution d'un problème qui dégradait les performances de chargement en bloc.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.2.R6, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.5`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.2.R6
Votre cluster de bases de données Neptune sera automatiquement mis à niveau vers cette version de correctif de maintenance lors de la prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.2.0.2`.
## Mise à niveau vers cette version
Amazon Neptune 1.2.0.2.R6 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.2.R5 du moteur Amazon Neptune (16/08/2023)
Depuis le 16 août 2023, la version 1.2.0.2.R5 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
Les modifications apportées à cette version du moteur peuvent, dans certains cas, entraîner une dégradation des performances de chargement en bloc. Par conséquent, les mises à niveau de cette version ont été temporairement suspendues jusqu'à ce que le problème soit résolu.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin en raison duquel `order()` empêchait de trier correctement les sorties de chaînes lorsque certaines d'entre elles contenaient un espace.
+ Correction d'un bogue Gremlin qui provoquait une fuite de transaction lors de la vérification du point de terminaison de statut d'une requête Gremlin pour détecter les requêtes contenant des prédicats dans les traversées enfants pour les étapes qui ne sont pas traitées nativement.
+ Correction d'un bogue openCypher lié à la gestion des transactions Bolt.
+ Correction d'un problème de simultanéité sur la couche de stockage qui pouvait provoquer un plantage.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.2.R5, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.5`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.2.R5
Votre cluster de bases de données Neptune sera automatiquement mis à niveau vers cette version de correctif de maintenance lors de la prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.2.0.2`.
## Mise à niveau vers cette version
Amazon Neptune 1.2.0.2.R5 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.2.R4 du moteur Amazon Neptune (08/05/2023)
Depuis le 8 mai 2023, la version 1.2.0.2.R4 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue SPARQL en raison duquel un grand nombre de valeurs injectées via une clause `VALUES` pouvait entraîner une dégradation des performances.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.2.R4, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.6`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.2.R4
Votre cluster de bases de données Neptune sera automatiquement mis à niveau vers cette version de correctif de maintenance lors de la prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.2.0.2`.
## Mise à niveau vers cette version
Amazon Neptune 1.2.0.2.R4 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.2.R3 du moteur Amazon Neptune (27/03/2023)
Depuis le 27 mars 2023, la version 1.2.0.2.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
+ Pour les clusters de base de données sans serveur, le paramètre de capacité minimale a été modifié à 1,0 NCU et le paramètre maximum valide le plus bas à 2,5. NCUs Consultez [Mise à l'échelle de la capacité dans un cluster de bases de données Neptune sans serveur](neptune-serverless-capacity-scaling.md).
+ Ajout d'un `enableInterContainerTrafficEncryption` paramètre à tous les [Neptune ML APIs](machine-learning-api-reference.md), que vous pouvez utiliser pour activer et désactiver le chiffrement du trafic entre conteneurs dans le cadre de tâches d'entraînement ou de réglage d'hyperparamètres.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin qui empêchait la reconnaissance de la syntaxe Gremlin `option(Predicate)` comme étant valide.
+ Correction d'un bogue Gremlin qui empêchait le nettoyage correct des requêtes en cas d'échec parce qu'elles contenaient trop d'étapes.
+ Correction des problèmes d'exactitude Gremlin pour les requêtes DFE utilisant `limit` comme traversée enfant des étapes autres que l'union en revenant à Tinkerpop. Voici un exemple de requête de ce type :
```
g.withSideEffect('Neptune#useDFE', true).V().as("a").select("a").by(out().limit(1))
```
+ Correction d'une fuite potentielle de transaction Gremlin lorsqu'une requête soumise sous forme de chaîne contient `GroupCountStep`.
+ Correction d'un bogue openCypher où la valeur du type de paramètre ne faisait pas toujours l'objet d'une inférence correcte pour une liste ou une liste de mappages.
+ Correction d'un bogue openCypher en raison duquel les requêtes de mise à jour et de retour ne géraient pas `orderBy`, `limit` ni `skip` correctement.
+ Correction d'un bogue openCypher qui permettait de remplacer les paramètres contenus dans une requête par des paramètres contenus dans une autre requête simultanée.
+ Correction d'un bogue SPARQL en raison duquel un grand nombre de valeurs injectées dans une clause `VALUES` pouvait entraîner une dégradation des performances.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.2.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.6`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.2.R3
Votre cluster de bases de données Neptune sera automatiquement mis à niveau vers cette version de correctif de maintenance lors de la prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.2.0.2`.
## Mise à niveau vers cette version
Amazon Neptune 1.2.0.2.R3 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.2.R2 du moteur Amazon Neptune (15/12/2022)
Depuis le 15 décembre 2022, la version 1.2.0.2.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
+ Amélioration des performances des requêtes openCypher impliquant `MERGE` et `OPTIONAL MATCH`.
+ Amélioration des performances des requêtes openCypher impliquant `UNWIND` pour une liste de mappages de valeurs littérales.
+ Amélioration des performances des requêtes openCypher dotées d'un filtre `IN` pour `id`. Par exemple :
```
MATCH (n) WHERE id(n) IN ['1', '2', '3'] RETURN n
```
+ Amélioration des performances et corrections de divers opérateurs Gremlin, notamment `repeat`, `coalesce`, `store` et `aggregate`.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue openCypher où les requêtes renvoyaient la chaîne `"null"` au lieu d'une valeur nulle dans Bolt et SPARQL-JSON.
+ Correction d'un bogue Gremlin qui empêchait la propagation d'une étiquette d'étape attachée à `UnionStep` au dernier élément de chemin de ses traversées enfants.
+ Correction d'un bogue Gremlin qui empêchait l'optimisation de `valueMap()` lors d'une traversée `by()` dans le moteur DFE.
+ Correction d'un bogue Gremlin qui empêchait les lignes de se verrouiller avec les requêtes de lecture exécutées dans le cadre d'une transaction Gremlin plus longue.
+ Correction d'un bogue du journal d'audit qui entraînait la journalisation d'informations inutiles et l'absence de certains champs dans les journaux.
+ Correction d'un bogue du journal d'audit en raison duquel l'ARN IAM des requêtes HTTP adressées à un cluster de bases de données compatible IAM n'était pas enregistré.
+ Correction d'un bogue dans le cache de recherche afin de limiter la mémoire incrémentielle utilisée pour les écritures dans le cache.
+ Correction d'un bogue du cache de recherche qui impliquait la définition du mode lecture seule pour le cache de recherche en cas d'échec des écritures.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.2.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.2.R2
Votre cluster de bases de données Neptune sera automatiquement mis à niveau vers cette version de correctif de maintenance lors de la prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.2.0.2`.
## Mise à niveau vers cette version
Amazon Neptune 1.2.0.2.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.1 du moteur Amazon Neptune (26/10/2022)
Depuis le 26 octobre 2022, la version 1.2.0.1 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Versions de correctifs ultérieures pour cette version
+ [Version de maintenance : 1.2.0.1.R2 (13/12/2022)](engine-releases-1.2.0.1.R2.md)
+ [Version de maintenance : 1.2.0.1.R3 (27/09/2023)](engine-releases-1.2.0.1.R3.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout d'[Amazon Neptune sans serveur](neptune-serverless.md), une configuration d'autoscaling à la demande qui fait évoluer la capacité de votre cluster de bases de données en fonction de l'augmentation ou de la baisse des besoins de traitement.
## Améliorations de cette version du moteur
+ Amélioration des performances des requêtes Gremlin `order-by`. Les requêtes Gremlin avec `order-by` à la fin d'une étape `NeptuneGraphQueryStep` utilisent désormais une taille de bloc plus grande pour de meilleures performances. Cela ne s'applique pas à `order-by` sur un nœud interne (non racine) du plan de requête.
+ Amélioration des performances des requêtes de mise à jour Gremlin. Les sommets et les arêtes doivent désormais être verrouillés pour empêcher toute suppression lors de l'ajout d'arêtes ou de propriétés. Cette modification élimine les verrouillages en double au sein d'une transaction, ce qui améliore les performances.
+ Amélioration des performances des requêtes Gremlin qui utilisent `dedup()` l'intérieur d'une sous-requête `repeat()` en la redirigeant `dedup` jusqu'à la couche d'exécution native.
+ Ajout de messages d'erreur conviviaux pour les erreurs d'authentification IAM. Ces messages affichent désormais l'ARN de votre utilisateur ou rôle IAM, l'ARN de la ressource et une liste des actions non autorisées pour la demande. La liste des actions non autorisées vous permet de voir ce qui est peut manquer ou être explicitement refusé dans la politique IAM que vous utilisez.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue de Garmlin à cause duquel l'utilisation `PartitionStrategy` après la mise à niveau vers la version TinkerPop 3.5 entraînait une erreur avec le message « PartitionStrategy ne fonctionne pas avec les traversées anonymes », qui empêchait l'exécution de la traversée.
+ Correction d'un bogue d'exactitude Gremlin concernant la conversion de `WherePredicateStep`, où le moteur de requêtes de Neptune générait des résultats incorrects pour les requêtes utilisant `where(P.neq('x'))` et autres variantes.
+ Correction d'un bogue openCypher dans la clause `MERGE` qui, dans certains cas, provoquait la création de nœuds et d'arêtes en double.
+ Correction d'un bogue SPARQL lié au traitement des requêtes contenant `(NOT) EXISTS` dans une clause `OPTIONAL`, où il manquait les résultats des requêtes dans certains cas.
+ Correction d'un bogue du chargeur en bloc qui entraînait des régressions de performance sous de fortes charges d'insertion.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.1
## Mise à niveau vers cette version
Amazon Neptune 1.2.0.1 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.1.R3 du moteur Amazon Neptune (27/09/2023)
Depuis le 27 septembre 2023, la version 1.2.0.1.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
+ Ajout d'un `enableInterContainerTrafficEncryption` paramètre à tous les [Neptune ML APIs](machine-learning-api-reference.md), que vous pouvez utiliser pour activer et désactiver le chiffrement du trafic entre conteneurs dans le cadre de tâches d'entraînement ou de réglage d'hyperparamètres.
+ Pour les clusters de base de données sans serveur, le paramètre de capacité minimale a été modifié à 1,0 NCU et le paramètre maximum valide le plus bas à 2,5. NCUs Voir [Mise à l'échelle de la capacité dans un cluster de bases de données Neptune sans serveur](neptune-serverless-capacity-scaling.md) *(((before release, this change needs to be reflected in the serverless page too))).*
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue dans OpenCypher à cause duquel les update-and-return requêtes ne se géraient pas ou `skip` ne `orderBy` fonctionnaient pas `limit` correctement.
+ Correction d'un bogue openCypher qui permettait de remplacer les paramètres contenus dans une requête par des paramètres contenus dans une autre requête simultanée.
+ Correction d'un bogue openCypher lié à la gestion des transactions Bolt.
+ Correction des problèmes d'exactitude Gremlin pour les requêtes DFE utilisant `limit` comme traversée enfant des étapes autres que l'union en revenant à Tinkerpop. Par exemple, pour des requêtes comme celle-ci :
```
g.withSideEffect('Neptune#useDFE', true)
.V()
.as("a")
.select("a")
.by(out()
.limit(1))
```
+ Correction d'un bogue Gremlin qui empêchait une requête d'échouer parce qu'elle contenait trop d' TinkerPop étapes et ne pouvait donc pas être nettoyée.
+ Correction d'un bogue Gremlin en raison duquel `order()` empêchait de trier correctement les sorties de chaînes lorsque certaines d'entre elles contenaient un espace.
+ Correction d'un bogue Gremlin qui provoquait une fuite de transaction lorsqu'une requête était soumise sous forme de chaîne et contenait `GroupCountStep`.
+ Correction d'un bogue Gremlin qui provoquait une fuite de transaction lors de la vérification du point de terminaison de statut d'une requête Gremlin pour détecter les requêtes contenant des prédicats dans les traversées enfants pour les étapes qui ne sont pas traitées nativement.
+ Correction d'un bogue Gremlin où l'ajout d'une arête et de ses propriétés suivi de `inV()` ou de `outV()` levait une exception `InternalFailureException`.
+ Correction d'un problème de simultanéité dans la couche de stockage.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.1.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.6`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.1.R3
Votre cluster de bases de données Neptune sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la [version de moteur 1.2.0.1](engine-releases-1.2.0.1.md).
## Mise à niveau vers cette version
Amazon Neptune 1.2.0.1.R3 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.1.R2 du moteur Amazon Neptune (13/12/2022)
Depuis le 13 décembre 2022, la version 1.2.0.1.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
+ Amélioration des performances des requêtes openCypher impliquant `UNWIND` au niveau d'une liste de mappages de valeurs littérales.
+ Amélioration des performances et corrections de divers opérateurs Gremlin, notamment `repeat`, `coalesce`, `store` et `aggregate`.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue openCypher où les requêtes renvoyaient la chaîne `"null"` au lieu d'une valeur nulle dans Bolt et SPARQL-JSON.
+ Correction d'un bogue du journal d'audit qui entraînait la journalisation d'informations inutiles et l'absence de certains champs dans les journaux.
+ Correction d'un bogue dans le cache de recherche afin de limiter la mémoire incrémentielle utilisée pour les écritures dans le cache.
+ Correction d'un bogue du cache de recherche qui impliquait la définition du mode lecture seule pour le cache de recherche en cas d'échec des écritures.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.1.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.1.R2
Votre cluster de bases de données Neptune sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la [version de moteur 1.2.0.1](engine-releases-1.2.0.1.md).
## Mise à niveau vers cette version
Amazon Neptune 1.2.0.1.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.0 du moteur Amazon Neptune (21/07/2022)
Depuis le 21 juillet 2022, la version 1.2.0.0 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
La [version 1.2.0.0 du moteur](#engine-releases-1.2.0.0) 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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau depuis une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.2.0.0.R2 (14/10/2022)](engine-releases-1.2.0.0.R2.md)
+ [Sortie : 1.2.0.0.R3 (15/12/2022)](engine-releases-1.2.0.0.R3.md)
+ [Sortie : 1.2.0.0.R4 (29/09/2023)](engine-releases-1.2.0.0.R4.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout de la prise en charge des [bases de données globales](neptune-global-database.md). Une base de données globale Neptune couvre plusieurs Régions AWS bases de données et se compose d'un cluster de bases de données principal dans une région et d'un maximum de cinq clusters de bases de données secondaires dans d'autres régions.
+ Ajout de la prise en charge d'un contrôle d'accès plus granulaire dans les politiques IAM Neptune que ce qui était disponible auparavant, sur la base des actions du plan de données. Il s'agit d'un changement radical dans la mesure où les politiques IAM existantes basées sur l'action `connect` obsolète doivent être ajustées pour utiliser les actions du plan de données plus granulaires. Consultez [Types de politique IAM](security-iam-access-manage.md#iam-auth-policy).
+ Disponibilité améliorée des instances de lecteur. Auparavant, lors du redémarrage d'une instance d'enregistreur, toutes les instances de lecteur d'un cluster Neptune redémarraient également. À partir de la version 1.2.0.0 du moteur, les instances de lecteur restent actives après le redémarrage de l'instance d'enregistreur, ce qui améliore la disponibilité des instances de lecteur. Les instances de lecteur peuvent être redémarrées séparément pour prendre en compte les modifications apportées aux groupes de paramètres. Consultez [Redémarrage d'une instance de base de données dans Amazon Neptune](manage-console-instances-reboot.md).
+ Ajout d'un nouveau paramètre de cluster de bases de données [neptune\$1streams\$1expiry\$1days](parameters.md#parameters-db-cluster-parameters-neptune_streams_expiry_days) qui vous permet de définir le nombre de jours pendant lesquels les enregistrements de flux sont conservés sur le serveur avant d'être supprimés. Cette plage est comprise entre 1 et 90, et la valeur par défaut est 7.
## Améliorations de cette version du moteur
+ Performances de sérialisation Gremlin améliorées pour ByteCode les requêtes.
+ Neptune traite désormais les prédicats de texte à l'aide du moteur DFE, pour de meilleures performances.
+ Neptune traite désormais les étapes `limit()` Gremlin à l'aide du moteur DFE, y compris les limites de traversée hors terminal et enfant.
+ Modification de la gestion DFE de l'étape `union()` Gremlin pour qu'elle fonctionne avec d'autres nouvelles fonctionnalités, ce qui signifie que les nœuds de référence apparaissent dans les profils de requête comme prévu.
+ Performances améliorées jusqu'à cinq fois de certaines opérations de jointure coûteuses au sein du DFE en les parallélisant.
+ Ajout de la prise en charge de la modulation `by()` pour `OrderGlobalStep order(global)` pour le moteur DFE Gremlin.
+ Ajout de l'affichage des valeurs statiques injectées dans les détails de la fonctionnalité explain du DFE.
+ Amélioration des performances lors du nettoyage des modèles dupliqués.
+ Ajout de la prise en charge de la préservation des commandes dans le moteur DFE Gremlin.
+ Amélioration des performances des requêtes Gremlin comportant des filtres vides, par exemple :
```
g.V().hasId(P.within([]))
```
```
g.V().hasId([])
```
+ Amélioration des messages d'erreur lorsqu'une requête SPARQL utilise une valeur numérique trop grande pour que Neptune puisse la représenter en interne.
+ Amélioration des performances de la suppression de sommets associés à des arêtes en réduisant les recherches d'index lorsque les flux sont désactivés.
+ Support DFE étendu à un plus grand nombre de variantes de l'`has()`étape, en particulier à `hasKey()``hasLabel()`, et à la plage de prédicats pour strings/URIs within. `has()` Cela concerne les requêtes telles que les suivantes :
```
// hasKey() on properties
g.V().properties().hasKey("name")
g.V().properties().has(T.key, TextP.startingWith("a"))
g.E().properties().hasKey("weight")
g.E().properties().hasKey(TextP.containing("t"))
// hasLabel() on vertex properties
g.V().properties().hasLabel("name")
// range predicates on ID and Label fields
g.V().has(T.label, gt("person"))
g.E().has(T.id, lte("(an ID value)"))
```
+ Ajout d'une fonction openCypher [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) spécifique à Neptune qui concatène les chaînes d'une liste en une seule chaîne.
+ Mise à jour des [politiques gérées par Neptune](security-iam-access-managed-policies.md) pour inclure les autorisations d'accès aux données et les autorisations pour la nouvelle base de données mondiale. APIs
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue en raison duquel une requête HTTP sans type de contenu spécifié échouait automatiquement.
+ Correction d'un bogue SPARQL dans l'optimiseur de requêtes qui empêchait l'utilisation d'un appel de service dans une requête.
+ Correction d'un bogue SPARQL dans l'analyseur Turtle RDF à cause duquel une combinaison particulière de données Unicode provoquait un échec.
+ Correction d'un bogue SPARQL en raison duquel une combinaison particulière de clauses `GRAPH` et `SELECT` générait des résultats de requête incorrects.
+ Correction d'un bogue Gremlin qui provoquait un problème d'exactitude pour les requêtes utilisant n'importe quelle étape de filtre au sein d'une étape d'union, comme suit :
```
g.V("1").union(hasLabel("person"), out())
```
+ Correction d'un bogue Gremlin où la valeur `count()` de `both().simplePath()` multipliait par deux le nombre réel de résultats renvoyés sans `count()`.
+ Correction d'un bogue openCypher en raison duquel une exception de non-correspondance de signature défectueuse était générée par le serveur pour les requêtes Bolt adressées aux clusters avec l'authentification IAM activée.
+ Correction d'un bogue openCypher où une requête utilisant HTTP keep-alive pouvait être fermée de manière incorrecte si elle était soumise après l'échec d'une demande.
+ Correction d'un bogue openCypher qui pouvait provoquer le déclenchement d'une erreur interne lorsqu'une requête renvoyant une valeur de constante était soumise.
+ Correction d'un bogue lié aux détails de la fonctionnalité explaon, de sorte que la sous-requête DFE `Time(ms)` additionne désormais correctement les temps CPU des opérateurs au sein de la sous-requête DFE. Prenons l'extrait suivant représentant la sortie de la fonctionnalité explain à titre d'exemple :
```
subQuery1
╔════╤════════╤════════╤═══════════════════════╤═══════════════════════════════════╤══════╤══════════╤═══════════╤═══════╤═══════════╗
║ ID │ Out #1 │ Out #2 │ Name │ Arguments │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║
╠════╪════════╪════════╪═══════════════════════╪═══════════════════════════════════╪══════╪══════════╪═══════════╪═══════╪═══════════╣
...
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 1 │ 2 │ - │ DFEChunkLocalSubQuery │ subQuery=...graph#336e.../graph_1 │ - │ 1 │ 1 │ 1.00 │ 0.38 ║
║ │ │ │ │ coordinationTime(ms)=0.026 │ │ │ │ │ ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
...
subQuery=...graph#336e.../graph_1
╔════╤════════╤════════╤═══════════════════════╤═══════════════════════════════════╤══════╤══════════╤═══════════╤═══════╤═══════════╗
║ ID │ Out #1 │ Out #2 │ Name │ Arguments │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║
╠════╪════════╪════════╪═══════════════════════╪═══════════════════════════════════╪══════╪══════════╪═══════════╪═══════╪═══════════╣
║ 0 │ 1 │ - │ DFESolutionInjection │ solutions=[?100 -> [-10^^]] │ - │ 0 │ 1 │ 0.00 │ 0.04 ║
║ │ │ │ │ outSchema=[?100] │ │ │ │ │ ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 1 │ 3 │ - │ DFERelationalJoin │ joinVars=[] │ - │ 2 │ 1 │ 0.50 │ 0.29 ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 2 │ 1 │ - │ DFESolutionInjection │ outSchema=[] │ - │ 0 │ 1 │ 0.00 │ 0.01 ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 3 │ - │ - │ DFEDrain │ - │ - │ 1 │ 0 │ 0.00 │ 0.02 ║
╚════╧════════╧════════╧═══════════════════════╧═══════════════════════════════════╧══════╧══════════╧═══════════╧═══════╧═══════════╝
```
Le total des durées des sous-requêtes dans la dernière colonne du tableau inférieur s'élève à 0,36 ms (`.04 + .29 + .01 + .02 = .36`). Lorsque vous ajoutez le temps de coordination de cette sous-requête (`.36 + .026 = .386`), vous obtenez un résultat proche de a durée de la sous-requête enregistrée dans la dernière colonne du tableau supérieur, à savoir `0.38` ms.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.0
Comme il s'agit d'une version majeure du moteur, la mise à niveau n'est pas automatique.
Vous ne pouvez effectuer une mise à niveau pour publier `1.2.0.0` manuellement qu'à partir de la dernière [version de correctif du moteur 1.1.1.0.](engine-releases-1.1.1.0.md) Les versions antérieures du moteur doivent d'abord être mises à niveau vers la dernière version `1.1.1.0` avant de pouvoir passer à la version `1.2.0.0`.
Par conséquent, avant d'essayer de passer à cette version, veuillez vérifier que vous exécuté actuellement le dernier correctif de la version `1.1.1.0`. Si ce n'est pas le cas, commencez par effectuer une mise à niveau vers la dernière version du correctif de `1.1.1.0`.
Avant la mise à niveau, vous devez également recréer tout groupe de paramètres de cluster de bases de données personnalisé que vous utilisiez avec votre version précédente, à l'aide de la famille `neptune1.2` de groupes de paramètres. Pour plus d’informations, consultez [Groupes de paramètres Amazon Neptune](parameter-groups.md).
Si vous effectuez d'abord une mise à niveau vers une version, `1.1.1.0` puis immédiatement vers une version `1.2.0.0`, vous risquez de rencontrer une erreur telle que la suivante :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer (voir [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md)).
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.0.R4 du moteur Amazon Neptune (29/09/2023)
Depuis le 29 septembre 2023, la version 1.2.0.0.R4 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
+ Ajout d'un `enableInterContainerTrafficEncryption` paramètre à tous les [Neptune ML APIs](machine-learning-api-reference.md), que vous pouvez utiliser pour activer et désactiver le chiffrement du trafic entre conteneurs dans le cadre de tâches d'entraînement ou de réglage d'hyperparamètres.
+ Pour les clusters de base de données sans serveur, le paramètre de capacité minimale a été modifié à 1,0 NCU et le paramètre maximum valide le plus bas à 2,5. NCUs Voir [Mise à l'échelle de la capacité dans un cluster de bases de données Neptune sans serveur](neptune-serverless-capacity-scaling.md) *(((before release, this change needs to be reflected in the serverless page too))).*
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue dans OpenCypher à cause duquel les update-and-return requêtes ne se géraient pas ou `skip` ne `orderBy` fonctionnaient pas `limit` correctement.
+ Correction d'un bogue openCypher qui permettait de remplacer les paramètres contenus dans une requête par des paramètres contenus dans une autre requête simultanée.
+ Correction d'un bogue openCypher lié à la gestion des transactions Bolt.
+ Correction des problèmes d'exactitude Gremlin pour les requêtes DFE utilisant `limit` comme traversée enfant des étapes autres que l'union en revenant à Tinkerpop. Par exemple, pour des requêtes comme celle-ci :
```
g.withSideEffect('Neptune#useDFE', true)
.V()
.as("a")
.select("a")
.by(out()
.limit(1))
```
+ Correction d'un bogue Gremlin qui empêchait une requête d'échouer parce qu'elle contenait trop d' TinkerPop étapes et ne pouvait donc pas être nettoyée.
+ Correction d'un bogue Gremlin en raison duquel `order()` empêchait de trier correctement les sorties de chaînes lorsque certaines d'entre elles contenaient un espace.
+ Correction d'un bogue Gremlin qui provoquait une fuite de transaction lorsqu'une requête était soumise sous forme de chaîne et contenait `GroupCountStep`.
+ Correction d'un bogue Gremlin qui provoquait une fuite de transaction lors de la vérification du point de terminaison de statut d'une requête Gremlin pour détecter les requêtes contenant des prédicats dans les traversées enfants pour les étapes qui ne sont pas traitées nativement.
+ Correction d'un bogue Gremlin où l'ajout d'une arête et de ses propriétés suivi de `inV()` ou de `outV()` levait une exception `InternalFailureException`.
+ Correction d'un problème de simultanéité dans la couche de stockage.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.0.R4, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.6`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.0.R4
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.2.0.0`.
Vous ne pouvez effectuer une mise à niveau pour publier `1.2.0.0` manuellement qu'à partir de la dernière [version de correctif du moteur 1.1.1.0.](engine-releases-1.1.1.0.md) Les versions antérieures du moteur doivent d'abord être mises à niveau vers la dernière version `1.1.1.0` avant de pouvoir passer à la version `1.2.0.0`.
Si vous effectuez d'abord une mise à niveau vers une version, `1.1.1.0` puis immédiatement vers une version `1.2.0.0`, vous risquez de rencontrer une erreur telle que la suivante :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.0.R3 du moteur Amazon Neptune (15/12/2022)
Depuis le 15 décembre 2022, la version 1.2.0.0.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau depuis une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
+ Amélioration des performances des requêtes openCypher impliquant `MERGE` et `OPTIONAL MATCH`.
+ Amélioration des performances des requêtes openCypher impliquant `UNWIND` au niveau d'une liste de mappages de valeurs littérales.
+ Amélioration des performances des requêtes openCypher dotées d'un filtre `IN` pour `id`. Par exemple :
```
MATCH (n) WHERE id(n) IN ['1', '2', '3'] RETURN n
```
+ Amélioration des performances et corrections de divers opérateurs Gremlin, notamment `repeat`, `coalesce`, `store` et `aggregate`.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue openCypher où les requêtes renvoyaient la chaîne `"null"` au lieu d'une valeur nulle dans Bolt et SPARQL-JSON.
+ Correction d'un bogue openCypher afin de pouvoir interpréter correctement le type de paramètre lorsque la valeur est une liste ou une liste de mappages.
+ Correction d'un bogue du journal d'audit qui entraînait la journalisation d'informations inutiles et l'absence de certains champs dans les journaux.
+ Correction d'un bogue du journal d'audit en raison duquel l'ARN IAM des requêtes HTTP adressées à un cluster de bases de données compatible IAM n'était pas enregistré.
+ Correction d'un bogue dans le cache de recherche afin de limiter la mémoire incrémentielle utilisée pour les écritures dans le cache.
+ Correction d'un bogue du cache de recherche qui impliquait la définition du mode lecture seule pour le cache de recherche en cas d'échec des écritures.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.0.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.0.R3
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.2.0.0`.
Vous ne pouvez effectuer une mise à niveau pour publier `1.2.0.0` manuellement qu'à partir de la dernière [version de correctif du moteur 1.1.1.0.](engine-releases-1.1.1.0.md) Les versions antérieures du moteur doivent d'abord être mises à niveau vers la dernière version `1.1.1.0` avant de pouvoir passer à la version `1.2.0.0`.
Si vous effectuez d'abord une mise à niveau vers une version, `1.1.1.0` puis immédiatement vers une version `1.2.0.0`, vous risquez de rencontrer une erreur telle que la suivante :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.2.0.0.R2 du moteur Amazon Neptune (14/10/2022)
Depuis le 14 octobre 2022, la version 1.2.0.0.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Note**
**En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :**
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 comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés et la [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch métrique doit tomber à zéro avant qu'une mise à niveau à partir d'une version antérieure à 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.
Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. 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 l'`UndoLogsListSize` CloudWatch indicateur est extrêmement important, l'ouverture d'un dossier de support peut vous aider à explorer d'autres stratégies pour le réduire.
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).
## Améliorations de cette version du moteur
+ Amélioration des performances des requêtes Gremlin `order-by`. Les requêtes Gremlin avec `order-by` à la fin d'une étape `NeptuneGraphQueryStep` utilisent désormais une taille de bloc plus grande pour de meilleures performances. Cela ne s'applique pas à `order-by` sur un nœud interne (non racine) du plan de requête.
+ Amélioration des performances des requêtes de mise à jour Gremlin. Les sommets et les arêtes doivent désormais être verrouillés pour empêcher toute suppression lors de l'ajout d'arêtes ou de propriétés. Cette modification élimine les verrouillages en double au sein d'une transaction, ce qui améliore les performances.
+ Amélioration des performances des requêtes Gremlin qui utilisent `dedup()` l'intérieur d'une sous-requête `repeat()` en la redirigeant `dedup` jusqu'à la couche d'exécution native.
+ Ajout de l'indicateur de requête Gremlin `Neptune#cardinalityEstimates`. Lorsque cette valeur est définie sur `false`, les estimations de cardinalité sont désactivées.
+ Ajout de messages d'erreur conviviaux pour les erreurs d'authentification IAM. Ces messages affichent désormais l'ARN de votre utilisateur ou rôle IAM, l'ARN de la ressource et une liste des actions non autorisées pour la demande. La liste des actions non autorisées vous permet de voir ce qui est peut manquer ou être explicitement refusé dans la politique IAM que vous utilisez.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue d'exactitude Gremlin concernant la conversion de `WherePredicateStep`, où le moteur de requêtes de Neptune générait des résultats incorrects pour les requêtes utilisant `where(P.neq('x'))` et autres variantes.
+ Correction d'un bogue de Garmlin à cause duquel l'utilisation `PartitionStrategy` après la mise à niveau vers la version TinkerPop 3.5 entraînait une erreur avec le message « PartitionStrategy ne fonctionne pas avec les traversées anonymes », qui empêchait l'exécution de la traversée.
+ Correction de divers bogues Gremlin liés à la valeur `joinTime` d'une jointure finale et aux statistiques au sein des sous-groupes `Project.ASK`.
+ Correction d'un bogue openCypher dans la clause `MERGE` qui, dans certains cas, provoquait la création de nœuds et d'arêtes en double.
+ Correction d'un bogue de transaction qui permettait à une session d'insérer des données de graphe et de les valider même lorsque les insertions de dictionnaire simultanées correspondantes étaient annulées.
+ Correction d'un bogue du chargeur en bloc qui entraînait des régressions de performance sous de fortes charges d'insertion.
+ Correction d'un bogue SPARQL lié au traitement des requêtes contenant `(NOT) EXISTS` dans une clause `OPTIONAL`, où il manquait les résultats des requêtes dans certains cas.
+ Correction d'un bogue à cause duquel les pilotes pouvaient sembler bloqués lorsque les demandes étaient annulées en raison de leur expiration avant le début de leur évaluation. Il était possible de parvenir à cet état si tous les threads de traitement des requêtes du serveur étaient consommés pendant que des éléments de la file d'attente des demandes arrivaient à expiration. Comme l'expiration d'élément dans la file d'attente des demandes n'entraînait pas l'envoi immédiat de messages, les réponses semblaient rester en attente pour le client.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.0.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.2.0.0.R2
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.2.0.0`.
Vous ne pouvez effectuer une mise à niveau pour publier `1.2.0.0` manuellement qu'à partir de la dernière [version de correctif du moteur 1.1.1.0.](engine-releases-1.1.1.0.md) Les versions antérieures du moteur doivent d'abord être mises à niveau vers la dernière version `1.1.1.0` avant de pouvoir passer à la version `1.2.0.0`.
Si vous effectuez d'abord une mise à niveau vers une version, `1.1.1.0` puis immédiatement vers une version `1.2.0.0`, vous risquez de rencontrer une erreur telle que la suivante :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.2.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.2.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.1.0.0 du moteur Amazon Neptune (19/04/2022)
Depuis le 19 avril 2022, la version 1.1.1.0 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Afin de mener à bien la mise à niveau, chaque sous-réseau de chaque zone de disponibilité (AZ) doit disposer d'au moins une adresse IP disponible par instance Neptune. Par exemple, s'il existe une instance d'enregistreur et deux instances de lecteur dans le sous-réseau 1, et deux instances de lecteur dans le sous-réseau 2, le sous-réseau 1 doit avoir au moins trois adresses IP libres, tandis que le sous-réseau 2 doit avoir au moins deux adresses IP libres avant de commencer la mise à niveau.
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Versions de correctifs ultérieures pour cette version
+ [Version de maintenance 1.1.1.0.R2 (16/05/2022)](engine-releases-1.1.1.0.R2.md)
+ [Sortie : 1.1.1.0.R3 (07/06/2022)](engine-releases-1.1.1.0.R3.md)
+ [Sortie : 1.1.1.0.R4 (23/06/2022)](engine-releases-1.1.1.0.R4.md)
+ [Sortie : 1.1.1.0.R5 (21/07/2022)](engine-releases-1.1.1.0.R5.md)
+ [Sortie : 1.1.1.0.R6 (23/09/2022)](engine-releases-1.1.1.0.R6.md)
+ [Sortie : 1.1.1.0.R7 (23/01/2023)](engine-releases-1.1.1.0.R7.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Le [langage de requête openCypher](access-graph-opencypher.md) est maintenant disponible de manière globale en production.
**Avertissement**
Cette version apporte une modification majeure du code qui utilise openCypher avec l'authentification IAM. Dans la version préliminaire de Neptune pour openCypher, la chaîne hôte de la signature IAM incluait le protocole, tel que `bolt://`. Par exemple :
```
"Host":"bolt://(host URL):(port)"
```
À compter de cette version du moteur, ce protocole doit être omis :
```
"Host":"(host URL):(port)"
```
Pour obtenir des exemples, consultez [Utilisation du protocole Bolt](access-graph-opencypher-bolt.md).
+ Ajout du support pour TinkerPop `3.5.2`. Parmi les [modifications apportées dans cette version](https://github.com/apache/tinkerpop/blob/3.5.2/CHANGELOG.asciidoc#release-3-5-2) figurent la prise en charge des transactions à distance et la prise en charge du bytecode pour les sessions (avec [https://tinkerpop.apache.org/docs/current/reference/#transactions](https://tinkerpop.apache.org/docs/current/reference/#transactions)), ainsi que l'ajout de la fonction `datetime()` au langage Gremlin.
**Avertissement**
Plusieurs modifications importantes introduites dans les TinkerPop versions 3.5.0, 3.5.1 et 3.5.2 peuvent affecter votre code Gremlin. Par exemple, [l'utilisation de traversées générées par un enfant GraphTraversalSource comme](https://issues.apache.org/jira/browse/TINKERPOP-2361) celle-ci ne fonctionnera plus :. `g.V().union(identity(), g.V())`
Maintenant, utilisez plutôt une traversée anonyme comme celle-ci : `g.V().union(identity(), __.V())`.
+ Ajout de la prise en charge des [clés de condition globales AWS](iam-data-condition-keys.md#iam-data-global-condition-keys) que vous pouvez utiliser dans les [stratégies d'accès aux données IAM](iam-admin-policies.md) qui contrôlent l'accès aux données stockées dans un cluster de bases de données Neptune.
+ Le [moteur de requêtes Neptune DFE](neptune-dfe-engine.md) est désormais disponible globalement pour une utilisation en production avec le langage de requête openCypher, mais pas encore pour les requêtes Gremlin et SPARQL. Vous l'activez désormais en utilisant son propre paramètre d'instance [neptune\$1dfe\$1query\$1engine](parameters.md#parameters-instance-parameters-neptune_dfe_query_engine) plutôt que le paramètre lab-mode.
## Améliorations de cette version du moteur
+ Ajout de nouvelles fonctionnalités à [openCypher](access-graph-opencypher.md), telles que la prise en charge des requêtes paramétrées, la mise en cache de l'arbre syntaxique abstrait (AST) pour les requêtes paramétrées, des améliorations des chemins de longueur variable (VLP) ainsi que de nouveaux opérateurs et clauses. Consultez [Conformité aux spécifications OpenCypher dans Amazon Neptune](feature-opencypher-compliance.md) pour découvrir le niveau actuel de prise en charge des différents langages.
+ Amélioration significative des performances d'openCypher pour les charges de travail de lecture et d'écriture simples, ce qui se traduit par un débit supérieur à celui de la version 1.1.0.0.
+ Suppression des limitations bidirectionnelles et des limitations de profondeur d'openCypher gérant les chemins de longueur variable.
+ Prise en charge complèle dans le moteur DFE des prédicats Gremlin `within` et `without`, y compris lorsqu'ils sont combinés avec d'autres opérateurs de prédicats. Par exemple :
```
g.V().has('age', within(12, 15, 18).or(gt(30)))
```
+ Prise en charge étendue dans le moteur DFE de l'étape Gremlin `order` lorsque la portée est globale (c'est-à-dire autre qu'`order(local)`) et lorsque les modulateurs `by()` ne sont pas utilisés. Par exemple, cette requête bénéficierait désormais de la prise en charge DFE :
```
g.V().values("age").order()
```
+ Ajout d'un champ `isLastOp` au format de réponse du [journal des modifications de flux Neptune](streams-using-api-reponse.md) pour indiquer qu'un enregistrement est la dernière opération de sa transaction.
+ Amélioration significative des performances de journalisation des audits et réduction de la latence lorsque la journalisation des audits est activée.
+ Conversion du WebSocket bytecode Garmlin et des requêtes HTTP dans un format lisible par l'utilisateur dans les journaux d'audit. Les requêtes peuvent désormais être directement copiées depuis les journaux d'audit afin de pouvoir être exécutées dans les blocs-notes Neptune et ailleurs. Notez que cette modification du format actuel du journal d'audit constitue une modification majeure.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin rare en raison duquel aucun résultat n'était renvoyé lors de l'utilisation combinée des étapes `filter()` et `count()` imbriquées, comme dans la requête suivante :
```
g.V("1").filter(out("knows")
.filter(in("knows")
.hasId("notExists"))
.count())
```
+ Correction d'un bogue Gremlin qui renvoyait une erreur lors de l'utilisation d'un sommet stocké par une étape agrégée dans les traversées `to()` ou `from()` associées à une étape `addE`. Voici un exemple de requête de ce type :
```
g.V("id").aggregate("v").out().addE().to(select("v").unfold()))
```
+ Correction d'un bogue Gremlin en raison duquel l'étape `not` échouait dans le cas des arêtes lors de l'utilisation du moteur DFE. Par exemple :
```
g.V().not(V())
```
+ Correction d'un bogue Gremlin qui entraînait l'indisponibilité des valeurs `sideEffect` dans les traversées `to()` et `from()`.
+ Correction d'un bogue qui provoquait parfois une réinitialisation rapide déclenchant un basculement d'instance.
+ Correction d'un bogue lié au chargeur en bloc, qui empêchait la fermeture d'une transaction ayant échoué avant le début de la prochaine tâche de chargement.
+ Correction d'un bogue lié au chargeur en bloc, en raison duquel une insuffisance de mémoire pouvait provoquer un incident au niveau du système.
+ Ajout d'une nouvelle tentative pour corriger un bogue lié au chargeur en bloc, à cause duquel le chargeur n'attendait pas assez longtemps que les informations d'identification IAM soient disponibles après un basculement.
+ Correction d'un bogue en raison duquel le cache d'informations d'identification interne n'était pas correctement vidé pour les points de terminaison autres que ceux des requêtes, tels que le point de terminaison `status`.
+ Correction d'un bogue lié aux flux pour garantir que les numéros de séquence de validation des flux sont correctement ordonnés.
+ Correction d'un bogue en raison duquel les connexions de longue durée étaient interrompues avant dix jours sur les clusters compatibles IAM.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.0.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.1.0
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version. Notez que les versions antérieures à 1.1.0.0 mettront plus de temps à passer à cette version de moteur majeure.
La mise à niveau vers cette version n'est pas automatique.
## Mise à niveau vers cette version
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera indisponible à ce stade pendant environ six minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine neptune \
4. --engine-version 1.1.1.0 \
5. --allow-major-version-upgrade \
6. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine neptune ^
4. --engine-version 1.1.1.0 ^
5. --allow-major-version-upgrade ^
6. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser une mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.1.1.0.R7 du moteur Amazon Neptune (23/01/2023)
Depuis le 23 janvier 2023, la version 1.1.1.0.R7 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Afin de mener à bien la mise à niveau, chaque sous-réseau de chaque zone de disponibilité (AZ) doit disposer d'au moins une adresse IP disponible par instance Neptune. Par exemple, s'il existe une instance d'enregistreur et deux instances de lecteur dans le sous-réseau 1, et deux instances de lecteur dans le sous-réseau 2, le sous-réseau 1 doit avoir au moins trois adresses IP libres, tandis que le sous-réseau 2 doit avoir au moins deux adresses IP libres avant de commencer la mise à niveau.
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Améliorations de cette version du moteur
+ Amélioration des performances des requêtes openCypher impliquant `MERGE` et `OPTIONAL MATCH`.
+ Amélioration des performances des requêtes openCypher impliquant `UNWIND` pour une liste de mappages de valeurs littérales.
+ Amélioration des performances des requêtes openCypher dotées d'un filtre `IN` pour `id`. Par exemple :
```
MATCH (n) WHERE id(n) IN ['1', '2', '3'] RETURN n
```
+ Amélioration des performances et corrections de divers opérateurs Gremlin, notamment `repeat`, `coalesce`, `store` et `aggregate`.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue openCypher où une demande utilisant HTTP keep-alive pouvait être fermée de manière incorrecte si elle était soumise après l'échec d'une demande.
+ Correction d'un bogue openCypher où le type de paramètre n'était pas toujours correctement interprété pour une liste ou une liste de mappages.
+ Correction d'un bogue openCypher où les requêtes renvoyaient la chaîne `"null"` au lieu d'une valeur nulle dans Bolt et SPARQL-JSON.
+ Codes d'erreur et messages d'erreur OpenCypher corrigés en cas d'échec ou d'erreur liés au délai d'expiration des requêtes. out-of-memory
+ Correction d'un bogue Gremlin qui empêchait l'optimisation de `valueMap()` lors d'une traversée `by()` dans le moteur DFE.
+ Correction d'un problème lié à la logique du détecteur de blocage qui empêchait parfois le moteur de répondre.
+ Correction d'un bogue du journal d'audit qui entraînait la journalisation d'informations inutiles et l'absence de certains champs dans les journaux.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.1.0.R7, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.3`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.1.0.R7
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.1.1.0`.
## Mise à niveau vers cette version
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera indisponible à ce stade pendant environ six minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.1.1.0.R6 du moteur Amazon Neptune (23/09/2022)
Depuis le 23 septembre 2022, la version 1.1.1.0.R6 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Afin de mener à bien la mise à niveau, chaque sous-réseau de chaque zone de disponibilité (AZ) doit disposer d'au moins une adresse IP disponible par instance Neptune. Par exemple, s'il existe une instance d'enregistreur et deux instances de lecteur dans le sous-réseau 1, et deux instances de lecteur dans le sous-réseau 2, le sous-réseau 1 doit avoir au moins trois adresses IP libres, tandis que le sous-réseau 2 doit avoir au moins deux adresses IP libres avant de commencer la mise à niveau.
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Note**
Cette version apporte une modification majeure du code qui utilise openCypher avec l'authentification IAM. Jusqu'à présent, la chaîne d'hôte contenue dans la signature IAM incluait le protocole `bolt://`, par exemple :
```
"Host":"bolt://(host URL):(port)"
```
À compter de la version du moteur `1.1.1.0`, ce protocole doit être omis :
```
"Host":"(host URL):(port)"
```
Pour obtenir des exemples, consultez [Utilisation du protocole Bolt](access-graph-opencypher-bolt.md).
## Améliorations de cette version du moteur
+ Amélioration des performances des requêtes Gremlin `order-by`. Les requêtes Gremlin avec `order-by` à la fin d'une étape `NeptuneGraphQueryStep` utilisent désormais une taille de bloc plus grande pour de meilleures performances. Cela ne s'applique pas à `order-by` sur un nœud interne (non racine) du plan de requête.
+ Amélioration des performances des requêtes de mise à jour Gremlin. Les sommets et les arêtes doivent désormais être verrouillés pour empêcher toute suppression lors de l'ajout d'arêtes ou de propriétés. Cette modification élimine les verrouillages en double au sein d'une transaction, ce qui améliore les performances.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue openCypher dans la clause `MERGE` qui, dans certains cas, provoquait la création de nœuds et d'arêtes en double.
+ Correction d'un bogue lié au traitement des requêtes SPARQL contenant `(NOT) EXISTS` dans une clause `OPTIONAL` où il manquait les résultats des requêtes dans certains cas.
+ Correction d'un bogue qui retardait le redémarrage du serveur lorsqu'un chargement en bloc était en cours.
+ Correction d'un bogue où la traversée bidirectionnelle d'un modèle de longueur variable openCypher avec un filtre sur la propriété de relation provoquait une erreur. Un exemple de modèle à longueur variable de ce type est `(n)-[r*1..2]->(m)`.
+ Correction d'un bogue lié à la manière dont les données mises en cache sont renvoyées au client, avec une latence étonnamment longue dans certains cas.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.1.0.R6, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.1.0.R6
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.1.1.0`.
## Mise à niveau vers cette version
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera indisponible à ce stade pendant environ six minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.1.1.0.R5 du moteur Amazon Neptune (21/07/2022)
Depuis le 21 juillet 2022, la version 1.1.1.0.R5 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Afin de mener à bien la mise à niveau, chaque sous-réseau de chaque zone de disponibilité (AZ) doit disposer d'au moins une adresse IP disponible par instance Neptune. Par exemple, s'il existe une instance d'enregistreur et deux instances de lecteur dans le sous-réseau 1, et deux instances de lecteur dans le sous-réseau 2, le sous-réseau 1 doit avoir au moins trois adresses IP libres, tandis que le sous-réseau 2 doit avoir au moins deux adresses IP libres avant de commencer la mise à niveau.
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Note**
Cette version apporte une modification majeure du code qui utilise openCypher avec l'authentification IAM. Jusqu'à présent, la chaîne d'hôte contenue dans la signature IAM incluait le protocole `bolt://`, par exemple :
```
"Host":"bolt://(host URL):(port)"
```
À compter de la version du moteur `1.1.1.0`, ce protocole doit être omis :
```
"Host":"(host URL):(port)"
```
Pour obtenir des exemples, consultez [Utilisation du protocole Bolt](access-graph-opencypher-bolt.md).
## Améliorations de cette version du moteur
+ Améliorations apportées pour prendre en charge la détection des blocages.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue qui empêchait l'arrêt complet des clusters de bases de données dans certaines conditions.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.1.0.R5, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.1.0.R5
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.1.1.0`.
## Mise à niveau vers cette version
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera indisponible à ce stade pendant environ six minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.1.1.0.R4 du moteur Amazon Neptune (23/06/2022)
Depuis le 23 juin 2022, la version 1.1.1.0.R4 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Afin de mener à bien la mise à niveau, chaque sous-réseau de chaque zone de disponibilité (AZ) doit disposer d'au moins une adresse IP disponible par instance Neptune. Par exemple, s'il existe une instance d'enregistreur et deux instances de lecteur dans le sous-réseau 1, et deux instances de lecteur dans le sous-réseau 2, le sous-réseau 1 doit avoir au moins trois adresses IP libres, tandis que le sous-réseau 2 doit avoir au moins deux adresses IP libres avant de commencer la mise à niveau.
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Note**
Cette version apporte une modification majeure du code qui utilise openCypher avec l'authentification IAM. Jusqu'à présent, la chaîne d'hôte contenue dans la signature IAM incluait le protocole `bolt://`, par exemple :
```
"Host":"bolt://(host URL):(port)"
```
À compter de la version du moteur `1.1.1.0`, ce protocole doit être omis :
```
"Host":"(host URL):(port)"
```
Pour obtenir des exemples, consultez [Utilisation du protocole Bolt](access-graph-opencypher-bolt.md).
## Améliorations de cette version du moteur
+ Configuration d'instance mise à jour pour les types d'instance `x2g`.
+ Amélioration des performances des chutes de sommets.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin qui empêchait les solutions de maintenir un ordre stable pour une requête appelée plusieurs fois ou sur plusieurs lecteurs pour certains types de jointures ASK.
+ Nous avons également réduit la portée d'une modification apportée à la version précédente qui entraînait des régressions de performance pour certains types de jointures ASK dans Gremlin.
+ Correction d'un bogue Gremlin dans l'étape `union()` qui se produisait en cas d'entrée d'arête et de traversée vers un sommet dans les traversées enfants.
+ Correction d'un bogue dans le profil Gremlin qui signalait que certaines étapes n'étaient pas optimisées alors qu'elles l'étaient.
+ Correction d'un bogue SPARQL où les variables utilisées dans des expressions `FILTER` imbriquées dans des clauses `UNION` se voyaient attribuer des informations de portée non valides.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.1.0.R4, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.1.0.R4
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.1.1.0`.
## Mise à niveau vers cette version
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera indisponible à ce stade pendant environ six minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.1.1.0.R3 du moteur Amazon Neptune (07/06/2022)
Depuis le 7 juin 2022, la version 1.1.1.0.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Note**
Cette version apporte une modification majeure du code qui utilise openCypher avec l'authentification IAM. Jusqu'à présent, la chaîne d'hôte contenue dans la signature IAM incluait le protocole `bolt://`, par exemple :
```
"Host":"bolt://(host URL):(port)"
```
À compter de la version du moteur `1.1.1.0`, ce protocole doit être omis :
```
"Host":"(host URL):(port)"
```
Pour obtenir des exemples, consultez [Utilisation du protocole Bolt](access-graph-opencypher-bolt.md).
## Améliorations de cette version du moteur
+ Ajout de la prise en charge des types d'instances `x2g` basés sur Graviton2, types d'instances optimisés pour les charges de travail gourmandes en mémoire. Ils ne sont initialement disponibles qu'en quatre Régions AWS :
+ USA Est (Virginie du Nord) (`us-east-1`)
+ USA Est (Ohio) (`us-east-2`)
+ USA Ouest (Oregon) (`us-west-2`)
+ Europe (Irlande) (`eu-west-1`)
Pour plus d'informations, consultez la page [Tarification Neptune](https://aws.amazon.com/neptune/pricing/).
+ Performances améliorées des étapes de Gremlin impliquant plusieurs traversées d'arêtes ou de sommets, recherches de propriétés ou recherches d'étiquettes.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin lié au traitement de l'étape `otherV()` dans une traversée enfant.
+ Correction d'un bogue Gremlin dans les requêtes où `union` n'avait que des étapes de filtrage comme enfants. Par exemple :
```
g.V().union(has("name"), out("knows")).out()
```
+ Correction d'un bogue SPARQL où les variables utilisées dans des expressions `FILTER` imbriquées dans des clauses `UNION` se voyaient attribuer des informations de portée non valides.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.1.0.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.1.0.R3
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.1.1.0`.
## Mise à niveau vers cette version
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera indisponible à ce stade pendant environ six minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version de maintenance d'Amazon Neptune, version 1.1.1.0.R2 (16/05/2022)
Depuis le 16 mai 2022, la version 1.1.1.0.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Afin de mener à bien la mise à niveau, chaque sous-réseau de chaque zone de disponibilité (AZ) doit disposer d'au moins une adresse IP disponible par instance Neptune. Par exemple, s'il existe une instance d'enregistreur et deux instances de lecteur dans le sous-réseau 1, et deux instances de lecteur dans le sous-réseau 2, le sous-réseau 1 doit avoir au moins trois adresses IP libres, tandis que le sous-réseau 2 doit avoir au moins deux adresses IP libres avant de commencer la mise à niveau.
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Note**
Cette version apporte une modification majeure du code qui utilise openCypher avec l'authentification IAM. Jusqu'à présent, la chaîne d'hôte contenue dans la signature IAM incluait le protocole `bolt://`, par exemple :
```
"Host":"bolt://(host URL):(port)"
```
À compter de la version du moteur `1.1.1.0`, ce protocole doit être omis :
```
"Host":"(host URL):(port)"
```
Pour obtenir des exemples, consultez [Utilisation du protocole Bolt](access-graph-opencypher-bolt.md).
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.1.0.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Première version de Gremlin prise en charge :* `3.5.2`
+ *Dernière version de Gremlin est prise en charge :* `3.5.4`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.1.0.R2
Votre cluster sera automatiquement mis à niveau vers cette version de correctif de maintenance lors de la prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.1.1.0`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera indisponible à ce stade pendant environ six minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.1.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.1.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.1.0.0 du moteur Amazon Neptune (19/11/2021)
Depuis le 19 novembre 2021, la version 1.1.1.0 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Afin de mener à bien la mise à niveau, chaque sous-réseau de chaque zone de disponibilité (AZ) doit disposer d'au moins une adresse IP disponible par instance Neptune. Par exemple, s'il existe une instance d'enregistreur et deux instances de lecteur dans le sous-réseau 1, et deux instances de lecteur dans le sous-réseau 2, le sous-réseau 1 doit avoir au moins trois adresses IP libres, tandis que le sous-réseau 2 doit avoir au moins deux adresses IP libres avant de commencer la mise à niveau.
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Note**
À partir de cette version du moteur, Neptune [ne prend plus en charge les types d'instances `R4`](instance-types.md#instance-type-r4). Si vous utilisez une instance `R4` dans votre cluster de bases de données, vous devrez la remplacer manuellement par un autre type d'instance avant de passer à cette version. Si vous utilisez une instance d'enregistreur `R4`, suivez [ces instructions](best-practices-general-basic.md#best-practices-resize-instance) pour la déplacer.
## Versions de correctifs ultérieures pour cette version
+ [Version de maintenance 1.1.0.0.R2 (16/05/2022)](engine-releases-1.1.0.0.R2.md)
+ [Version de maintenance 1.1.0.0.R3 (23/12/2022)](engine-releases-1.1.0.0.R3.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Introduction d'instances de base de données `T4g` polyvalentes et `R6g` optimisées pour la mémoire, alimentées par le [processeur AWS Graviton2](https://aws.amazon.com/ec2/graviton/). Les instances basées sur Graviton2 offrent des performances nettement price/performance supérieures aux instances x86 comparables de génération actuelle pour diverses charges de travail. Les applications fonctionnent normalement sur ces nouveaux types d'instances. Il n'est donc pas nécessaire de transférer le code des applications lors de la mise à niveau vers ces nouveaux types d'instances.
Pour plus d'informations sur la disponibilité et la tarification d'une région, consultez la page [Tarification Amazon Neptune](https://aws.amazon.com/neptune/pricing/).
+ Ajout des [modèles personnalisés](machine-learning-custom-models.md) dans Neptune ML.
+ Ajout de la prise en charge des [requêtes d'inférence SPARQL](machine-learning-sparql-inference-queries.md) dans Neptune ML.
+ Ajout d'un [nouveau point de terminaison de flux](streams-using-api-call.md) pour les données du graphe de propriétés, à savoir :
```
https://Neptune-DNS:8182/propertygraph/stream
```
Le format de sortie de ce point de terminaison, nommé `PG_JSON`, est exactement le même que le format `GREMLIN_JSON` généré par l'ancien flux `gremlin/stream`.
Ce nouveau point de terminaison `propertygraph/stream` étend la prise en charge des flux Neptune à openCypher et remplace le point de terminaison `gremlin/stream` par le format de sortie `GREMLIN_JSON` associé.
## Améliorations de cette version du moteur
+ Améliorations apportées aux flux Neptune :
+ Ajout d'un champ `commitTimestamp` à l'objet `records` dans le [format de réponse du journal des modifications de flux Neptune](streams-using-api-reponse.md) afin de fournir un horodatage pour chaque enregistrement d'un flux de journal des modifications.
+ Ajout d'une valeur `LATEST` au paramètre `iteratorType`, vous permettant de récupérer le dernier ID d'événement valide dans les flux. Consultez [Appel de l'API Streams](streams-using-api-call.md).
+ Ajout de la prise en charge du [score de confiance de l'inférence](machine-learning-gremlin-inference-query-predicates.md#machine-learning-gremlin-inference-neptune-ml-score-predicate) dans les requêtes de classification et de régression des nœuds Gremlin.
+ Ajout de la prise en charge de la clause `OPTIONAL MATCH` dans openCypher.
+ Ajout de la prise en charge de la clause `MERGE` dans openCypher.
+ Ajout de la prise en charge de l'utilisation de `ORDER BY` dans les clauses `WITH` dans openCypher.
+ Ajout de la prise en charge de la compréhension des modèles dans openCypher et ajout d'une prise en charge étendue de l'expression des modèles au-delà de la vérification de leur existence.
+ Prise en charge étendue des clauses `DELETE` et `DELETE DETACH` dans openCypher, de sorte qu'elles peuvent désormais être utilisées avec d'autres clauses de mise à jour.
+ Prise en charge étendue des clauses `CREATE` et `UPDATE` utilisées avec `RETURN` dans openCypher.
+ Ajout dans le moteur DFE de la prise en charge des étapes Gremlin `limit`, `range` et `skip`.
+ Amélioration de l'exécution des requêtes dans le moteur DFE lorsque ni `explain`, ni `profile` ne sont demandés.
+ Amélioration de l'exécution des requêtes dans le moteur DFE pour l'expression `value`.
+ Amélioration de divers modèles d'insertion conditionnelle Gremlin enchaînés afin d'éviter les exceptions de modification simultanée et de permettre le chaînage de modèles de requête tels que ceux-ci :
+ Insertion conditionnelle de sommets par ID, par exemple :
```
g.V(ID).fold().coalesce(unfold(), g.addV("L1").property(id,ID))
```
+ Insertion conditionnelle de sommets avec plusieurs étiquettes, par exemple :
```
g.V(ID).fold().coalesce(unfold(), g.addV("L1::L2").property(id,ID))
```
+ Insertion conditionnelle d'arêtes par ID, par exemple :
```
g.E(ID).fold().coalesce(unfold(), V(from).addE(label).to(V(to)).property(id, ID))
```
+ Insertion conditionnelle d'arêtes avec plusieurs étiquettes, par exemple :
```
g.E(ID).fold().coalesce(unfold(), g.addE(label).from(V(from)).to(V(to)).property(id, ID))
```
+ Insertion conditionnelle suivie d'une requête, par exemple :
```
g.V(ID).fold().coalesce(unfold(), g.addV("L1").property(id,ID)).project("myvalues").by(valueMap())
```
+ Insertion conditionnelle avec propriétés ajoutées, par exemple :
```
g.V(ID).fold().coalesce(unfold(), g.addV("L1").property(id,ID).property("name","pumba"))
```
## Défauts corrigés dans cette version du moteur
+ Désactivation de la [fonctionnalité de statistiques](neptune-dfe-statistics.md) sur les types d'instances `T3.medium`, qui n'étaient pas en mesure de la prendre en charge.
+ Correction d'un bogue SPARQL lié à `explain` où une fonction `IN` utilisait des valeurs non constantes.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.0.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.0.0
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
La mise à niveau vers cette version n'est pas automatique.
## Mise à niveau vers cette version
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.0.0 \
4. --allow-major-version-upgrade \
5. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.0.0 ^
4. --allow-major-version-upgrade ^
5. --apply-immediately
```
Au lieu d'`--apply-immediately`, vous pouvez spécifier `--no-apply-immediately`. Pour effectuer une mise à niveau de version majeure, le allow-major-version-upgrade paramètre est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.
Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--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 base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :
```
--db-instance-parameter-group-name (name of the custom instance parameter group)
```
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version de maintenance d'Amazon Neptune, version 1.1.0.0.R3 (23/12/2022)
Depuis le 23 décembre 2023, la version 1.1.0.0.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Afin de mener à bien la mise à niveau, chaque sous-réseau de chaque zone de disponibilité (AZ) doit disposer d'au moins une adresse IP disponible par instance Neptune. Par exemple, s'il existe une instance d'enregistreur et deux instances de lecteur dans le sous-réseau 1, et deux instances de lecteur dans le sous-réseau 2, le sous-réseau 1 doit avoir au moins trois adresses IP libres, tandis que le sous-réseau 2 doit avoir au moins deux adresses IP libres avant de commencer la mise à niveau.
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Améliorations de cette version du moteur
+ Amélioration des performances et corrections de divers opérateurs Gremlin, notamment `repeat`, `coalesce`, `store` et `aggregate`.
## Défauts corrigés dans cette version du moteur
+ Correction d'un problème de pic d'activité du CPU.
+ Correction d'un bogue openCypher où les requêtes renvoyaient la chaîne `"null"` au lieu d'une valeur nulle dans Bolt et SPARQL-JSON.
+ Correction d'un bogue du journal d'audit qui entraînait la journalisation d'informations inutiles et l'absence de certains champs dans les journaux.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.0.0.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.0.0.R3
Votre cluster sera automatiquement mis à niveau vers cette version de correctif de maintenance lors de la prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.1.0.0`.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera indisponible à ce stade pendant environ six minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Note**
À partir de cette version du moteur, Neptune [ne prend plus en charge les types d'instances `R4`](instance-types.md#instance-type-r4). Si vous utilisez une instance `R4` dans votre cluster de bases de données, vous devrez la remplacer manuellement par un autre type d'instance avant de passer à cette version. Si vous utilisez une instance d'enregistreur `R4`, suivez [ces instructions](best-practices-general-basic.md#best-practices-resize-instance) pour la déplacer.
## Mise à niveau vers cette version
Amazon Neptune 1.1.0.0.R3 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.0.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.0.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version de maintenance d'Amazon Neptune, version 1.1.0.0.R2 (16/05/2022)
Depuis le 16 mai 2022, la version 1.1.0.0.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera alors indisponible pendant quelques minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue en raison duquel le cache d'informations d'identification interne n'était pas correctement vidé pour les points de terminaison autres que ceux des requêtes, tels que le point de terminaison d'état.
+ Correction d'un bogue qui augmentait le retard de réplication après une mise à niveau du moteur.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.1.0.0.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version d'openCypher :* `Neptune-9.0.20190305-1.0`
+ *Version de SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.1.0.0.R2
Votre cluster sera automatiquement mis à niveau vers cette version de correctif de maintenance lors de la prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.1.0.0`.
**Important**
**La mise à niveau vers cette version du moteur à partir d'une version antérieure à `1.1.0.0` déclenche également une mise à niveau du système d'exploitation sur toutes les instances de votre cluster de bases de données. Étant donné que les demandes d'écriture actives qui se produisent pendant la mise à niveau du système d'exploitation ne sont pas traitées, vous devez suspendre toutes les charges de travail d'écriture dans le cluster en cours de mise à niveau, y compris les chargements de données en bloc, avant de démarrer la mise à niveau.**
Au début de la mise à niveau, Neptune génère un instantané dont le nom est composé de `preupgrade` suivi d'un identifiant généré automatiquement en fonction des informations de votre cluster de bases de données. Cet instantané ne vous est pas facturé. Vous pouvez l'utiliser pour restaurer votre cluster de bases de données en cas de problème pendant le processus de mise à niveau.
Lorsque la mise à niveau du moteur elle-même sera terminée, la nouvelle version du moteur sera brièvement disponible sur l'ancien système d'exploitation, mais en moins de cinq minutes, toutes les instances de votre cluster commenceront simultanément une mise à niveau du système d'exploitation. Votre cluster de bases de données sera indisponible à ce stade pendant environ six minutes. Vous pourrez reprendre les charges de travail d'écriture une fois la mise à niveau terminée.
Ce processus génère les événements suivants :
Messages d'événements par cluster :
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Messages d'événements par instance :
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Note**
À partir de cette version du moteur, Neptune [ne prend plus en charge les types d'instances `R4`](instance-types.md#instance-type-r4). Si vous utilisez une instance `R4` dans votre cluster de bases de données, vous devrez la remplacer manuellement par un autre type d'instance avant de passer à cette version. Si vous utilisez une instance d'enregistreur `R4`, suivez [ces instructions](best-practices-general-basic.md#best-practices-resize-instance) pour la déplacer.
## Mise à niveau vers cette version
Amazon Neptune 1.1.0.0.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.1.0.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.1.0.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.5.1 du moteur Amazon Neptune (01/10/2021)
Depuis le 1er octobre 2021, la version 1.0.5.1 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.5.1.R2 (26/10/2021)](engine-releases-1.0.5.1.R2.md)
+ [Sortie : 1.0.5.1.R3 (13/01/2022)](engine-releases-1.0.5.1.R3.md)
+ [Version de maintenance 1.0.5.1.R4 (16/05/2022)](engine-releases-1.0.5.1.R4.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout d'un [cache de résultats](gremlin-results-cache.md) pour mettre en cache les résultats des requêtes spécifiées.
+ Date/time Support ajouté dans Neptune OpenCypher.
+ Ajout de la prise en charge de l'accès `List` et `Map` aux éléments dans Neptune openCypher.
## Améliorations de cette version du moteur
+ Les noms des points de terminaison Neptune openCypher ne sont pas sensibles à la casse.
+ Amélioration de la fonctionnalité explain d'openCypher.
+ Amélioration des modèles de requêtes Gremlin à upsert unique se terminant par les étapes `iterate()` et `profile()`.
+ Amélioration des performances des fonctions Gremlin `keys()` et `property()`.
+ L'étape Gremlin `dedup()` est exécutée dans le DFE lorsqu'elle est utilisée avec une portée globale.
+ Les prédicats `HAS` Gremlin suivants sont exécutés dans le moteur DFE lorsque celui-ci est activé :
+ `EQ`
+ `NEQ`
+ `LT`
+ `LTE`
+ `GT`
+ `GTE`
+ `BETWEEN`
+ `INSIDE`
+ `OUTSIDE`
+ `WITHIN`
+ `AND (connectives)`
+ `OR (connectives)`
+ Amélioration des performances de requêtes LIMIT.
+ Amélioration des performances des requêtes d'agrégation générales openCypher.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin qui permettait à une arête d'être connectée à une autre arête.
+ Correction d'un bogue Gremlin qui entraînait le choix d'une stratégie de jointure sous-optimale.
+ Correction d'un bogue Gremlin qui bloquait la sérialisation des nœuds et des relations lorsque plus de 100 propriétés étaient présentes.
+ Correction d'un bogue qui ralentissait la planification de l'exécution des requêtes comportant de grands modèles de graphes.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.5.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.5.1
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
La mise à niveau vers cette version n'est pas automatique.
## Mise à niveau vers cette version
Amazon Neptune 1.0.5.1 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.5.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.5.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version de maintenance d'Amazon Neptune, version 1.0.5.1.R4 (16/05/2022)
Depuis le 16 mai 2022, la version 1.0.5.0.R4 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.5.1.R4, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.5.1.R4
Votre cluster sera automatiquement mis à niveau vers cette version de correctif de maintenance lors de la prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.5.1`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.5.1.R4 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.5.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.5.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.5.1.R3 du moteur Amazon Neptune (13/01/2022)
Depuis le 13 janvier 2022, la version 1.0.5.1.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue qui pouvait provoquer une fuite de ressources lorsqu'une requête ne parvenait pas à obtenir toutes les ressources dont elle avait besoin.
+ Correction d'une petite fuite de mémoire lors de l'exécution d'une requête causée par une allocation de mémoire non revendiquée.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.5.1.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.5.1.R3
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.5.1`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.5.1.R3 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.5.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.5.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.5.1.R2 du moteur Amazon Neptune (26/10/2021)
Depuis le 26 octobre 2021, la version 1.0.5.1.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue qui provoquait le redémarrage du serveur lorsqu'une erreur transitoire se produisait pendant de la création d'une ancienne version d'un élément de graphe, dans le cadre d'un isolement de lecture reproductible. Neptune renvoie désormais une erreur à la place, afin que le client puisse effectuer une nouvelle tentative.
+ Correction d'un bogue qui provoquait le redémarrage du serveur lorsqu'une erreur transitoire se produisait lors de la mise à jour d'une seule cardinalité. Neptune renvoie désormais une erreur à la place, afin que le client puisse effectuer une nouvelle tentative.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.5.1.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.5.1.R2
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.5.1`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.5.1.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.5.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.5.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.5.0 du moteur Amazon Neptune (27/07/2021)
Depuis le 27 juillet 2021, la version 1.0.5.0 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.5.0.R2 (16/08/2021)](engine-releases-1.0.5.0.R2.md)
+ [Sortie : 1.0.5.0.R3 (15/09/2021)](engine-releases-1.0.5.0.R3.md)
+ [Version de maintenance 1.0.5.0.R5 (16/05/2022)](engine-releases-1.0.5.0.R5.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ [Neptune ML](machine-learning.md) a été publié pour une utilisation en production avec de nombreuses nouvelles fonctionnalités et n'est plus en mode laboratoire.
+ Ajout de la prise en charge initiale du langage de requête [openCypher](access-graph-opencypher.md), en mode expérimental. **openCypher** est le standard open source pour le langage de requête Cypher. Sa syntaxe est spécifiée dans le [Cypher Query Language Reference (version 9)](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf) et est gérée par le projet [openCypher](http://www.opencypher.org/).
Consultez [Accès au graphe Neptune avec openCypher](access-graph-opencypher.md) pour plus d'informations sur l'implémentation Neptune de ce langage.
Le [protocole Bolt](https://neo4j.com/docs/bolt/current/bolt/), que les clients Neptune utilisent pour les requêtes openCypher, est également pris en charge. Consultez [Utilisation du protocole Bolt pour envoyer des requêtes openCypher à Neptune](access-graph-opencypher-bolt.md).
La prise en charge d'openCypher est désormais activée automatiquement, mais dépend du [Moteur DFE Neptune](neptune-dfe-engine.md), qui n'est actuellement disponible qu'en [mode laboratoire](features-lab-mode.md). Le paramètre `DFEQueryEngine` par défaut du cluster de bases de données `neptune_lab_mode` est désormais `DFEQueryEngine=viaQueryHint` : le moteur est donc activé, mais uniquement utilisé pour les requêtes dont l'indicateur de requête `useDFE` est défini sur `true`. Si vous désactivez le moteur DFE en définissant `DFEQueryEngine=disabled`, vous ne pouvez pas utiliser openCypher.
+ Ajout de la prise en charge du [protocole HTTP SPARQL 1.1 Graph Store](https://www.w3.org/TR/sparql11-http-rdf-update/). Consultez [Utilisation du protocole HTTP SPARQL 1.1 Graph Store (GSP) dans Amazon Neptune](sparql-graph-store-protocol.md).
+ Remplacement du paramètre de mode expérimental par défaut du [Moteur DFE Neptune](neptune-dfe-engine.md) par `viaQueryHint` : le moteur DFE est désormais activé par défaut, mais uniquement utilisé pour les requêtes dont l'indicateur de requête `useDFE` est défini sur `true`.
+ Ajout d'une nouvelle CloudWatch métrique Amazon,`StatsNumStatementsScanned`, pour surveiller le calcul des statistiques pour le moteur Neptune DFE. Consultez [Utilisation de la `StatsNumStatementsScanned` CloudWatch métrique pour surveiller le calcul des statistiques](neptune-dfe-statistics.md#neptune-dfe-statistics-monitoring).
## Améliorations de cette version du moteur
+ Ajout du support pour Apache TinkerPop 3.4.11.
**Important**
Une modification a été apportée à TinkerPop la version 3.4.11 qui améliore l'exactitude du traitement des requêtes, mais qui, pour le moment, peut parfois avoir un impact sérieux sur les performances des requêtes.
Par exemple, une requête de ce type peut être beaucoup plus lente :
```
g.V().hasLabel('airport').
order().
by(out().count(),desc).
limit(10).
out()
```
Les sommets après le pas de limite sont désormais récupérés de manière non optimale en raison de la modification 3.4.11. TinkerPop Pour éviter cela, vous pouvez modifier la requête en ajoutant l'étape barrier() à tout moment après `order().by()`. Par exemple :
```
g.V().hasLabel('airport').
order().
by(out().count(),desc).
limit(10).
barrier().
out()
```
+ L'[indicateur de requête `joinOrder` SPARQL](sparql-query-hints-joinOrder.md) est désormais pris en charge par l'autre moteur de requête Neptune DFE.
+ La sortie de l'[API d'état Neptune](access-graph-status.md) a été étendue et réorganisée afin de clarifier les paramètres et les fonctionnalités du cluster de bases de données.
La nouvelle sortie contient un objet `features` de niveau supérieur comportant des informations d'état sur les fonctionnalités du cluster de bases de données et un objet `settings` de niveau supérieur comportant des informations sur les paramètres. Pour examiner le nouveau format, consultez [Exemple de sortie de la commande instance status](access-graph-status.md#access-graph-status-sample-output).
+ La gestion des journaux de modifications des flux a été améliorée lorsque des flux `AFTER_SEQUENCE_NUMBER` sont demandés avec le dernier ID d'événement sur le serveur, quand cet ID a déjà expiré. Le serveur ne renvoie plus d'erreur d'identifiant d'événement ayant expiré si l'identifiant d'événement demandé est le dernier identifiant d'événement purgé sur le serveur.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin lié à l'ordre des valeurs numériques.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.5.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.5.0
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
La mise à niveau vers cette version n'est pas automatique.
## Mise à niveau vers cette version
Amazon Neptune 1.0.5.0 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.5.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.5.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version de maintenance d'Amazon Neptune, version 1.0.5.0.R5 (16/05/2022)
Depuis le 16 mai 2022, la version 1.0.5.0.R5 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.5.0.R5, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.5.0.R5
Votre cluster sera automatiquement mis à niveau vers cette version de correctif maintenance lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur 1.0.5.0.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.5.0.R5 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.5.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.5.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.5.0.R3 du moteur Amazon Neptune (15/09/2021)
Depuis le 15 septembre 2021, la version 1.0.5.0.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue qui empêchait le moteur de répondre dans l'une des situations suivantes :
+ Un chargement en bloc se produit en même temps que le calcul automatique des statistiques.
+ Un calcul de statistiques a été demandé manuellement alors qu'un tel calcul était déjà en cours.
+ Correction d'un bogue lié à la détection des blocages et à l'acquisition des blocages qui pouvait provoquer un incident au niveau du moteur.
+ Correction d'un bogue Gremlin où le moteur renvoyait une erreur lorsqu'il trouvait des données inconnues provenant d'un point de terminaison ML distant dans une requête d'inférence Gremlin.
+ Correction de plusieurs bogues dans la gestion des modèles ML APIs liés aux tâches de transformation des modèles et aux recommandations d'instances.
+ Correction d'un bug qui pouvait provoquer le crash du moteur lors de la génération du nœud et du bord IDs.
+ Correction d'un bogue qui ralentissait la génération de plans de requêtes pour les requêtes comportant de grands modèles de graphes.
+ Correction d'un bogue openCypher qui pouvait provoquer le blocage d'une requête lors de la récupération d'un nœud comportant plus de 100 propriétés.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.5.0.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.5.0.R3
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur 1.0.5.0.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.5.0.R3 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.5.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.5.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.5.0.R2 du moteur Amazon Neptune (16/08/2021)
Depuis le 16 août 2021, la version 1.0.5.0.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Désactivation d'une optimisation effectuée dans la [version de moteur `1.0.5.0`](engine-releases-1.0.5.0.md) qui permettait au [cache de recherche Neptune](feature-overview-lookup-cache.md) de survivre aux redémarrages du moteur sur les réplicas. Les redémarrages de réplicas vident à présent le cache de recherche.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.5.0.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.11`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.5.0.R2
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.5.0`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.5.0.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.5.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.5.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.4.2 du moteur Amazon Neptune (01/06/2021)
**Note**
La version 1.0.4.2.R2 du moteur a été la première version de 1.0.4.2 à être publiée.
**Topics**
+ [Version 1.0.4.2.R5 du moteur Amazon Neptune (16/08/2021)](engine-releases-1.0.4.2.R5.md)
+ [Version 1.0.4.2.R4 du moteur Amazon Neptune (23/07/2021)](engine-releases-1.0.4.2.R4.md)
+ [Version 1.0.4.2.R3 du moteur Amazon Neptune (28/06/2021)](engine-releases-1.0.4.2.R3.md)
+ [Version 1.0.4.2.R2 du moteur Amazon Neptune (01/06/2021)](engine-releases-1.0.4.2.R2.md)
+ [Version 1.0.4.2.R1 du moteur Amazon Neptune (27/05/2021)](engine-releases-1.0.4.2.R1.md)
# Version 1.0.4.2.R5 du moteur Amazon Neptune (16/08/2021)
Depuis le 16 août 2021, la version 1.0.4.2.R5 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Désactivation d'une optimisation effectuée dans la [version de moteur `1.0.4.2.R4`](engine-releases-1.0.4.2.R4.md) qui permettait au [cache de recherche Neptune](feature-overview-lookup-cache.md) de survivre aux redémarrages du moteur sur les réplicas. Les redémarrages de réplicas vident à présent le cache de recherche.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.2.R5, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.10`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.2.R5
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.4.2`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
# Version 1.0.4.2.R4 du moteur Amazon Neptune (23/07/2021)
Depuis le 23 juillet 2021, la version 1.0.4.2.R4 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Améliorations de cette version du moteur
+ Amélioration du comportement du cache de recherche afin d'éviter l'effacement redondant du cache après une réinitialisation rapide sur un réplica.
+ Gestion améliorée des journaux de modifications des flux lorsque les flux `AFTER_SEQUENCE_NUMBER` sont demandés avec le dernier ID d'événement sur le serveur, quand cet ID a déjà expiré. Le serveur ne renvoie plus d'erreur d'identifiant d'événement ayant expiré si l'identifiant d'événement demandé est le dernier identifiant d'événement purgé sur le serveur.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue introduit dans la version 1.0.4.0.R1 où les requêtes ne renvoyaient pas l'intégralité des valeurs de chaîne supérieures à 760 caractères. Les termes concernés par ce bogue étaient les littéraux RDF et/ou URIs, ou Gremlin IDs, les clés et les valeurs de chaîne.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.2.R4, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.10`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.2.R4
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.4.2`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
# Version 1.0.4.2.R3 du moteur Amazon Neptune (28/06/2021)
Depuis le 28 juin 2021, la version 1.0.4.2.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Problèmes connus dans cette version du moteur
**Problème :**
Bogue SPARQL qui ne respecte pas le type de média dans un en-tête `Accept`en cas d'espaces.
Par exemple, une requête ` -H "Accept: text/csv; q=1.0, */*; q=0.1" ` renvoie une sortie JSON plutôt qu'une sortie CSV.
**Solution :**
Si vous supprimez les espaces dans la clause `Accept` de l'en-tête, le moteur renvoie le résultat dans le format demandé correct. En d'autres termes, au lieu de ` -H "Accept: text/csv; q=1.0, */*; q=0.1" `, utilisez :
```
-H "Accept: text/csv;q=1.0,*/*;q=0.1"
```
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue lors de l'effacement du cache de recherche sur les réplicas après une réinitialisation rapide.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.2.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.10`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.2.R3
Cette version de correctif est facultative, sauf si votre cluster de bases de données utilise une ou plusieurs instances `R5d`. Si votre cluster possède des instances `R5d`, il sera automatiquement mis à niveau lors de la prochaine fenêtre de maintenance. Dans le cas contraire, sa mise à niveau vers cette version de correctif ne sera pas automatique.
Vous pouvez mettre à jour `1.0.4.2.R2` la version vers cette `1.0.4.2.R3` version manuellement à l'aide de la AWS CLI [apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/neptune/apply-pending-maintenance-action.html)commande (l'[ApplyPendingMaintenanceAction](api-other-apis.md#ApplyPendingMaintenanceAction)API).
# Version 1.0.4.2.R2 du moteur Amazon Neptune (01/06/2021)
Depuis le 1er juin 2021, la version 1.0.4.2.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.4.2.R3 (28/06/2021)](engine-releases-1.0.4.2.R3.md)
## Problèmes connus dans cette version du moteur
**Problème :**
Bogue SPARQL qui ne respecte pas le type de média dans un en-tête `Accept`en cas d'espaces.
Par exemple, une requête ` -H "Accept: text/csv; q=1.0, */*; q=0.1" ` renvoie une sortie JSON plutôt qu'une sortie CSV.
**Solution :**
Si vous supprimez les espaces dans la clause `Accept` de l'en-tête, le moteur renvoie le résultat dans le format demandé correct. En d'autres termes, au lieu de ` -H "Accept: text/csv; q=1.0, */*; q=0.1" `, utilisez :
```
-H "Accept: text/csv;q=1.0,*/*;q=0.1"
```
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout du nouveau type d'instance R5d, qui inclut un cache de recherche pour accélérer les lectures dans les cas d'utilisation impliquant un volume élevé de recherche de valeurs de propriété ou de littéraux RDF. Consultez [Le cache de recherche Neptune peut accélérer les requêtes de lecture](feature-overview-lookup-cache.md).
+ Ajout d'un nouveau paramètre en mode laboratoire qui permet au moteur DFE expérimental d'être invoqué uniquement par requête avec l'indicateur de requête `useDFE`.
## Améliorations de cette version du moteur
+ Ajout du support pour la version TinkerPop 3.4.10.
+ Ajout de la prise en charge de l'utilisation de l'étape de configuration `withStrategies( )` lors de l'envoi de requêtes de script Gremlin. Plus précisément, les étapes `SubgraphStrategy`, `PartitionStrategy`, `ReadOnlyStrategy`, `EdgeLabelVerificationStrategy` et `ReservedKeysVerificationStrategy` sont toutes prises en charge.
+ Ajout de l'optimisation des traversées `V()` au milieu d'une requête. Auparavant, ces traversées n'étaient pas optimisées dans Neptune.
+ Ajout de la prise en charge de la [RFC 2141 URNs](https://tools.ietf.org/html/rfc2141) à utiliser comme `namedGraphUri` paramètres `baseUri` et pour un chargement en vrac.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin dans l'analyseur dans lequel les requêtes incorrectes étaient considérées comme valides.
+ Correction d'un bogue Gremlin où le déploiement d'un effet secondaire `aggregate()` avec `cap().unfold()` pour le remplacer par `valueMap()` provoquait une exception.
+ Correction d'un bogue Gremlin qui provoquait l'échec de certaines étapes `property()` après une étape `addV()` avec l'erreur « cannot cast to String » (Conversion en chaîne impossible).
+ Correction d'un bogue Gremlin qui empêchait certains modèles d'insertion conditionnelle de déclencher des exceptions de modification simultanée.
+ Correction d'un bogue Gremlin de sorte que le délai d'expiration de la demande de requête ne puisse plus dépasser le délai d'expiration de la session.
+ Correction d'un bogue SPARQL en raison duquel les mises à jour utilisant LOAD ou UNLOAD pouvaient échouer avec un code HTTP 500 au lieu du code HTTP 400 lorsque le serveur distant n'était pas disponible.
+ Correction d'un bogue où les appels d'API de flux échouaient lorsque des valeurs `commitNum` ou `opNum` supérieures à la limite d'entiers signés de 32 bits (2 147 483 647) étaient utilisées.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.2.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.10`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.2.R2
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
La mise à niveau vers cette version n'est pas automatique.
## Mise à niveau vers cette version
Amazon Neptune 1.0.4.2.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.4.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.4.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.4.2.R1 du moteur Amazon Neptune (27/05/2021)
La version 1.0.4.1.R1 du moteur n'a jamais été déployée.
# Version 1.0.4.1 du moteur Amazon Neptune (08/12/2020)
Depuis le 8 décembre 2020, la version 1.0.4.1 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.4.1.R1.1 (22/03/2021)](engine-releases-1.0.4.1.R1.1.md)
+ [Sortie : 1.0.4.1.R2 (24/02/2021)](engine-releases-1.0.4.1.R2.md)
**Important**
[Sortie : 1.0.4.0 (12/10/2020)](engine-releases-1.0.4.0.md) a rendu les protocoles TLS 1.2 et HTTPS obligatoires pour toutes les connexions à Amazon Neptune. Cependant, un bogue présent dans cette version a permis aux connexions HTTP (connexions TLS and/or obsolètes) de continuer à fonctionner pour les clients qui avaient précédemment défini un paramètre de cluster de base de données afin d'empêcher l'application des connexions HTTPS.
Ce bogue a été corrigé dans les versions de correctifs [1.0.4.0.R2](engine-releases-1.0.4.0.R2.md) et [1.0.4.1.R2](engine-releases-1.0.4.1.R2.md), mais le correctif provoquait des échecs de connexion inattendus lors de l'installation automatique des correctifs. Pour cette raison, les deux correctifs ont été annulés et ne peuvent être installés que manuellement, afin de vous permettre de mettre à jour votre configuration pour TLS 1.2.
Le fait de devoir l'utiliser SSL/TLS pour toutes les connexions à Neptune affecte vos connexions avec la console Gremlin, le pilote Gremlin, Python, .NET, NodeJS, REST, ainsi que les connexions à l'équilibreur de charge. APIs Si vous avez utilisé le protocole HTTP ou une ancienne version de TLS jusqu'à présent, vous devrez mettre à jour le client et les pilotes concernés, et modifier le code pour qu'il utilise exclusivement le protocole HTTPS avant d'installer les derniers correctifs sur le système.
## Nouvelles fonctionnalités pour cette version du moteur
+ Présentation de la fonctionnalité Neptune ML, qui apporte de puissantes fonctionnalités de machine learning à Amazon Neptune. Consultez [Amazon Neptune ML pour le machine learning sur les graphes](machine-learning.md).
+ Ajout d'une opération `UNLOAD` SPARQL personnalisée pour supprimer les données extraites d'une source distante. Consultez [SPARQL UPDATE UNLOAD](sparql-api-reference-unload.md).
## Améliorations de cette version du moteur
+ Optimisation de certains modèles d'insertion conditionnelle Gremlin pour éviter les exceptions de modification simultanée.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin qui pouvait entraîner des résultats manquants pour un modèle spécifique de requêtes qui utilisaient l'étape `as()`.
+ Correction d'un bogue Gremlin qui pouvait provoquer des erreurs lors de l'utilisation de l'étape `project()` imbriquée dans une autre étape, comme `union()`.
+ Correction d'un bogue Gremlin dans l'étape `project()`.
+ Correction d'un bogue Gremlin lié à la traversée basée sur des chaînes, à cause duquel l'étape `none()` ne fonctionnait pas.
+ Correction d'un bogue Gremlin lié à la traversée basée sur des chaînes, à cause duquel un mappage vide n'était pas pris en charge comme argument de l'étape `inject()`.
+ Correction d'un bogue Gremlin lié à l'exécution de traversées basées sur des chaînes dans le moteur DFE et à cause duquel une méthode de terminal telle que `toList()` ne fonctionnait pas correctement.
+ Correction d'un bogue Gremlin qui empêchait de clôturer des transactions lors de l'utilisation de l'étape `iterate()` dans les requêtes sous forme de chaîne.
+ Correction d'un bogue Gremlin qui pouvait provoquer une exception pour les requêtes utilisant le modèle `is(P.gte(0))` dans certaines situations.
+ Correction d'un bogue Gremlin qui pouvait provoquer une exception pour les requêtes utilisant le modèle `order().by(T.id)` dans certaines situations.
+ Correction d'un bogue Gremlin en raison duquel les requêtes utilisant le modèle `addV().aggregate()` généraient des résultats incorrects dans certaines situations.
+ Correction d'un bogue Gremlin qui pouvait provoquer une exception dans certaines situations pour les requêtes utilisant l'étape `path()` suivie du modèle d'étape `project()`.
+ Correction d'un bogue SPARQL où la fonction `SUBSTR` signalait une erreur au lieu de renvoyer une chaîne vide.
+ Correction d'un bogue dans le moteur DFE en raison duquel les opérations de jointure dans les plans de requêtes non bloquants pouvaient générer des résultats incorrects en présence de variables indépendantes.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.8`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.1
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.4.1`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.4.1 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.4.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.4.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.4.1.R1.1 du moteur Amazon Neptune (22/03/2021)
Depuis le 22 mars 2021, la version 1.0.4.1.R1.1 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Désactivation d'une optimisation pour les modèles d'insertion conditionnelle Gremlin qui peuvent être ajoutés à des étiquettes et à des propriétés existantes.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.1.R1.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.8`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.1.R1.1
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.4.1`.
## Mise à niveau vers cette version
Amazon Neptune 1.0.4.1.R1.1 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.4.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.4.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.4.1.R2 du moteur Amazon Neptune (24/02/2021)
Depuis le 24 février 2021, la version 1.0.4.1.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.4.1.R2.1 (11/03/2021)](engine-releases-1.0.4.1.R2.1.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Neptune prend en charge la compression des fichiers individuels au format `bzip2` pour les chargements en bloc. Consultez [Formats de chargement de données](bulk-load-tutorial-format.md).
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue dans [Sortie : 1.0.4.0 (12/10/2020)](engine-releases-1.0.4.0.md) qui autorisait les connexions à Neptune à l'aide de TLS `HTTP` ou version antérieure, plutôt que `HTTPS` et TLS 1.2.
**Important**
**Le fait de devoir l'utiliser SSL/TLS pour toutes les connexions à Neptune peut être un changement radical.** Cela affecte vos connexions avec la console Gremlin, le pilote Gremlin, Python Gremlin, .NET, NodeJS, APIs REST, ainsi que les connexions à l'équilibreur de charge. Si vous avez utilisé le protocole HTTP ou une ancienne version de TLS jusqu'à présent, vous devrez mettre à jour le client et les pilotes concernés avant d'installer ce correctif, et modifier le code pour utiliser exclusivement le protocole HTTPS.
+ Correction d'un bogue Gremlin où l'exception `InternalFailureException` était définie comme code de réponse dans certaines circonstances lors d'un événement `ConcurrentModificationException`.
+ Correction d'un bogue Gremlin où, dans certaines conditions, la mise à jour des arêtes ou des sommets pouvait provoquer une exception `InternalFailureException` transitoire.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.1.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.8`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.1.R2
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.4.1`.
## Mise à niveau vers cette version
Amazon Neptune 1.0.4.1.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.4.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.4.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.4.1.R2.1 du moteur Amazon Neptune (11/03/2021)
Depuis le 11 mars 2021, la version 1.0.4.1.R2.1 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Désactivation d'une optimisation pour les modèles d'insertion conditionnelle Gremlin qui peuvent être ajoutés à des étiquettes et à des propriétés existantes.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.1.R2.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.8`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.1.R2.1
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.4.1.R2`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.4.1.R2.1 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.4.1.R2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.4.1.R2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.4.0 du moteur Amazon Neptune (12/10/2020)
Depuis le 12 octobre 2020, la version 1.0.4.0 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.4.0.R2 (24/02/2021)](engine-releases-1.0.4.0.R2.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout de la compression au niveau des frames pour Gremlin.
## Améliorations de cette version du moteur
+ Amazon Neptune exige désormais l'utilisation du protocole SSL (Secure Sockets Layer) avec le protocole TLSv1 .2 pour toutes les connexions à Neptune dans toutes les régions, en utilisant ces suites de chiffrement puissantes :
+ `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
+ `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
+ `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384`
+ `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`
+ `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA`
+ `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA`
Cela est vrai à la fois pour REST et pour WebSocket les connexions à Neptune, et cela signifie que vous devez utiliser le protocole HTTPS plutôt que le protocole HTTP lorsque vous vous connectez à Neptune dans toutes les régions.
Étant donné que les connexions client utilisant HTTP ou TLS 1.1 ne seront plus prises en charge nulle part, assurez-vous que vos clients et votre code ont été mis à jour pour pouvoir utiliser TLS 1.2 et HTTPS avant de passer à cette version du moteur.
**Important**
**Le fait de devoir l'utiliser SSL/TLS pour toutes les connexions à Neptune peut être un changement radical.** Cela affecte vos connexions avec la console Gremlin, le pilote Gremlin, Gremlin Python, .NET, NodeJS, APIs REST, ainsi que les connexions à l'équilibreur de charge. Si vous avez utilisé le protocole HTTP pour une partie ou la totalité de ces connexions, vous devez à présent mettre à jour le client et les pilotes concernés et modifier le code pour qu'il utilise le protocole HTTPS. Dans le cas contraire, les connexions échoueront.
Un bogue dans cette version a permis aux connexions HTTP (connexions TLS and/or obsolètes) de continuer à fonctionner pour les clients qui avaient précédemment défini un paramètre de cluster de base de données afin d'empêcher l'application des connexions HTTPS. Ce bogue a été corrigé dans les versions de correctifs [1.0.4.0.R2](engine-releases-1.0.4.0.R2.md) et [1.0.4.1.R2](engine-releases-1.0.4.1.R2.md), mais le correctif provoquait des échecs de connexion inattendus lors de l'installation automatique des correctifs.
Pour cette raison, les deux correctifs ont été annulés et ne peuvent être installés que manuellement, afin de vous permettre de mettre à jour votre configuration pour TLS 1.2.
+ Mise à niveau TinkerPop vers la version 3.4.8. Il s'agit d'une mise à niveau rétrocompatible. Consultez le [journal des TinkerPop modifications](https://github.com/apache/tinkerpop/blob/master/CHANGELOG.asciidoc#tinkerpop-348-release-date-august-3-2020) pour connaître les nouveautés.
+ Amélioration des performances pour l'étape Gremlin `properties()`.
+ Ajout de détails sur `BindOp` et `MultiplexerOp` dans les rapports d'explication et de profil.
+ Ajout d'une fonction de prélecture des données pour améliorer les performances en cas de défaillance du cache.
+ Ajout d'un nouveau paramètre `allowEmptyStrings` dans le paramètre `parserConfiguration` du chargeur en bloc. Il permet de traiter les chaînes vides comme des valeurs de propriété valides dans les chargements CSV (voir [Paramètres de demande du chargeur Neptune](load-api-reference-load.md#load-api-reference-load-parameters)).
+ Le chargeur autorise désormais un point-virgule avec caractère d'échappement dans les colonnes CSV à valeurs multiples.
## Défauts corrigés dans cette version du moteur
+ Correction d'une fuite de mémoire Grenlin potentielle liée à l'étape `both()`.
+ Correction d'un bogue en raison duquel les métriques des demandes manquaient parce qu'un point de terminaison se terminant par / n'était pas géré correctement.
+ Correction d'un bogue en raison duquel les réplicas prenaient du retard et redémarraient sous forte charge lorsque le moteur DFE était activé en mode laboratoire.
+ Correction d'un bogue qui empêchait le message d'erreur correct d'être signalé lorsqu'un chargement groupé échouait en raison d'une out-of-memory condition.
+ Correction d'un bogue SPARQL en raison duquel l'encodage des caractères était placé dans l'en-tête Content-Encoding dans les réponses aux requêtes SPARQL. Au lieu de cela, `charset` est désormais placé dans l'en-tête Content-Type, ce qui permet aux clients HTTP de reconnaître le jeu de caractères utilisé automatiquement.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.8`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.0
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
La mise à niveau vers cette version n'est pas automatique.
## Mise à niveau vers cette version
Amazon Neptune 1.0.4.0 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.4.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.4.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.4.0.R2 du moteur Amazon Neptune (24/02/2021)
Depuis le 24 février 2021, la version 1.0.4.0.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue dans [Sortie : 1.0.4.0 (12/10/2020)](engine-releases-1.0.4.0.md) qui autorisait les connexions à Neptune à l'aide de TLS `HTTP` ou version antérieure, plutôt que `HTTPS` et TLS 1.2.
**Important**
**Le fait de devoir l'utiliser SSL/TLS pour toutes les connexions à Neptune peut être un changement radical.** Cela affecte vos connexions avec la console Gremlin, le pilote Gremlin, Python Gremlin, .NET, NodeJS, APIs REST, ainsi que les connexions à l'équilibreur de charge. Si vous avez utilisé le protocole HTTP ou une ancienne version de TLS jusqu'à présent, vous devrez mettre à jour le client et les pilotes concernés avant d'installer ce correctif, et modifier le code pour utiliser exclusivement le protocole HTTPS.
+ Correction d'un bogue dans le chargement en bloc des fichiers CSV impliquant des libellés se terminant par `#`.
+ Correction d'un bogue Gremlin où l'exception `InternalFailureException` était définie comme code de réponse dans certaines circonstances lors d'un événement `ConcurrentModificationException`.
+ Correction d'un bogue Gremlin où, dans certaines conditions, la mise à jour des arêtes ou des sommets pouvait provoquer une exception `InternalFailureException` transitoire.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.4.0.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.8`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.4.0.R2
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.4.0`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.4.0.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.4.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.4.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.3.0 du moteur Amazon Neptune (03/08/2020)
Depuis le 3 août 2020, la version 1.0.3.0 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.3.0.R2 (12/10/2020)](engine-releases-1.0.3.0.R2.md)
+ [Sortie : 1.0.3.0.R3 (19/02/2021)](engine-releases-1.0.3.0.R3.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Neptune a introduit un nouveau moteur de requête alternatif (DFE) qui contribue à accélérer considérablement l'exécution des requêtes. Consultez [Autre moteur de requête (DFE) Amazon Neptune](neptune-dfe-engine.md).
+ Ce DFE s'appuie sur des statistiques prégénérées concernant les données du graphe Neptune, qui sont gérées via de nouveaux points de terminaison de statistiques. Consultez [Statistiques DFE](neptune-dfe-statistics.md).
+ Vous pouvez désormais exclure les tâches de chargement en file d'attente de la liste des charges IDs renvoyées par l' Get-Status API Loader en définissant le nouveau `includeQueuedLoads` paramètre sur FALSE. Consultez [Paramètres de demande du Neptune Loader Get-Status](load-api-reference-status-requests.md#load-api-reference-status-parameters).
+ Neptune prend désormais en charge les en-têtes de fin pour les réponses aux requêtes SPARQL, qui peuvent contenir un code d'erreur et un message si une demande échoue après avoir commencé à renvoyer des fragments de réponse. Consultez [En-têtes de suivi HTTP facultatifs pour les réponses SPARQL en plusieurs parties](access-graph-sparql-http-trailing-headers.md).
+ Neptune vous permet désormais également d'activer l'encodage des réponses fragmentées pour les requêtes Gremlin. Comme dans le cas de SPARQL, les segments de réponse ont des en-têtes de fin qui peuvent contenir un code d'erreur et un message en cas d'échec après que la requête a commencé à renvoyer des fragments de réponse. Consultez [Utilisation d'en-têtes de suivi HTTP facultatifs pour activer les réponses Gremlin en plusieurs parties](access-graph-gremlin-rest-trailing-headers.md).
## Améliorations de cette version du moteur
+ Vous pouvez désormais indiquer la taille des demandes groupées ElasticSearch pour les recherches en texte intégral dans Gremlin.
+ Amélioration de l'utilisation de la mémoire pour les requêtes SPARQL GROUP BY.
+ Ajout d'un nouvel optimiseur de requêtes Gremlin pour affiner certains filtres indépendants.
+ Augmentation de la durée maximale pendant WebSocket laquelle une connexion authentifiée via IAM peut rester ouverte, de 36 heures à 10 jours.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue selon lequel, si vous envoyiez un paramètre d'URL non encodé dans une requête POST, Neptune renvoyait le code de statut HTTP 500 et une exception `InternalServerErrorException`. Neptune renvoie maintenant le code de statut HTTP 400 et une exception `BadRequestException`, avec le message : `Failure to process the POST request parameters`.
+ Correction d'un bogue de Gremlin qui empêchait le signalement correct d'un échec de WebSocket connexion.
+ Correction d'un bogue Gremlin lié à la disparition des effets secondaires.
+ Correction d'un bogue Gremlin qui empêchait la prise en charge correcte du paramètre de recherche en texte intégral `batchsize`.
+ Correction d'un bogue Gremlin pour gérer `toV` et `fromV` individuellement pour chaque direction. `bothE`
+ Correction d'un bogue Gremlin impliquant `Edge pathType` dans l'étape `hasLabel`.
+ Correction d'un bogue SPARQL en raison duquel la réorganisation des jointures avec des liaisons statiques ne fonctionnait pas correctement.
+ Correction d'un bogue SPARQL UPDATE LOAD en raison duquel un compartiment Amazon S3 indisponible n'était pas correctement signalé.
+ Correction d'un bogue SPARQL en raison duquel un problème avec un nœud SERVICE dans une sous-requête n'était pas correctement signalé.
+ Correction d'un bogue SPARQL en raison duquel les requêtes contenant des conditions FILTER EXISTS ou FILTER NOT EXISTS imbriquées n'étaient pas correctement évaluées.
+ Correction d'un bogue SPARQL pour gérer correctement les liaisons générées en double lors de l'appel des points de terminaison du service SPARQL via des requêtes de génération.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.3.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.3`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.3.0
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
Si le paramètre `AutoMinorVersionUpgrade` de votre cluster est défini sur `True`, votre cluster sera automatiquement mis à niveau vers cette version de moteur deux à trois semaines après la date de cette version, au cours d'une fenêtre de maintenance.
## Mise à niveau vers cette version
Amazon Neptune 1.0.3.0 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.3.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.3.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.3.0.R3 du moteur Amazon Neptune (19/02/2021)
Depuis le 19 février 2021, la version 1.0.3.0.R3 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue dans le chargement en bloc des fichiers CSV impliquant des libellés se terminant par `#`.
+ Correction d'un bogue Gremlin qui pouvait entraîner des résultats manquants pour un modèle spécifique de requêtes utilisant l'étape `as()`.
+ Correction d'un bogue Gremlin qui pouvait provoquer des erreurs lors de l'utilisation de l'étape `project()` imbriquée dans une autre étape, comme `union()`.
+ Correction d'un bogue Gremlin lié à l'exécution de traversées de chaînes dans le moteur DFE expérimental en cas d'utilisation d'une méthode de terminal comme `toList()`.
+ Correction d'un bogue Gremlin qui empêchait de clôturer une transaction lors de l'utilisation de l'étape `iterate()` dans une requête sous forme de chaîne.
+ Correction d'un bogue Gremlin qui pouvait provoquer une exception pour les requêtes utilisant le modèle `is(P.gte(0))` dans certaines situations.
+ Correction d'un bogue Gremlin où l'exception `InternalFailureException` était définie comme code de réponse dans certaines circonstances lors d'un événement `ConcurrentModificationException`.
+ Correction d'un bogue Gremlin où, dans certaines conditions, la mise à jour des arêtes ou des sommets pouvait provoquer une exception `InternalFailureException` transitoire.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.3.0.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.8`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.3.0.R3
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.3.0`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.3.0.R3 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.3.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.3.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.3.0.R2 du moteur Amazon Neptune (12/10/2020)
Depuis le 12 octobre 2020, la version 1.0.3.0.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Améliorations de cette version du moteur
+ Amélioration des performances pour l'étape Gremlin `properties()`.
+ Ajout de détails sur `BindOp` et `MultiplexerOp` dans les rapports d'explication et de profil.
+ Pour les réponses aux requêtes SPARQL, `charset` a été ajouté à l'en-tête Content-Type, permettant aux clients HTTP de reconnaître le jeu de caractères utilisé automatiquement.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue SPARQL qui empêchait la gestion de l'exception `CancellationException`
+ Correction d'un bogue SPARQL qui empêchait les requêtes contenant des options imbriquées de fonctionner correctement.
+ Correction d'un bogue SPARQL dans LOAD où `ConcurrentModificationException` pouvait provoquer le blocage d'une requête.
+ Correction d'un bogue SPARQL qui empêchait les réponses aux requêtes d'être compressées au format gzip.
+ Correction d'un bogue Gremlin dans l'étape `groupBy()`.
+ Correction d'un bogue Gremlin lié à l'utilisation d'une étape `aggregate()` au sein d'une étape `local()`.
+ Correction d'un bogue Gremlin lié à l'utilisation de `bothE()` suivi d'un prédicat utilisant des valeurs agrégées.
+ Correction d'un bogue Gremlin lié à l'utilisation de l'étape `bothE()` au sein d'une étape `repeat()`.
+ Correction d'une fuite de mémoire Grenlin potentielle liée à l'étape `both()`.
+ Correction d'un bogue en raison duquel les métriques des demandes manquaient parce qu'un point de terminaison se terminant par / n'était pas géré correctement.
+ Correction d'un bogue qui pouvait générer une exception `ThrottlingException` même si la file d'attente des requêtes n'était pas pleine.
+ Correction d'un bogue lié à la récupération de l'état du chargement lorsqu'un chargement échoue pour une raison telle que `LOAD_DATA_FAILED_DUE_TO_FEED_MODIFIED_OR_DELETE`.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.3.0.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.3`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.3.0.R2
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
Si le paramètre `AutoMinorVersionUpgrade` de votre cluster est défini sur `True`, votre cluster sera automatiquement mis à niveau vers cette version de moteur deux à trois semaines après la date de cette version, au cours d'une fenêtre de maintenance.
## Mise à niveau vers cette version
Amazon Neptune 1.0.3.0.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.3.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.3.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.2 du moteur Amazon Neptune (09/03/2020)
Depuis le 9 mars 2020, la version 1.0.2.2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.2.2.R2 (02/04/2020)](engine-releases-1.0.2.2.R2.md)
+ [Sortie : 1.0.2.2.R3 (22/07/2020)](engine-releases-1.0.2.2.R3.md)
+ [Sortie : 1.0.2.2.R4 (23/07/2020)](engine-releases-1.0.2.2.R4.md)
+ [Sortie : 1.0.2.2.R5 (12/10/2020)](engine-releases-1.0.2.2.R5.md)
+ [Sortie : 1.0.2.2.R6 (19/02/2021)](engine-releases-1.0.2.2.R6.md)
## Améliorations de cette version du moteur
+ Ajout d'informations à l'API d'état sur les transactions qui sont annulées. Consultez [Statut d’une instance](access-graph-status.md).
+ Mise à niveau de la version d'Apache TinkerPop vers la version 3.4.3.
La version 3.4.3 est rétrocompatible avec la version précédente prise en charge par Neptune (3.4.1). Elle introduit un changement mineur dans le comportement : Gremlin ne renvoie plus d'erreur lorsque vous essayez de fermer une session qui n'existe pas (consultez les informations relatives à la [prévention des erreurs lors de la clôture de sessions qui n'existent pas](https://issues.apache.org/jira/browse/TINKERPOP-2237)).
+ Suppression des goulets d'étranglement des performances dans l'exécution des étapes de recherche en texte intégral de Gremlin.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue SPARQL dans la gestion des modèles de graphique vide dans les requêtes.
+ Correction d'un bogue SPARQL dans la gestion des points-virgules non codés dans les requêtes codées en URL.
+ Correction d'un bogue Gremlin dans la gestion des sommets répétés dans l'étape `Union`.
+ Correction d'un bogue Gremlin qui faisait que certaines requêtes avec un `.simplePath()` ou `.cyclicPath()` dans un `.repeat()` renvoyaient des résultats incorrects.
+ Correction d'un bogue Gremlin qui faisant que `.project()` renvoyait des résultats incorrects si sa traversée enfant ne renvoyait aucune solution.
+ Correction d'un bogue Gremlin où les erreurs provenant de conflits de lecture-écriture déclenchaient un `InternalFailureException` plutôt qu’un `ConcurrentModificationException`.
+ Correction d'un bogue Gremlin qui provoquait des échecs `.group().by(...).by(values("property"))`.
+ Correction de bogues Gremlin dans la sortie du profil pour les full-text-search étapes.
+ Correction d'une fuite de ressource dans les sessions Gremlin.
+ Correction d'un bogue qui empêchait l'API d'état de signaler la bonne version à commander dans certains cas.
+ Correction d'un bogue lié au chargeur en bloc qui autorisait qu'une URL à un emplacement autre qu'Amazon S3 soit utilisée comme source dans une demande de chargement en bloc.
+ Correction d'un bogue lié au chargeur en bloc dans le statut détaillé du chargement.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.3`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.2
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
Si le paramètre `AutoMinorVersionUpgrade` de votre cluster est défini sur `True`, votre cluster sera automatiquement mis à niveau vers cette version de moteur deux à trois semaines après la date de cette version, au cours d'une fenêtre de maintenance.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.2.R6 du moteur Amazon Neptune (19/02/2021)
Depuis le 19 février 2021, la version 1.0.2.2.R6 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin où l'exception `InternalFailureException` était définie comme code de réponse dans certaines circonstances lors d'un événement `ConcurrentModificationException`.
+ Correction d'un bogue Gremlin où, dans certaines conditions, la mise à jour des arêtes ou des sommets pouvait provoquer une exception `InternalFailureException` transitoire.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.2.R6, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.8`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.2.R6
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.2.2`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.2.R6 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.2.R5 du moteur Amazon Neptune (12/10/2020)
Depuis le 12 octobre 2020, la version 1.0.2.2.R5 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Améliorations de cette version du moteur
+ Amélioration des performances pour l'étape Gremlin `properties()`.
+ Ajout de détails sur `BindOp` et `MultiplexerOp` dans les rapports d'explication et de profil.
+ Pour les réponses aux requêtes SPARQL, `charset` a été ajouté à l'en-tête Content-Type, permettant aux clients HTTP de reconnaître le jeu de caractères utilisé automatiquement.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue SPARQL qui empêchait la gestion de l'exception `CancellationException`
+ Correction d'un bogue SPARQL qui empêchait les requêtes contenant des options imbriquées de fonctionner correctement.
+ Correction d'un bogue SPARQL dans LOAD où `ConcurrentModificationException` pouvait provoquer le blocage d'une requête.
+ Correction d'un bogue SPARQL qui empêchait les réponses aux requêtes d'être compressées au format gzip.
+ Correction d'un bogue Gremlin dans l'étape `groupBy()`.
+ Correction d'un bogue Gremlin lié à l'utilisation d'une étape `aggregate()` au sein d'une étape `local()`.
+ Correction d'un bogue Gremlin lié à l'utilisation de `bothE()` suivi d'un prédicat utilisant des valeurs agrégées.
+ Correction d'un bogue Gremlin lié à l'utilisation de l'étape `bothE()` au sein d'une étape `repeat()`.
+ Correction d'une fuite de mémoire Grenlin potentielle liée à l'étape `both()`.
+ Correction d'un bogue en raison duquel les métriques des demandes manquaient parce qu'un point de terminaison se terminant par / n'était pas géré correctement.
+ Correction d'un bogue qui pouvait générer une exception `ThrottlingException` même si la file d'attente des requêtes n'était pas pleine.
+ Correction d'un bogue lié à la récupération de l'état du chargement lorsqu'un chargement échoue pour une raison telle que `LOAD_DATA_FAILED_DUE_TO_FEED_MODIFIED_OR_DELETE`.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.2.R5, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.3`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.2.R5
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.2.2`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.2.R5 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.2.R4 du moteur Amazon Neptune (23/07/2020)
Depuis le 23 juillet 2020, la version 1.0.2.2.R4 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Améliorations de cette version du moteur
+ Amélioration de l'utilisation de la mémoire en libérant plus fréquemment la mémoire inutilisée dans le système d'exploitation.
+ L'utilisation de la mémoire a également été améliorée pour les requêtes SPARQL GROUP BY.
+ La durée maximale pendant laquelle une WebSocket connexion authentifiée par IAM peut rester ouverte est passée de 36 heures à 10 jours.
+ Ajout de la `BufferCacheHitRatio` CloudWatch métrique, qui peut être utile pour diagnostiquer la latence des requêtes et ajuster les types d'instances. Consultez [Métriques Neptune](cw-metrics.md#cw-metrics-available).
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue lors de la fermeture des WebSocket connexions IAM inactives ou expirées. Neptune envoie désormais un frame de fermeture avant de fermer la connexion.
+ Correction d'un bogue SPARQL dans l'évaluation des requêtes contenant des conditions FILTER EXISTS FILTER NOT and/or EXISTS imbriquées.
+ Correction d'un bogue de résiliation des requêtes SPARQL qui bloquait les threads sur le serveur dans certaines conditions extrêmes.
+ Correction d'un bogue Gremlin impliquant Edge PathType dans l'étape `hasLabel`.
+ Correction d'un bogue Gremlin pour gérer `toV` et `fromV` individuellement pour chaque direction. `bothE`
+ Correction d'un bogue Gremlin lié à la disparition des effets secondaires.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.2.R4, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.3`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.2.R4
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.2.2`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.2.R4 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.2.R3 du moteur Amazon Neptune (22/07/2020)
La version du moteur 1.0.2.2.R3 a été intégrée à la [version du moteur 1.0.2.2.R4](engine-releases-1.0.2.2.R4.md).
# Version 1.0.2.2.R2 du moteur Amazon Neptune (02/04/2020)
Depuis le 2 avril 2020, la version 1.0.2.2.R2 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Améliorations de cette version du moteur
+ Vous pouvez maintenant mettre en file d'attente jusqu'à 64 tâches de chargement en bloc, au lieu d'attendre la fin d'une tâche avant de lancer la suivante. Vous pouvez également subordonner l'exécution d'une demande de chargement en file d'attente à la réussite d'une ou de plusieurs tâches de chargement précédemment en file d'attente à l'aide du paramètre `dependencies` de la commande `load`. Consultez [Commande de chargeur Neptune](load-api-reference-load.md).
+ Full-text-search la sortie peut maintenant être triée (voir[Paramètres de recherche en texte intégral](full-text-search-parameters.md)).
+ Il existe maintenant un paramètre de cluster de bases de données permettant d'appeler des flux Neptune. Cette fonctionnalité n'est plus en mode expérimental. Consultez [Activation de Neptune Streams](streams-using-enabling.md).
## Défauts corrigés dans cette version du moteur
+ Correction d'une défaillance aléatoire au démarrage du serveur qui retardait la création de l'instance.
+ Correction d'un problème d'optimiseur dans le cadre duquel les instructions `BIND` de la requête faisaient démarrer l'optimiseur avec des motifs non sélectifs dans la planification des ordres de jointure.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.2.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.3`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.2.R2
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.2.2`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.2.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.2 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.2 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.1 du moteur Amazon Neptune (22/11/2019)
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.2.1.R6 (22/04/2020)](engine-releases-1.0.2.1.R6.md)
+ [Sortie : 1.0.2.1.R5 (22/04/2020)](engine-releases-1.0.2.1.R5.md) *Cette version de correctif n'a pas été déployée.*
+ [Sortie : 1.0.2.1.R4 (20/12/2019)](engine-releases-1.0.2.1.R4.md)
+ [Sortie : 1.0.2.1.R3 (12/12/2019)](engine-releases-1.0.2.1.R3.md)
+ [Sortie : 1.0.2.1.R2 (25/11/2019)](engine-releases-1.0.2.1.R2.md)
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout de fonctionnalités de recherche en texte intégral grâce à l'intégration avec Amazon OpenSearch Service. Consultez [Recherche en texte intégral Neptune](full-text-search.md).
+ Ajout de l'option d'utilisation du mode Lab afin de créer un quatrième index (un index OSGP) pour les nombres élevés de prédicats. Consultez [Index OSGP](features-lab-mode.md#features-lab-mode-features-osgp-index).
+ Ajout d'un mode *détaillé* à SPARQL Explain. Consultez [Utilisation de SPARQL `explain`](sparql-explain-using.md) et [Sortie de mode détaillé](sparql-explain-examples.md#sparql-explain-example-details) pour en savoir plus.
+ Ajout d'informations sur le mode Lab au rapport de statut du moteur. Consultez [Statut d’une instance](access-graph-status.md) pour plus de détails.
+ Les instantanés du cluster de bases de données peuvent désormais être copiés d'une AWS région à l'autre. Consultez [Copie d'un instantané](backup-restore-copy-snapshot.md).
## Améliorations de cette version du moteur
+ Amélioration des performances lors du traitement d'un grand nombre de prédicats.
+ Optimisation renforcée des requêtes. Même si cela devrait être entièrement transparent pour les clients, nous vous encourageons à tester vos applications avant de les mettre à niveau afin de vous assurer qu'elles se comportent comme prévu.
+ Améliorations mineures pour la génération de rapport d'erreurs.
+ Ajout d'optimisations pour les étapes Gremlin `.project()` et `.identity()`.
+ Ajout d'optimisations pour les cas `.union()` Gremlin non terminaux.
+ Ajout d'une prise en charge native pour les traversées `.path().by()` de Gremlin.
+ Ajout d'une prise en charge native pour `.coalesce()` de Gremlin.
+ Optimisation supplémentaire de l'écriture en bloc.
+ Nous exigeons désormais que les connexions HTTPS utilisent au moins la version TLS 1.2 ou supérieure, afin d'empêcher l'utilisation de outdated/insecure chiffrements.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue de traitement de traversée interne `addE()` de Gremlin.
+ Correction d'un bogue Gremlin provoqué par la fuite d'annotations AST de traversées enfants vers le parent.
+ Correction d'un bogue qui avait lieu dans Gremlin quand `.otherV()` était appelé après `select()`.
+ Correction d'un bogue Gremlin qui provoquait l'échec de certaines étapes `.hasLabel()` si elles apparaissaient après une étape `bothE()`.
+ Corrections mineures pour .sum() and .project() dans Gremlin.
+ Correction d'un bogue dans le traitement des requêtes SPARQL sans accolade de fermeture.
+ Correction de quelques bogues mineurs dans SPARQL Explain.
+ Correction d'un bogue dans le traitement des demandes d'obtention de statut de chargement simultanées.
+ Mémoire réduite utilisée pour exécuter certaines traversées Gremlin avec des étapes `.project()`.
+ Correction apportée aux comparaisons numériques de valeurs spéciales dans SPARQL. Consultez [Conformité aux normes](feature-overview-standards-compliance.md).
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.1`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.1
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
La mise à niveau vers cette version n'est pas automatique.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.1 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.1.R6 du moteur Amazon Neptune (22/04/2020)
Depuis le 22 avril 2020, la version 1.0.2.1.R6 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue au cours duquel `ConcurrentModificationConflictException` et `TransactionException` n'étaient pas convertis en un élément `NeptuneGremlinException`, provoquant le renvoi de `InternalFailureException` aux clients.
+ Correction d'un bogue où Neptune signalait que son état était sain avant que le serveur ne soit complètement prêt.
+ Correction d'un bogue au cours duquel les validations des transactions du dictionnaire et de l'utilisateur étaient hors service lorsque deux mappages `value->id` étaient insérés simultanément.
+ Correction d'un bogue dans la sérialisation de l'état de charge.
+ Correction d'un bogue des sessions Gremlin.
+ Correction d'un bogue où Neptune ne parvenait pas à émettre une exception lorsque le serveur ne démarrait pas.
+ Correction d'un bogue où Neptune ne parvenait pas à envoyer un frame de fermeture WebSocket avant de fermer le canal.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.1.R6, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.1`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.1.R6
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.2.1`.
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.1.R6 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.1.R5 du moteur Amazon Neptune (22/04/2020)
La version 1.0.2.1.R5 du moteur n'a jamais été déployée.
# Version 1.0.2.1.R4 du moteur Amazon Neptune (20/12/2019)
## Améliorations de cette version du moteur
+ Neptune essaie désormais de toujours placer un full-text-search appel en premier dans le pipeline d'exécution. Cela réduit le volume des appels OpenSearch, ce qui peut améliorer considérablement les performances. Consultez [Full-text-search exécution de requêtes](full-text-search-query-execution.md).
+ Neptune génère désormais une exception `IllegalArgumentException` si vous essayez d'accéder à une propriété, un sommet ou une arête qui n'existe pas. Auparavant, Neptune générait une exception `UnsupportedOperationException` dans cette situation.
Par exemple, si vous essayez d'ajouter une arête référençant un sommet inexistant, vous générerez désormais une `IllegalArgumentException`.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin dans lequel une traversée `union` à l'intérieur d'un `project-by` ne renvoie aucun résultat ou renvoie des résultats incorrects.
+ Correction d'un bogue Gremlin qui faisait renvoyer des résultats incorrects aux étapes `.project().by()` imbriquées.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.1.R4, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.1`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.1.R4
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
Toutefois, **la mise à jour automatique vers cette version n'est pas prise en charge**.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.1.R4 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.1.R3 du moteur Amazon Neptune (12/12/2019)
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue qui entraînait la désactivation de l'index `OSGP`, même si la fonctionnalité était correctement dans[Mode Lab](features-lab-mode.md) à l'aide de la valeur `ObjectIndex` dans le paramètre `neptune_lab_mode`.
+ Correction d'un bogue qui affectait les requêtes Gremlin avec un `.fold()` dans une étape `.project().by()`. Par exemple, la requête suivante a renvoyé des résultats incomplets :
```
g.V().project("a").by(valueMap().fold())
```
+ Correction d'un goulot d'étranglement des performances dans les chargements en groupe de données RDF.
+ Correction d'un bogue qui provoquait un incident sur les réplicas lorsque les flux étaient activés et que le réplica était redémarré avant l'instance principale.
+ Correction d'un bogue où les certificats SSL pivotés sur les instances n'étaient pas récupérés sans un redémarrage de l'instance.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.1.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.1`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.1.R3
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
Toutefois, **la mise à jour automatique vers cette version n'est pas prise en charge**.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.1.R3 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.1.R2 du moteur Amazon Neptune (25/11/2019)
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue affectant toutes les requêtes `project().by()` avec les traversées de type .by autres que rond-robin (tourniquet) et `path()`.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.1.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.1`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.1.R2
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
Toutefois, **la mise à jour automatique vers cette version n'est pas prise en charge**.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.1.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.1 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.1 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.0 du moteur Amazon Neptune (08/11/2019)
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 19 mai 2020, plus aucune instance ne sera créée avec cette version du moteur.
Cette version du moteur est désormais remplacée par la [version 1.0.2.1](engine-releases-1.0.2.1.md), qui contient toutes les corrections de bogues de cette version ainsi que des fonctionnalités supplémentaires telles que l'intégration de la recherche en texte intégral, la prise en charge des index OSGP et la copie de clusters de instantanés de base de données entre les régions. AWS
À compter du 1er juin 2020, Neptune mettra automatiquement à niveau tout cluster exécutant cette version de moteur vers le [dernier correctif de la version 1.0.2.1](engine-releases-1.0.2.1.R6.md) lors de la prochaine fenêtre de maintenance. Vous pouvez effectuer une mise à niveau manuelle avant cette date, comme décrit [ici](engine-releases-1.0.2.1.md).
Si vous rencontrez des problèmes avec la mise à niveau, contactez-nous via [AWS Support](https://aws.amazon.com/support) ou les [Forums des développeurs AWS](https://forums.aws.amazon.com/forum.jspa?forumID=253).
## Versions de correctifs ultérieures pour cette version
+ [Sortie : 1.0.2.0.R3 (05/05/2020)](engine-releases-1.0.2.0.R3.md)
+ [Sortie : 1.0.2.0.R2 (21/11/2019)](engine-releases-1.0.2.0.R2.md)
## Nouvelles fonctionnalités pour cette version du moteur
Outre les mises à jour de maintenance, cette version ajoute de nouvelles fonctionnalités pour prendre en charge plusieurs versions de moteur à la fois (voir [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md)).
Par conséquent, la numérotation des version du moteur a changé (voir [Numérotation des versions avant la version du moteur 1.3.0.0](cluster-maintenance.md#older-engine-numbers)).
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.1`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.0
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
La mise à niveau vers cette version n'est pas automatique.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.0 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.0.R3 du moteur Amazon Neptune (05/05/2020)
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 19 mai 2020, plus aucune instance ne sera créée avec cette version du moteur.
Cette version du moteur est désormais remplacée par la [version 1.0.2.1](engine-releases-1.0.2.1.md), qui contient toutes les corrections de bogues de cette version ainsi que des fonctionnalités supplémentaires telles que l'intégration de la recherche en texte intégral, la prise en charge des index OSGP et la copie de clusters de instantanés de base de données entre les régions. AWS
À compter du 1er juin 2020, Neptune mettra automatiquement à niveau tout cluster exécutant cette version de moteur vers le [dernier correctif de la version 1.0.2.1](engine-releases-1.0.2.1.R6.md) lors de la prochaine fenêtre de maintenance. Vous pouvez effectuer une mise à niveau manuelle avant cette date, comme décrit [ici](engine-releases-1.0.2.1.md).
Si vous rencontrez des problèmes avec la mise à niveau, contactez-nous via [AWS Support](https://aws.amazon.com/support) ou les [Forums des développeurs AWS](https://forums.aws.amazon.com/forum.jspa?forumID=253).
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue au cours duquel `ConcurrentModificationConflictException` et `TransactionException` étaient signalés en tant qu'éléments `InternalFailureException` génériques.
+ Correction de bogues lors des vérifications de l'état qui provoquaient des redémarrages fréquents du serveur lors du démarrage.
+ Correction d'un bogue au cours duquel les données n'étaient pas visibles sur les réplicas parce que les validations n'étaient pas fonctionnelles dans certaines conditions.
+ Correction d'un bogue lié à la sérialisation de l'état de charge au cours duquel une charge échouait en raison d'un manque d'autorisations d'Amazon S3.
+ Correction d'une fuite de ressource dans les sessions Gremlin.
+ Correction d'un bogue lié à la surveillance de l'état qui masquait l'état défectueux au démarrage des composants gérant l'authentification IAM.
+ Correction d'un bug qui empêchait Neptune d'envoyer un WebSocket cadre de fermeture avant de fermer le canal.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.0.R3, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.1`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.0.R3
Votre cluster sera automatiquement mis à niveau vers cette version de correctif lors de votre prochaine fenêtre de maintenance si vous exécutez la version de moteur `1.0.2.0`.
Vous pouvez mettre à niveau manuellement n'importe quelle version précédente du moteur Neptune vers cette version.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.0.R3 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.2.0.R2 du moteur Amazon Neptune (21/11/2019)
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 19 mai 2020, plus aucune instance ne sera créée avec cette version du moteur.
Cette version du moteur est désormais remplacée par la [version 1.0.2.1](engine-releases-1.0.2.1.md), qui contient toutes les corrections de bogues de cette version ainsi que des fonctionnalités supplémentaires telles que l'intégration de la recherche en texte intégral, la prise en charge des index OSGP et la copie de clusters de instantanés de base de données entre les régions. AWS
À compter du 1er juin 2020, Neptune mettra automatiquement à niveau tout cluster exécutant cette version de moteur vers le [dernier correctif de la version 1.0.2.1](engine-releases-1.0.2.1.R6.md) lors de la prochaine fenêtre de maintenance. Vous pouvez effectuer une mise à niveau manuelle avant cette date, comme décrit [ici](engine-releases-1.0.2.1.md).
Si vous rencontrez des problèmes avec la mise à niveau, contactez-nous via [AWS Support](https://aws.amazon.com/support) ou les [Forums des développeurs AWS](https://forums.aws.amazon.com/forum.jspa?forumID=253).
## Défauts corrigés dans cette version du moteur
+ Amélioration de la stratégie de mise en cache pour les pages à valider sur le serveur pour une récupération plus rapide de `FreeableMemory` lorsque le serveur passe à un état de faible mémoire.
+ Correction d'un bogue qui pouvait provoquer une course et un crash lorsque de nombreuses demandes simultanées de chargement initial étaient traitées sur le serveur. and/or
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.2.0.R2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.1`
+ *Version SPARQL :* `1.1`
## Chemins de mise à niveau vers la version de moteur 1.0.2.0.R2
Vous pouvez mettre à niveau manuellement n'importe quelle version antérieure du moteur Neptune vers cette version.
Toutefois, **la mise à jour automatique vers cette version n'est pas prise en charge**.
## Mise à niveau vers cette version
Amazon Neptune 1.0.2.0.R2 est désormais disponible globalement.
Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :
Pour Linux, OS X ou Unix :
```
1. aws neptune modify-db-cluster \
2. --db-cluster-identifier (your-neptune-cluster) \
3. --engine-version 1.0.2.0 \
4. --apply-immediately
```
Pour Windows :
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine-version 1.0.2.0 ^
4. --apply-immediately
```
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.
### Toujour 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. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.
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 changements majeurs.
Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le 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.
**Note**
Si vous essayez de procéder à une mise à niveau alors qu'[une action en attente est en cours](manage-console-maintaining), une erreur telle que la suivante peut survenir :
```
We're sorry, your request to modify DB cluster (cluster identifier) has failed.
Cannot modify engine version because instance (instance identifier) is
running on an old configuration. Apply any pending maintenance actions on the instance before
proceeding with the upgrade.
```
Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.
Pour plus d'informations sur la mise à niveau de la version du moteur , consultez [Maintenance du cluster de bases de données Amazon Neptune](cluster-maintenance.md). Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
# Version 1.0.1.2 du moteur Amazon Neptune (10/06/2020)
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 27 avril 2021, plus aucune instance ne sera créée avec cette version du moteur.
## Améliorations de cette version du moteur
+ Neptune génère désormais une exception `IllegalArgumentException` si vous essayez d'accéder à une propriété, un sommet ou une arête qui n'existe pas. Auparavant, Neptune générait une exception `UnsupportedOperationException` dans cette situation.
Par exemple, si vous essayez d'ajouter une arête référençant un sommet inexistant, vous générerez désormais une `IllegalArgumentException`.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue au cours duquel les validations des transactions du dictionnaire et de l'utilisateur étaient hors service lorsque deux mappages `value->id` étaient insérés simultanément.
+ Correction d'un bogue dans la sérialisation de l'état de charge.
+ Correction d'une défaillance aléatoire au démarrage du serveur qui retardait la création de l'instance.
+ Correction d'une fuite de curseur.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.1.2, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.4.1`
+ *Version SPARQL :* `1.1`
# Version 1.0.1.1 du moteur Amazon Neptune (26/06/2020)
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 27 avril 2021, plus aucune instance ne sera créée avec cette version du moteur.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue où les validations n’étaient pas fonctionnelles lorsqu'elles étaient insérées simultanément.
+ Correction d'un bogue dans la sérialisation de l'état de charge.
+ Correction d'une défaillance aléatoire au démarrage du serveur qui retardait la création de l'instance.
+ Correction d'une fuite de mémoire.
## Versions de langage de requête prises en charge dans cette version
Avant de mettre à niveau un cluster de bases de données vers la version 1.0.1.1, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :
+ *Version Gremlin :* `3.3.2`
+ *Version SPARQL :* `1.1`
# Version 1.0.1.0 du moteur Amazon Neptune (02/07/2019)
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 27 avril 2021, plus aucune instance ne sera créée avec cette version du moteur.
# Mises à jour du moteur Amazon Neptune 31/10/2019
**Version :** 1.0.1.0.200502.0
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 27 avril 2021, plus aucune instance ne sera créée avec cette version du moteur.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bug Gremlin dans la sérialisation de la réponse de l'étape `tree()` lorsque des clients se connectent à Neptune en utilisant `traversal().withRemote(...)` (en d'autres termes, à l'aide du bytecode GLV).
Cette version résout un problème dans lequel les clients qui se connectaient à Neptune à l'aide d'un `traversal().withRemote(...)` recevait une réponse non valide aux requêtes Gremlin contenant une étape `tree()`.
+ Correction d'un bogue SPARQL dans les requêtes `DELETE WHERE LIMIT`, dans lequel le processus de fin de requête se bloquait en raison d'une condition de concurrence, provoquant l'expiration de la requête.
# Mises à jour du moteur Amazon Neptune 15/10/2019
**Version :** 1.0.1.0.200463.0
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 27 avril 2021, plus aucune instance ne sera créée avec cette version du moteur.
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout d'une Explain/Profile fonctionnalité Gremlin (voir[Analyse de l'exécution des requêtes à l'aide de Gremlin `explain`](gremlin-explain.md)).
+ Ajout de [Prise en charge des sessions basées sur des scripts Gremlin](access-graph-gremlin-sessions.md) pour activer l'exécution de plusieurs traversées Gremlin dans une seule transaction.
+ Ajout de la prise en charge de l'extension de requête fédérée SPARQL dans Neptune (voir [Requête fédérée SPARQL 1.1](https://www.w3.org/TR/sparql11-federated-query/) et [Requêtes fédérées SPARQL dans Neptune à l'aide de l'extension `SERVICE`](sparql-service.md)).
+ Ajout d'une fonctionnalité vous permettant d'injecter votre propre `queryId` dans une requête Gremlin ou SPARQL, via un paramètre d'URL HTTP ou via un indicateur de requête `queryId` SPARQL (voir [Injection d'un ID personnalisé dans une requête Neptune Gremlin ou SPARQL](features-query-id.md)).
+ Ajout d'une fonctionnalité [Mode Lab](features-lab-mode.md) à Neptune qui vous permet de tester les fonctionnalités à venir qui ne sont pas encore prêtes à être utilisées en production.
+ Ajout d'une fonctionnalité [Flux Neptune](streams.md) à venir qui consigne de manière fiable chaque modification apportée à votre base de données dans un flux conservé pendant une semaine. Cette fonction est disponible uniquement en mode Lab.
+ Mise à jour de la sémantique formalisée pour les transactions simultanées (voir [Sémantique des transactions dans Neptune](transactions.md)). Cette fonctionnalité offre des garanties de conformité aux normes du secteur en matière de simultanéité.
Cette sémantique des transactions personnalisée est activée par défaut. Dans certains scénarios, cette fonctionnalité peut modifier le comportement de chargement actuel et réduire les performances de chargement. Vous pouvez utiliser le paramètre `neptune_lab_mode` de cluster de bases de données pour revenir à la sémantique précédente en incluant `ReadWriteConflictDetection=disabled` dans la valeur du paramètre.
## Améliorations de cette version du moteur
+ Amélioration de l'[Statut d’une instance](access-graph-status.md)API en indiquant la version TinkerPop et la version de SPARQL utilisées par le moteur.
+ Amélioration des performances de l'opérateur de sous-graphe Gremlin.
+ Amélioration des performances de la sérialisation des réponses Gremlin.
+ Amélioration des performances à l'étape Gremlin Union.
+ Amélioration de la latence des requêtes SPARQL simples.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue Gremlin pour lequel le délai d'attente était renvoyé de manière incorrecte en tant qu'échec interne.
+ Correction d'un bogue SPARQL dans lequel le paramètre ORDER BY exécuté sur un ensemble partiel de variables provoquait une erreur de serveur interne.
# Mises à jour du moteur Amazon Neptune 19/09/2019
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 27 avril 2021, plus aucune instance ne sera créée avec cette version du moteur.
**Version :** 1.0.1.0.200457.0
Amazon Neptune 1.0.1.0.200457.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200457.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre à niveau un cluster de bases de données :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Défauts corrigés dans cette version du moteur
+ Correction d'un problème d'exactitude Gremlin introduit dans la version précédente du moteur (1.0.1.0.200369.0) en supprimant l'amélioration des performances de la gestion des prédicats cumulés qui l'entraînait.
+ Correction d'un bogue SPARQL qui provoquait la génération d'une `InternalServerError` par les requêtes avec le paramètre `DISTINCT` et un modèle unique encapsulé dans `OPTIONAL`.
# Mises à jour du moteur Amazon Neptune 13/08/2019
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 27 avril 2021, plus aucune instance ne sera créée avec cette version du moteur.
## Nouvelles fonctionnalités pour cette version du moteur
+ Ajout d'une option `OVERSUBSCRIBE` au paramètre `parallelism` de [Commande de chargeur Neptune](load-api-reference-load.md), ce qui conduit le chargeur en bloc Neptune à utiliser tous les threads et ressources disponibles.
## Améliorations de cette version du moteur
+ Amélioration des performances des filtres SPARQL contenant des expressions OR logiques simples.
+ Amélioration des performances de Gremlin dans la gestion des prédicats conjonctifs.
## Défauts corrigés dans cette version du moteur
+ Correction d'un bogue SPARQL empêchant la soustraction d'un élément `xsd:duration` à un élément `xsd:date`.
+ Correction d'un bogue SPARQL entraînant des résultats incomplets de l'inlining statique en présence d'un `UNION`.
+ Correction d'un bogue SPARQL dans l'annulation de requête.
+ Correction d'un bogue Gremlin entraînant un dépassement de capacité au cours de la promotion de type.
+ Correction d'un bogue Gremlin dans la gestion des éléments de sommet dans les étapes `addE().from().to()`.
+ Correction d'un bogue Gremlin (publié le 26/07/2019 dans la [version 1.0.1.0 200366.0 du moteur](engine-releases-1.0.1.0.200366.0.md)) impliquant la gestion des valeurs flottantes et des doubles NaN dans les insertions à cardinalité unique.
+ Correction d'un bogue dans la génération de plans de requête impliquant des recherches basées sur les propriétés.
# Mises à jour du moteur Amazon Neptune 26/07/2019
**Version :** 1.0.1.0.200366.0
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 27 avril 2021, plus aucune instance ne sera créée avec cette version du moteur.
## Nouvelles fonctionnalités pour cette version du moteur
+ Mise à niveau vers la TinkerPop version 3.4.1 (voir [Informations de TinkerPop mise à niveau](http://tinkerpop.apache.org/docs/3.4.1/upgrade/) et [journal des modifications TinkerPop 3.4.1](https://github.com/apache/tinkerpop/blob/3.4.1/CHANGELOG.asciidoc#release-3-4-1)).
Ces modifications offrent aux utilisateurs de Neptune de nouvelles fonctionnalités et des améliorations, notamment les suivantes :
+ `GraphBinary` est désormais disponible dans un format de sérialisation.
+ Un bogue de maintien en vie qui provoquait des fuites de mémoire dans le pilote TinkerPop Java a été corrigé. Il n'est donc plus nécessaire de le contourner.
Toutefois, dans quelques cas, elles peuvent affecter le code Gremlin existant dans Neptune. Par exemple :
+ `valueMap()` renvoie désormais un `Map` au lieu d'un `Map`.
+ Le comportement incohérent de l'étape `within()` a été corrigé pour la rendre compatible avec les autres étapes. Auparavant, les types devaient correspondre pour que les comparaisons fonctionnent. Désormais, il est possible de comparer des nombres de types différents avec précision. Par exemple, `33` est maintenant considéré comme égal à `33L`, ce qui n'était pas le cas auparavant.
+ Un bogue dans `ReducingBarrierStep` a été corrigé, si bien qu'il ne renvoie plus de valeur si aucun élément n'est disponible pour la sortie.
+ L'ordre des portées `select()` a changé (l'ordre est désormais `maps`, `side-effects`, `paths`). Cela a pour effet de changer les résultats des rares requêtes qui combinent `side-effects` et `select` avec le même nom de clé pour `side-effects` que pour `select`.
+ `bulkSet()` fait désormais partie du protocole GraphSON. Les requêtes qui se terminent par `toBulkSet()` ne fonctionnent pas avec les anciens clients.
+ Un paramétrage de l'étape `Submit()` a été supprimée du client 3.4.
De nombreuses autres modifications introduites dans la version TinkerPop 3.4 n'affectent pas le comportement actuel de Neptune. Par exemple, `io()` de Gremlin a été ajouté en tant qu'étape à `Traversal` et est désormais obsolète dans `Graph`, mais n'a jamais été activé dans Neptune.
+ Ajout de la prise en charge des propriétés de sommet à cardinalité unique au [chargeur en bloc pour Gremlin](bulk-load-tutorial-format-gremlin.md#bulk-load-tutorial-format-gremlin-propheaders) pour charger les données de graphes de propriétés.
+ Ajout d'une option permettant de remplacer les valeurs existantes d'une propriété à cardinalité unique dans le chargeur en bloc.
+ Ajout de la possibilité de [récupérer le statut d'une requête Gremlin](gremlin-api-status.md) et d'[annuler une requête Gremlin](gremlin-api-status-cancel.md).
+ Ajout d'un [indicateur de requête pour les délais d'expiration de requête SPARQL](sparql-query-hints-queryTimeout.md).
+ Ajout de la possibilité d'afficher le rôle d'instance dans l'API de statut (consultez [Statut d’une instance](access-graph-status.md)).
+ Ajout de la prise en charge du clonage de base de données (consultez [Clonage de bases de données dans Neptune](manage-console-cloning.md)).
## Améliorations de cette version du moteur
+ Amélioration de l'explication des requêtes SPARQL pour afficher les variables de graphe à partir des clauses FROM.
+ Amélioration des performances de SPARQL dans les filtres, les filtres « égal à », les clauses VALUES et les nombres de plages.
+ Amélioration des performances pour le classement des étapes Gremlin.
+ Amélioration des performances pour les traversées `.repeat.dedup` Gremlin.
+ Amélioration des performances pour les traversées `valueMap()` et `path().by()` Gremlin.
## Défauts corrigés dans cette version du moteur
+ Résolution de plusieurs problèmes liés aux chemins de propriété SPARQL, y compris à l'opération avec des graphes nommés.
+ Résolution d'un problème lié aux requêtes SPARQL CONSTRUCT entraînant des problèmes de mémoire.
+ Résolution d'un problème lié à l'analyseur RDF Turtle et aux noms locaux.
+ Résolution d'un problème de correction des messages d'erreur affichés aux utilisateurs.
+ Résolution d'un problème lié aux traversées `repeat()...drop()` Gremlin.
+ Résolution d'un problème lié à l'étape `drop()` Gremlin.
+ Résolution d'un problème lié aux filtres d'étiquette Gremlin.
+ Résolution d'un problème lié aux délais d'expiration de requête Gremlin.
# Mises à jour du moteur Amazon Neptune 02/07/2019
## IMPORTANT : CETTE VERSION DU MOTEUR EST MAINTENANT OBSOLÈTE
À partir du 27 avril 2021, plus aucune instance ne sera créée avec cette version du moteur.
## Défauts corrigés dans cette version du moteur
+ Un bogue, qui empêchait l'optimisation de certains modèles dont le nom et la valeur de propriété étaient liés, a été corrigé.
# Versions antérieures de Neptune Engine
**Topics**
+ [Mises à jour du moteur Amazon Neptune 12/06/2019](engine-releases-1.0.1.0.200310.0.md)
+ [Mises à jour du moteur Amazon Neptune 01/05/2019](engine-releases-1.0.1.0.200296.0.md)
+ [Mises à jour du moteur Amazon Neptune 21/01/2019](engine-releases-1.0.1.0.200267.0.md)
+ [Mises à jour du moteur Amazon Neptune 19/11/2018](engine-releases-1.0.1.0.200264.0.md)
+ [Mises à jour du moteur Amazon Neptune 08/11/2018](engine-releases-1.0.1.0.200258.0.md)
+ [Mises à jour du moteur Amazon Neptune 29/10/2018](engine-releases-1.0.1.0.200255.0.md)
+ [Mises à jour du moteur Amazon Neptune 06/09/2018](engine-releases-1.0.1.0.200237.0.md)
+ [Mises à jour du moteur Amazon Neptune 24/07/2018](engine-releases-1.0.1.0.200236.0.md)
+ [Mises à jour du moteur Amazon Neptune 22/06/2018](engine-releases-1.0.1.0.200233.0.md)
# Mises à jour du moteur Amazon Neptune 12/06/2019
**Version :** 1.0.1.0.200310.0
Amazon Neptune 1.0.1.0.200310.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200310.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre immédiatement à niveau un cluster de bases de données vers cette version :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
Les clusters de bases de données Neptune seront automatiquement mis à niveau vers la version 1.0.1.0.200310.0 du moteur pendant les fenêtres de maintenance du système. L'horaire d'application des mises à jour dépend de la région et du paramètre de fenêtre de maintenance configuré pour le cluster de bases de données, ainsi que du type de mise à jour.
**Note**
La fenêtre de maintenance de l'instance ne s'applique pas aux mises à jour du moteur.
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Améliorations
+ Un bogue, où l'insertion et la suppression simultanées d'une périphérie pouvait générer plusieurs périphéries portant le même ID, a été corrigé.
+ Autres correctifs mineurs et améliorations.
# Mises à jour du moteur Amazon Neptune 01/05/2019
**Version :** 1.0.1.0.200296.0
Amazon Neptune 1.0.1.0.200296.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200296.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre immédiatement à niveau un cluster de bases de données vers cette version :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
Les clusters de bases de données Neptune seront automatiquement mis à niveau vers la version 1.0.1.0.200296.0 du moteur pendant les fenêtres de maintenance du système. L'horaire d'application des mises à jour dépend de la région et du paramètre de fenêtre de maintenance configuré pour le cluster de bases de données, ainsi que du type de mise à jour.
**Note**
La fenêtre de maintenance de l'instance ne s'applique pas aux mises à jour du moteur.
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Améliorations
+ Ajout de la nouvelle fonctionnalité `explain` aux requêtes SPARQL Neptune pour vous aider à visualiser le plan de requête et à prendre les mesures nécessaires pour l'optimiser si nécessaire. Pour plus d'informations, consultez [SPARQL `explain`Extension SPARQL `SERVICE`](sparql-explain.md).
+ Amélioration des performances et des rapports de SPARQL de diverses manières.
+ Amélioration des performances et du comportement de Gremlin de diverses manières.
+ Amélioration de l'expiration des requêtes `drop( )` de longue durée.
+ Amélioration des performances des requêtes `otherV( )`.
+ Ajout de deux champs aux informations renvoyées quand vous interrogez l'état Neptune d'un cluster ou d'une instance de base de données, notamment le numéro de version du moteur et l'heure de démarrage du cluster ou de l'instance. Consultez [Statut d’une instance](access-graph-status.md).
+ L'API `Get-Status` du chargeur Neptune renvoie désormais un champ `startTime` qui enregistre l'heure de début d'une tâche de chargement.
+ La commande de chargeur prend désormais un paramètre `parallelism` facultatif qui vous permet de limiter le nombre de threads que le chargeur utilise.
# Mises à jour du moteur Amazon Neptune 21/01/2019
**Version :** 1.0.1.0.200267.0
Amazon Neptune 1.0.1.0.200267.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200267.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre immédiatement à niveau un cluster de bases de données vers cette version :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
Les clusters de bases de données Neptune seront automatiquement mis à niveau vers la version 1.0.1.0.200267.0 du moteur pendant les fenêtres de maintenance du système. L'horaire d'application des mises à jour dépend de la région et du paramètre de fenêtre de maintenance configuré pour le cluster de bases de données, ainsi que du type de mise à jour.
**Note**
La fenêtre de maintenance de l'instance ne s'applique pas aux mises à jour du moteur.
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Améliorations
+ Neptune attend plus longtemps (dans le délai d'interrogation spécifié) que les conflits soient résolus. Cela réduit le nombre d'exceptions de modifications simultanées qui doivent être gérées par le client (voir [Erreurs liées aux requêtes](errors-engine-codes.md#errors-query)).
+ Un problème qui amenait parfois l'application de la cardinalité par Gremlin à provoquer le redémarrage du moteur a été résolu.
+ Amélioration des performances de Gremlin pour les requêtes répétées `emit.times`.
+ Un problème de Gremlin par lequel `repeat.until` laissait passer des solutions `.emit` qui auraient dû être filtrées a été résolu.
+ Amélioration de la gestion des erreurs dans Gremlin.
# Mises à jour du moteur Amazon Neptune 19/11/2018
**Version :** 1.0.1.0.200264.0
Amazon Neptune 1.0.1.0.200264.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200264.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre immédiatement à niveau un cluster de bases de données vers cette version :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
Les clusters de bases de données Neptune seront automatiquement mis à niveau vers la version 1.0.1.0.200264.0 du moteur pendant les fenêtres de maintenance du système. L'horaire d'application des mises à jour dépend de la région et du paramètre de fenêtre de maintenance configuré pour le cluster de bases de données, ainsi que du type de mise à jour.
**Note**
La fenêtre de maintenance de l'instance ne s'applique pas aux mises à jour du moteur.
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Améliorations
+ Ajout de la prise en charge de [Indicateurs de requête Gremlin](gremlin-query-hints.md).
+ Amélioration des messages d'erreur pour l'authentification IAM. Pour de plus amples informations, veuillez consulter [Erreurs d'authentification IAM](errors-engine-codes.md#errors-iam-auth).
+ Amélioration des performances des requêtes SPARQL avec un grand nombre de prédicats.
+ Amélioration des performances de chemin de propriété SPARQL.
+ Amélioration des performances de Gremlin pour les mutations conditionnelles, telles que le modèle `fold().coalesce(unfold(), …)` lorsqu'il est utilisé avec les étapes `addV()`, `addE()` et `property()`.
+ Amélioration des performances de Gremlin pour les modulations `by()` et `sack()`.
+ Amélioration des performances de Gremlin pour les étapes `group()` et `groupCount()`.
+ Amélioration des performances de Gremlin pour les étapes `store()`, `sideEffect()` et `cap().unfold()`.
+ Amélioration de la prise en charge pour les contraintes de propriétés de cardinalité unique Gremlin.
+ Amélioration de l'application de la cardinalité unique à des propriétés d'arc et des propriétés de sommet marquées comme des propriétés de cardinalité unique.
+ Introduction d'une erreur si des valeurs de propriétés supplémentaires sont spécifiées pour une propriété d'arc existante lors de tâches de chargement Neptune.
# Mises à jour du moteur Amazon Neptune 08/11/2018
**Version :** 1.0.1.0.200258.0
Amazon Neptune 1.0.1.0.200258.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200258.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre immédiatement à niveau un cluster de bases de données vers cette version :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
Les clusters de bases de données Neptune seront automatiquement mis à niveau vers la version 1.0.1.0.200258.0 du moteur pendant les fenêtres de maintenance du système. L'horaire d'application des mises à jour dépend de la région et du paramètre de fenêtre de maintenance configuré pour le cluster de bases de données, ainsi que du type de mise à jour.
**Note**
La fenêtre de maintenance de l'instance ne s'applique pas aux mises à jour du moteur.
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Améliorations
+ Ajout de la prise en charge de [Indicateurs de requête SPARQL](sparql-query-hints.md).
+ Amélioration des performances des requêtes Exists SPARQL FILTER (NOT).
+ Amélioration des performances des requêtes SPARQL DESCRIBE.
+ Amélioration des performances pour le modèle de répétition jusqu'à dans Gremlin.
+ Amélioration de la performance pour l'ajout d'arcs dans Gremlin.
+ Résolution d'un problème où des requêtes SPARQL Update DELETE pouvaient échouer dans certains cas.
+ Correction d'un problème de gestion des délais d'attente sur le serveur Gremlin WebSocket.
# Mises à jour du moteur Amazon Neptune 29/10/2018
**Version :** 1.0.1.0.200255.0
Amazon Neptune 1.0.1.0.200255.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200255.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre immédiatement à niveau un cluster de bases de données vers cette version :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
Les clusters de bases de données Neptune seront automatiquement mis à niveau vers la version 1.0.1.0.200255.0 du moteur pendant les fenêtres de maintenance du système. L'horaire d'application des mises à jour dépend de la région et du paramètre de fenêtre de maintenance configuré pour le cluster de bases de données, ainsi que du type de mise à jour.
**Note**
La fenêtre de maintenance de l'instance ne s'applique pas aux mises à jour du moteur.
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Améliorations
+ Ajout d'informations sur l'authentification IAM dans les journaux d'audit.
+ Ajout de la prise en charge des informations d'identification temporaires à l'aide de rôles IAM et de profils d'instance.
+ Ajout de la terminaison de WebSocket connexion pour l'authentification IAM lorsque l'autorisation est révoquée ou si l'utilisateur ou le rôle IAM est supprimé.
+ Le nombre maximum de WebSocket connexions a été limité à 60 000 par instance.
+ Amélioration des performances du chargement en bloc pour de plus petits types d'instance.
+ Amélioration des performances pour les requêtes qui incluent les opérateurs `and()`, `or()`, `not()` et `drop()` dans Gremlin.
+ L' NTriples analyseur rejette désormais les éléments non valides URIs, tels que ceux URIs contenant des espaces blancs.
# Mises à jour du moteur Amazon Neptune 06/09/2018
**Version :** 1.0.1.0.200237.0
Amazon Neptune 1.0.1.0.200237.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200237.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre immédiatement à niveau un cluster de bases de données vers cette version :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
Les clusters de bases de données Neptune seront automatiquement mis à niveau vers la version 1.0.1.0.200237.0 du moteur pendant les fenêtres de maintenance du système. L'horaire d'application des mises à jour dépend de la région et du paramètre de fenêtre de maintenance configuré pour le cluster de bases de données, ainsi que du type de mise à jour.
**Note**
La fenêtre de maintenance de l'instance ne s'applique pas aux mises à jour du moteur.
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Améliorations
+ Résolution d'un problème où des requêtes `SPARQL COUNT(DISTINCT)` échouaient.
+ Résolution d'un problème où les requêtes `COUNT`, `SUM` et `MIN` avec une clause `DISTINCT` manquaient de mémoire.
+ Résolution d'un problème où le type de données `BLOB` entraînait l'échec d'une tâche de chargeur Neptune.
+ Résolution d'un problème où les insertions en double entraînaient des échecs de transaction.
+ Résolution d'un problème où les requêtes `DROP ALL` ne pouvaient pas être annulées.
+ Résolution d'un problème où les clients Gremlin se bloquaient de façon intermittente.
+ Mise à jour de tous les codes d'erreur pour les charges utiles plus volumineuses que 150 M à la valeur `HTTP 400`.
+ Amélioration des performances et de la précision des single-triple-pattern `COUNT()` requêtes.
+ Amélioration des performances des requêtes `SPARQL UNION` avec les clauses `BIND`.
# Mises à jour du moteur Amazon Neptune 24/07/2018
**Version :** 1.0.1.0.200236.0
Amazon Neptune 1.0.1.0.200236.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200236.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre immédiatement à niveau un cluster de bases de données vers cette version :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
Les clusters de bases de données Neptune seront automatiquement mis à niveau vers la version 1.0.1.0.200236.0 du moteur pendant les fenêtres de maintenance du système. L'horaire d'application des mises à jour dépend de la région et du paramètre de fenêtre de maintenance configuré pour le cluster de bases de données, ainsi que du type de mise à jour.
**Note**
La fenêtre de maintenance de l'instance ne s'applique pas aux mises à jour du moteur.
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Améliorations
+ Mise à jour de la sérialisation SPARQL pour le type de données `xsd:string`. xsd:string n'est plus inclus dans la sérialisation JSON, qui est désormais cohérente avec d'autres formats de sortie.
+ Correction du traitement de l'infini `xsd:double`/`xsd:float`. Les valeurs `-INF`, `NaN`, et `INF` sont désormais reconnues et traitées correctement dans tous les formats de chargeur de données SPARQL, SPARQL 1.1 UPDATE et SPARQL 1.1 Query.
+ Résolution d'un problème en raison duquel une requête Gremlin avec des valeurs de chaîne vides échoue de manière inattendue.
+ Résolution d'un problème en raison duquel `aggregate()` et `cap()` sur un graphique vide échoue de manière inattendue.
+ Résolution d'un problème en raison duquel des réponses d'erreur incorrectes sont renvoyées pour Gremlin lorsque la spécification de cardinalité n'est pas valide, par exemple `.property(set,id,'10')` et `.property(single,id,'10')`.
+ Correction d'un problème en raison duquel une syntaxe Gremlin non valide était renvoyée sous forme de InternalFailureException.
+ Correction de l'orthographe dans `TimeLimitExceeededException` en `TimeLimitExceededException`, dans des messages d'erreur.
+ Modification de la réponse des points de terminaison SPARQL et GREMLIN en une réponse cohérente lorsqu'aucun script n'est fourni.
+ Clarification des messages d'erreur pour un trop grand nombre de demandes simultanées.
# Mises à jour du moteur Amazon Neptune 22/06/2018
**Version :** 1.0.1.0.200233.0
Amazon Neptune 1.0.1.0.200233.0 est disponible globalement. Tous les nouveaux clusters de bases de données Neptune, y compris ceux restaurés à partir d'instantanés, seront créés dans 1.0.1.0.200233.0 une fois la mise à jour du moteur terminée pour cette région.
Les clusters existants peuvent être mis immédiatement à niveau vers cette version à l'aide des opérations de base de données sur la console ou à l’aide du kit SDK. Vous pouvez utiliser la commande CLI suivante pour mettre immédiatement à niveau un cluster de bases de données vers cette version :
```
aws neptune apply-pending-maintenance-action \
--apply-action system-update \
--opt-in-type immediate \
--resource-identifier arn:aws:rds::::
```
Les clusters de bases de données Neptune seront automatiquement mis à niveau vers la version 1.0.1.0.200233.0 du moteur pendant les fenêtres de maintenance du système. L'horaire d'application des mises à jour dépend de la région et du paramètre de fenêtre de maintenance configuré pour le cluster de bases de données, ainsi que du type de mise à jour.
**Note**
La fenêtre de maintenance de l'instance ne s'applique pas aux mises à jour du moteur.
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 toutes les instances figurant dans un cluster de bases de données, si bien que vous connaîtrez de 20-30 secondes à plusieurs minutes d'indisponibilité, après quoi vous pourrez reprendre l'utilisation de votre ou de vos clusters de bases de données. Vous pouvez consulter et modifier vos paramètres de fenêtre de maintenance dans la [console Neptune](https://console.aws.amazon.com/neptune/home).
Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le [support AWS Premium](https://aws.amazon.com/support).
## Améliorations
+ Résolution d'un problème où l'émission en succession rapide d'un grand nombre de demandes de chargement en masse provoquait une erreur.
+ Correction d'un problème dépendant des données à cause duquel une requête pouvait échouer avec un InternalServerError. L'exemple suivant montre le type de requête concerné.
```
g.V("my-id123").as("start").outE("knows").has("edgePropertyKey1", P.gt(0)).as("myedge").inV()
.as("end").select("start", "end", "myedge").by("vertexPropertyKey1")
.by("vertexPropertyKey1").by("edgePropertyKey1")
```
+ Correction d'un problème en raison duquel un client Java Gremlin ne pouvait pas se connecter au serveur en utilisant la même WebSocket connexion après l'expiration du délai d'une requête de longue durée.
+ Correction d'un problème en raison duquel les séquences échappées contenues dans le cadre de la requête Gremlin via HTTP ou des requêtes basées sur des chaînes via la WebSocket connexion n'étaient pas traitées correctement.