Versions de correctifs Nouvelles fonctions Améliorations Défauts corrigés Versions de langage de requête prises en charge Chemins de mise à niveau Mise à niveau

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

Nouvelles fonctionnalités pour cette version du moteur

Le langage de requête openCypher 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.
Ajout de la prise en charge de TinkerPop 3.5.2. Parmi les modifications apportées dans cette version figurent la prise en charge des transactions à distance et la prise en charge du bytecode pour les sessions (avec g.tx), ainsi que l'ajout de la fonction datetime() au langage Gremlin.

Avertissement
Plusieurs modifications importantes introduites dans TinkerPop 3.5.0, 3.5.1 et 3.5.2 peuvent affecter le code Gremlin. Par exemple, l'utilisation des traversées générées par un objet GraphTraversalSource en tant qu'enfants ne fonctionne 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 que vous pouvez utiliser dans les stratégies d'accès aux données IAM 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 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_dfe_query_engine plutôt que le paramètre lab-mode.

Améliorations de cette version du moteur

Ajout de nouvelles fonctionnalités à openCypher, 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 openCypher conformité aux spécifications dans Amazon Neptune 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 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 bytecode WebSocket et des requêtes HTTP de Gremlin 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

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 :


aws neptune modify-db-cluster \
    --db-cluster-identifier (your-neptune-cluster) \
    --engine neptune \
    --engine-version 1.1.1.0 \
    --allow-major-version-upgrade \
    --apply-immediately

Pour Windows :


aws neptune modify-db-cluster ^
    --db-cluster-identifier (your-neptune-cluster) ^
    --engine neptune ^
    --engine-version 1.1.1.0 ^
    --allow-major-version-upgrade ^
    --apply-immediately

Au lieu d'--apply-immediately, vous pouvez spécifier --no-apply-immediately. Pour effectuer une mise à niveau de version majeure, le paramètre allow-major-version-upgrade 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, 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. En cas de question ou de doute, l'équipe AWS Support est disponible sur les forums de la communauté et via AWS Premium Support.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Sortie : 1.2.0.0.R2 (14/10/2022)

Sortie : 1.1.1.0.R7 (23/01/2023)