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