Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Amazon Neptune Engine-Version 1.2.0.0 (21.07.2022) Ab dem 21.07.2022 wird die Engine-Version 1.2.0.0 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist. **Anmerkung** **Bei einem Upgrade von einer Engine-Version vor 1.2.0.0:** Mit der [Engine-Version 1.2.0.0](#engine-releases-1.2.0.0) wurde ein neues Format für benutzerdefinierte Parametergruppen und benutzerdefinierte Cluster-Parametergruppen eingeführt. Wenn Sie also von einer Engine-Version vor 1.2.0.0 auf Engine-Version 1.2.0.0 oder höher aktualisieren, müssen Sie alle vorhandenen benutzerdefinierten Parametergruppen und benutzerdefinierten Cluster-Parametergruppen mithilfe der Parametergruppenfamilie `neptune1.2` neu erstellen. In früheren Versionen wurde die Parametergruppenfamilie `neptune1` verwendet und diese Parametergruppen funktionieren nicht mit Version 1.2.0.0 und höher. Weitere Informationen finden Sie unter [Amazon-Neptune-Parametergruppen](parameter-groups.md). Mit der Engine-Version 1.2.0.0 wurde auch ein neues Format für Undo-Protokolle eingeführt. Daher müssen alle Undo-Logs, die von einer früheren Engine-Version erstellt wurden, gelöscht werden und die [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch Metrik muss auf Null fallen, bevor ein Upgrade von einer Version vor 1.2.0.0 gestartet werden kann. Wenn beim Versuch, ein Update zu starten, zu viele Undo-Protokolldatensätze (200.000 oder mehr) vorhanden sind, kann es beim Upgrade-Versuch zu einer Zeitüberschreitung kommen, während auf den Abschluss des Löschvorgangs der Undo-Protokolle gewartet wird. Sie können die Löschgeschwindigkeit beschleunigen, indem Sie die Writer-Instance des Clusters aktualisieren, in der das Löschen stattfindet. Wenn Sie dies tun, bevor Sie versuchen, das Upgrade durchzuführen, kann die Anzahl der Undo-Logs vor dem Start reduziert werden. Wenn Sie die Größe des Writers auf einen 24XL-Instance-Typ erhöhen, kann sich Ihre Löschrate auf mehr als eine Million Datensätze pro Stunde erhöhen. Wenn die `UndoLogsListSize` CloudWatch Metrik extrem umfangreich ist, kann Ihnen die Eröffnung eines Support-Falls dabei helfen, zusätzliche Strategien zu finden, um sie zu reduzieren. Schließlich wurde mit Version 1.2.0.0 eine bahnbrechende Änderung eingeführt, die sich auf früheren Code auswirkt, der das Bolt-Protokoll mit IAM-Authentifizierung verwendete. Ab Version 1.2.0.0 benötigt Bolt einen Ressourcenpfad für die IAM-Signatur. In Java könnte das Festlegen des Ressourcenpfads so aussehen: `request.setResourcePath("/openCypher"));`. In anderen Sprachen kann `/openCypher` an den Endpunkt-URI angehängt werden. Beispiele finden Sie unter [Verwenden des Bolt-Protokolls](access-graph-opencypher-bolt.md). ## Nachfolgende Patch-Veröffentlichungen für dieses Version + [Release: 1.2.0.0.R2 (14.10.2022)](engine-releases-1.2.0.0.R2.md) + [Release: 1.2.0.0.R3 (15.12.2022)](engine-releases-1.2.0.0.R3.md) + [Release: 1.2.0.0.R4 (29.09.2023)](engine-releases-1.2.0.0.R4.md) ## Neue Features in dieser Engine-Version + Unterstützung für [globale Datenbanken](neptune-global-database.md) hinzugefügt. Eine globale Neptune-Datenbank umfasst mehrere AWS-Regionen Datenbanken und besteht aus einem primären DB-Cluster in einer Region und bis zu fünf sekundären DB-Clustern in anderen Regionen. + Unterstützung für eine detailliertere Zugriffskontrolle in Neptune IAM-Richtlinien als bisher hinzugefügt, basierend auf Aktionen auf Datenebene. Dies ist insofern eine signifikante Änderung, als bestehende IAM-Richtlinien, die auf der veralteten `connect`-Aktion basieren, angepasst werden müssen, um die detaillierteren Aktionen auf der Datenebene zu verwenden. Siehe [Arten von IAM-Richtlinien](security-iam-access-manage.md#iam-auth-policy). + Verbesserte Verfügbarkeit von Reader-Instances Zuvor wurden, als eine Writer-Instance neu gestartet wurde, alle Reader-Instances in einem Neptune-Cluster automatisch neu gestartet. Ab Engine-Version 1.2.0.0 bleiben Reader-Instances auch nach einem Writer-Neustart aktiv, was die Verfügbarkeit der Reader verbessert. Reader-Instances können separat neu gestartet werden, um Änderungen an Parametergruppen zu übernehmen. Siehe [Neustarten einer DB-Instance in Amazon Neptune](manage-console-instances-reboot.md). + Es wurde ein neuer DB-Cluster-Parameter [neptune\$1streams\$1expiry\$1days](parameters.md#parameters-db-cluster-parameters-neptune_streams_expiry_days) hinzugefügt, mit dem Sie festlegen können, wie viele Tage Stream-Datensätze auf dem Server aufbewahrt werden, bevor sie gelöscht werden. Der Bereich ist 1 bis 90 und der Standard ist 7. ## Verbesserungen in dieser Engine-Version + Die Leistung der Gremlin-Serialisierung für Abfragen wurde verbessert. ByteCode + Neptune verarbeitet Textprädikate jetzt mithilfe der DFE-Engine, um die Leistung zu verbessern. + Neptune verarbeitet `limit()` Gremlin-Schritte jetzt mithilfe der DFE-Engine, einschließlich Grenzwerten für Nichtterminal- und untergeordneten Traversal-Grenzwerte. + Die DFE-Behandlung des Gremlin-`union()`-Schritts wurde geändert, sodass er mit anderen neuen Features funktioniert. Das bedeutet, dass Referenzknoten wie erwartet in Abfrageprofilen angezeigt werden. + Die Leistung einiger teurer Join-Operationen innerhalb von DFE wurde um den Faktor 5 verbessert, indem sie parallelisiert wurden. + `by()` Modulationsunterstützung für `OrderGlobalStep order(global)` für die Gremlin DFE-Engine hinzugefügt. + Die Anzeige eingefügter statischer Werte wurde in den Erläuterungsdetails für DFE hinzugefügt. + Die Leistung beim Löschen doppelter Muster wurde verbessert. + Unterstützung für die Beibehaltung von Aufträgen in der Gremlin DFE-Engine hinzugefügt. + Die Leistung von Gremlin-Abfragen mit leeren Filtern wie diesen wurde verbessert: ``` g.V().hasId(P.within([])) ``` ``` g.V().hasId([]) ``` + Fehlermeldungen wurden verbessert, wenn eine SPARQL-Abfrage einen numerischen Wert verwendet, der für Neptune zu groß ist, um ihn intern darzustellen. + Die Leistung beim Löschen von Scheitelpunkten mit zugehörigen Edges wurde verbessert, indem die Anzahl der Indexsuchen reduziert wurde, wenn Streams deaktiviert sind. + Die DFE-Unterstützung wurde um mehr Varianten des `has()` Schritts erweitert, insbesondere um die Prädikate to `hasKey()``hasLabel()`, und Range for within. strings/URIs `has()` Dies betrifft Abfragen wie die folgende: ``` // 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)")) ``` + Es wurde eine Neptune-spezifische openCypher-[`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function)Funktion hinzugefügt, die Zeichenketten in einer Liste zu einer einzigen Zeichenkette verkettet. + Die von [Neptune verwalteten Richtlinien](security-iam-access-managed-policies.md) wurden aktualisiert und enthalten nun Datenzugriffsberechtigungen und Berechtigungen für die neue globale Datenbank. APIs ## In diesem Engine-Version behobene Fehler + Es wurde ein Fehler behoben, bei dem eine HTTP-Anfrage ohne angegebenen Inhaltstyp automatisch fehlschlug. + Es wurde ein SPARQL-Fehler im Abfrageoptimierer behoben, der die Verwendung eines Serviceaufrufs innerhalb einer Abfrage verhinderte. + Es wurde ein SPARQL-Fehler im Turtle RDF-Parser behoben, bei dem eine bestimmte Kombination von Unicode-Daten zu einem Ausfall führte. + Es wurde ein SPARQL-Fehler behoben, bei dem eine bestimmte Kombination von `GRAPH`- und `SELECT`-Klauseln zu falschen Abfrageergebnissen führte. + Es wurde ein Gremlin-Fehler behoben, der zu einem Korrektheitsproblem bei Abfragen führte, die einen beliebigen Filterschritt innerhalb eines Union-Schritts verwendeten, wie zum Beispiel den folgenden: ``` g.V("1").union(hasLabel("person"), out()) ``` + Es wurde ein Gremlin-Fehler behoben, bei dem `count()` von `both().simplePath()` zu einer doppelten Anzahl von Ergebnissen führen würde, die ohne `count()` zurückgegeben wurden. + Es wurde ein openCypher-Fehler behoben, bei dem vom Server für Bolt-Anfragen an Cluster mit aktivierter IAM-Authentifizierung eine fehlerhafte Ausnahme wegen Nichtübereinstimmung der Signatur generiert wurde. + Es wurde ein openCypher-Fehler behoben, bei dem eine Abfrage, die HTTP-Keep-Alive verwendete, fälschlicherweise geschlossen werden konnte, wenn sie nach einer fehlgeschlagenen Anfrage eingereicht wurde. + Es wurde ein openCypher-Fehler behoben, der dazu führen konnte, dass ein interner Fehler ausgelöst wurde, wenn eine Abfrage, die einen konstanten Wert zurückgibt, gesendet wurde. + Es wurde ein Fehler in den Erläuterungsdetails behoben, sodass die DFE-Unterabfrage die CPU-Zeiten von Operatoren innerhalb der DFE-Unterabfrage `Time(ms)` jetzt korrekt summiert. Betrachten Sie den folgenden Auszug aus der Erklärungsausgabe als Beispiel: ``` 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 ║ ╚════╧════════╧════════╧═══════════════════════╧═══════════════════════════════════╧══════╧══════════╧═══════════╧═══════╧═══════════╝ ``` Die subQuery-Zeiten in der letzten Spalte der unteren Tabelle ergeben zusammen 0,36 ms (`.04 + .29 + .01 + .02 = .36`). Wenn Sie die Koordinationszeit für diese Unterabfrage (`.36 + .026 = .386`) hinzurechnen, erhalten Sie ein Ergebnis, das der Zeit für die subQuery, die in der letzten Spalte der oberen Tabelle aufgezeichnet wurde, sehr nahe kommt, nämlich `0.38` ms. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.0.0 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist: + *Die älteste unterstützte Version von Gremlin:* `3.5.2` + *Die neueste unterstützte Version von Gremlin:* `3.5.4` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade-Pfade zum Engine-Release 1.2.0.0 Da es sich um eine wichtige Engine-Version handelt, gibt es kein automatisches Upgrade darauf. Sie können nur `1.2.0.0` manuell vom neuesten Patch-Release des [Engine-Release 1.1.1.0](engine-releases-1.1.1.0.md) auf Release aktualisieren. Frühere Engine-Versionen müssen zuerst auf die neueste Version von `1.1.1.0` aktualisiert werden, bevor sie auf `1.2.0.0` aktualisiert werden können. Bevor Sie versuchen, auf diese Version zu aktualisieren, sollten Sie daher überprüfen, ob Sie derzeit den neuesten Patch-Release von Release `1.1.1.0` verwenden. Falls nicht, führen Sie zunächst ein Upgrade auf den neuesten Patch-Release von `1.1.1.0` durch. Vor dem Upgrade müssen Sie außerdem alle benutzerdefinierten DB-Cluster-Parametergruppen, die Sie mit Ihrer vorherigen Version verwendet haben, mithilfe der Parametergruppenfamilie `neptune1.2` neu erstellen. Weitere Informationen finden Sie unter [Amazon-Neptune-Parametergruppen](parameter-groups.md). Wenn Sie zuerst auf Version `1.1.1.0` und dann sofort auf Version `1.2.0.0` aktualisieren, tritt möglicherweise ein Fehler wie der folgende auf: ``` 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. ``` Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann (siehe [Warten eines Amazon-Neptune-DB-Clusters](cluster-maintenance.md)). ## Upgrade auf diesen Release Wenn auf einem DB-Cluster eine Engine-Version ausgeführt wird, für die es einen Upgrade-Pfad zu dieser Version gibt, kann sie jetzt aktualisiert werden. Sie können jeden geeigneten Cluster mithilfe der DB-Cluster-Operationen auf der Konsole oder mithilfe des SDK aktualisieren. Mit dem folgenden CLI-Befehl wird ein geeignetes Cluster sofort aktualisiert: Für Linux, OS X oder 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 ``` Für 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 ``` Statt `--apply-immediately` können Sie `--no-apply-immediately` angeben. Um ein Upgrade einer Hauptversion durchzuführen, ist der allow-major-version-upgrade Parameter erforderlich. Stellen Sie außerdem sicher, dass Sie die Engine-Version angeben, da Ihre Engine sonst möglicherweise auf eine andere Version aktualisiert wird. Wenn Ihr Cluster eine benutzerdefinierte Cluster-Parametergruppe verwendet, müssen Sie diesen Parameter einschließen, um ihn zu anzugeben: ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` Ebenso sollte für Instances im Cluster, die eine benutzerdefinierte DB-Parametergruppe verwenden, dieser Parameter eingeschlossen werden, um ihn zu spezifizieren: ``` --db-instance-parameter-group-name (name of the custom instance parameter group) ``` ### Testen Sie immer vor dem Upgrade Wenn eine neue Haupt- oder Nebenversion der Neptune-Engine veröffentlicht wird, testen Sie Ihre Neptune-Anwendungen immer zuerst dafür, bevor Sie sie dazu aktualisieren. Selbst ein Nebenversions-Upgrade könnte neue Features oder Verhaltensweisen einführen, die sich auf Ihren Code auswirken können. Vergleichen Sie zunächst die Seiten mit den Versionshinweisen Ihrer aktuellen Version mit denen der Zielversion, um festzustellen, ob es Änderungen an den Versionen der Abfragesprache oder andere wichtige Änderungen geben wird. Die beste Methode, eine neue Version zu testen, bevor Sie Ihren Produktions-DB-Cluster aktualisieren, besteht darin, den Produktions-Cluster zu klonen, so dass auf dem Klon die neue Engine-Version ausgeführt wird. Sie können dann Abfragen auf dem Klon ausführen, ohne dass der Produktions-DB-Cluster davon betroffen wird. ### Erstellen Sie vor einem Upgrade immer einen manuellen Snapshot Bevor Sie ein Upgrade durchführen, wird dringend empfohlen, immer einen manuellen Snapshot Ihres DB-Clusters zu erstellen. Ein automatischer Snapshot bietet nur kurzfristigen Schutz, wohingegen ein manueller Snapshot verfügbar bleibt, bis Sie ihn explizit löschen. In bestimmten Fällen erstellt Neptune im Rahmen des Upgrade-Prozesses einen manuellen Snapshot für Sie, aber Sie sollten sich nicht darauf verlassen und in jedem Fall Ihren eigenen manuellen Snapshot erstellen. Wenn Sie sicher sind, dass Sie Ihren DB-Cluster nicht auf den Zustand vor dem Upgrade zurücksetzen müssen, können Sie den manuellen Snapshot, den Sie selbst erstellt haben, sowie den manuellen Snapshot, den Neptune möglicherweise erstellt hat, explizit löschen. Wenn Neptune einen manuellen Snapshot erstellt, hat dieser einen Namen, der mit `preupgrade` beginnt, gefolgt vom Namen Ihres DB-Clusters, der Quell-Engine-Version, der Ziel-Engine-Version und dem Datum. **Anmerkung** Wenn Sie versuchen, ein Upgrade durchzuführen, während [eine ausstehende Aktion ausgeführt wird](manage-console-maintaining), kann ein Fehler wie der folgende auftreten: ``` 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. ``` Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann. Weitere Informationen zum Upgraden Ihrer Engine-Version finden Sie unter [Warten eines Amazon-Neptune-DB-Clusters](cluster-maintenance.md). Wenn Sie Fragen oder Bedenken haben, steht Ihnen das AWS Support-Team in den Community-Foren und über den [AWS Premium-Support](https://aws.amazon.com/support) zur Verfügung. # Amazon Neptune Engine-Version 1.2.0.0.R4 (29.09.2023) Ab dem 29.09.2023 wird die Engine-Version 1.2.0.0.R4 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist. **Anmerkung** **Bei einem Upgrade von einer Engine-Version vor 1.2.0.0:** Mit der [Engine-Version 1.2.0.0](engine-releases-1.2.0.0.md) wurde ein neues Format für benutzerdefinierte Parametergruppen und benutzerdefinierte Cluster-Parametergruppen eingeführt. Wenn Sie also von einer Engine-Version vor 1.2.0.0 auf Engine-Version 1.2.0.0 oder höher aktualisieren, müssen Sie alle vorhandenen benutzerdefinierten Parametergruppen und benutzerdefinierten Cluster-Parametergruppen mithilfe der Parametergruppenfamilie `neptune1.2` neu erstellen. In früheren Versionen wurde die Parametergruppenfamilie `neptune1` verwendet und diese Parametergruppen funktionieren nicht mit Version 1.2.0.0 und höher. Weitere Informationen finden Sie unter [Amazon-Neptune-Parametergruppen](parameter-groups.md). Mit der Engine-Version 1.2.0.0 wurde auch ein neues Format für Undo-Protokolle eingeführt. Daher müssen alle Undo-Logs, die von einer früheren Engine-Version erstellt wurden, gelöscht werden und die [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch Metrik muss auf Null fallen, bevor ein Upgrade von einer Version vor 1.2.0.0 gestartet werden kann. Wenn beim Versuch, ein Update zu starten, zu viele Undo-Protokolldatensätze (200.000 oder mehr) vorhanden sind, kann es beim Upgrade-Versuch zu einer Zeitüberschreitung kommen, während auf den Abschluss des Löschvorgangs der Undo-Protokolle gewartet wird. Sie können die Löschgeschwindigkeit beschleunigen, indem Sie die Writer-Instance des Clusters aktualisieren, in der das Löschen stattfindet. Wenn Sie dies tun, bevor Sie versuchen, das Upgrade durchzuführen, kann die Anzahl der Undo-Logs vor dem Start reduziert werden. Wenn Sie die Größe des Writers auf einen 24XL-Instance-Typ erhöhen, kann sich Ihre Löschrate auf mehr als eine Million Datensätze pro Stunde erhöhen. Wenn die `UndoLogsListSize` CloudWatch Metrik extrem umfangreich ist, kann Ihnen die Eröffnung eines Support-Falls dabei helfen, zusätzliche Strategien zu finden, um sie zu reduzieren. Schließlich wurde mit Version 1.2.0.0 eine bahnbrechende Änderung eingeführt, die sich auf früheren Code auswirkt, der das Bolt-Protokoll mit IAM-Authentifizierung verwendete. Ab Version 1.2.0.0 benötigt Bolt einen Ressourcenpfad für die IAM-Signatur. In Java könnte das Festlegen des Ressourcenpfads so aussehen: `request.setResourcePath("/openCypher"));`. In anderen Sprachen kann `/openCypher` an den Endpunkt-URI angehängt werden. Beispiele finden Sie unter [Verwenden des Bolt-Protokolls](access-graph-opencypher-bolt.md). ## Verbesserungen in dieser Engine-Version + Allen [Neptune ML](machine-learning-api-reference.md) wurde ein `enableInterContainerTrafficEncryption` Parameter hinzugefügt APIs, mit dem Sie die Verschlüsselung des Datenverkehrs zwischen Containern in Trainings- oder Hyperparameter-Tuning-Jobs aktivieren und deaktivieren können. + Für serverlose DB-Cluster wurde die Einstellung für die Mindestkapazität auf 1,0 NCU und die niedrigste gültige Maximaleinstellung auf 2,5 geändert. NCUs Siehe [Kapazitätsskalierung in einem Neptune-Serverless-DB-Cluster](neptune-serverless-capacity-scaling.md) *(((before release, this change needs to be reflected in the serverless page too))).* ## In diesem Engine-Version behobene Fehler + Es wurde ein OpenCypher-Fehler behoben, bei dem update-and-return Abfragen nicht oder nicht richtig behandelt `orderBy` wurden. `limit` `skip` + Es wurde ein openCypher-Fehler behoben, durch den Parameter, die in einer Anfrage enthalten waren, durch Parameter in einer anderen gleichzeitigen Anfrage überschrieben werden konnten. + Es wurde ein openCypher-Fehler bei der Transaktionsverarbeitung von Bolt behoben. + Behebung von Gremlin-Korrektheitsproblemen bei DFE-Abfragen mit `limit` als untergeordneter Traversal von Nicht-Union-Schritten durch Rückgriff auf Tinkerpop. Zum Beispiel für Abfragen wie diese: ``` g.withSideEffect('Neptune#useDFE', true) .V() .as("a") .select("a") .by(out() .limit(1)) ``` + Es wurde ein Gremlin-Fehler behoben, bei dem eine Abfrage fehlschlug, weil sie zu viele TinkerPop Schritte enthielt, und dann nicht bereinigt wurde. + Es wurde ein Gremlin-Fehler behoben, bei dem Zeichenkettenausgaben von `order()` nicht richtig sortiert wurden, wenn einige von ihnen ein Leerzeichen enthielten. + Es wurde ein Gremlin-Fehler behoben, durch den ein Transaktionsleck auftreten konnte, wenn eine Abfrage als Zeichenfolge gesendet wurde und `GroupCountStep` enthalten hat. + Es wurde ein Gremlin-Fehler behoben, bei dem es zu einem Transaktionsleck kam, wenn der Endpunkt des Gremlin-Abfragestatus auf Abfragen mit Prädikaten in untergeordneten Durchläufen für Schritte überprüft wurde, die nicht nativ verarbeitet wurden. + Es wurde ein Gremlin-Fehler behoben, durch den beim Hinzufügen einer Edge und ihrer Eigenschaften gefolgt von `inV()` oder `outV()` ein `InternalFailureException` verursacht wurde. + Ein Problem mit der Parallelität in der Speicherebene wurde behoben. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.0.0.R4 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist: + *Die älteste unterstützte Version von Gremlin:* `3.5.2` + *Die neueste unterstützte Version von Gremlin:* `3.5.6` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade-Pfade zum Engine-Release 1.2.0.0.R4 Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.2.0.0` ausführen. Sie können nur `1.2.0.0` manuell vom neuesten Patch-Release des [Engine-Release 1.1.1.0](engine-releases-1.1.1.0.md) auf Release aktualisieren. Frühere Engine-Versionen müssen zuerst auf die neueste Version von `1.1.1.0` aktualisiert werden, bevor sie auf `1.2.0.0` aktualisiert werden können. Wenn Sie zuerst auf Version `1.1.1.0` und dann sofort auf Version `1.2.0.0` aktualisieren, tritt möglicherweise ein Fehler wie der folgende auf: ``` 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. ``` Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann. ## Upgrade auf diesen Release Wenn auf einem DB-Cluster eine Engine-Version ausgeführt wird, für die es einen Upgrade-Pfad zu dieser Version gibt, kann sie jetzt aktualisiert werden. Sie können jeden geeigneten Cluster mithilfe der DB-Cluster-Operationen auf der Konsole oder mithilfe des SDK aktualisieren. Mit dem folgenden CLI-Befehl wird ein geeignetes Cluster sofort aktualisiert: Für Linux, OS X oder 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 ``` Für 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 ``` Statt `--apply-immediately` können Sie `--no-apply-immediately` angeben. Um ein Hauptversions-Upgrade durchzuführen, ist der allow-major-version-upgrade Parameter erforderlich. Stellen Sie außerdem sicher, dass Sie die Engine-Version angeben, da Ihre Engine sonst möglicherweise auf eine andere Version aktualisiert wird. Wenn Ihr Cluster eine benutzerdefinierte Cluster-Parametergruppe verwendet, müssen Sie diesen Parameter einschließen, um ihn zu anzugeben: ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` Ebenso sollte für Instances im Cluster, die eine benutzerdefinierte DB-Parametergruppe verwenden, dieser Parameter eingeschlossen werden, um ihn zu spezifizieren: ``` --db-instance-parameter-group-name (name of the custom instance parameter group) ``` ### Testen Sie immer vor dem Upgrade Wenn eine neue Haupt- oder Nebenversion der Neptune-Engine veröffentlicht wird, testen Sie Ihre Neptune-Anwendungen immer zuerst dafür, bevor Sie sie dazu aktualisieren. Selbst ein Nebenversions-Upgrade könnte neue Features oder Verhaltensweisen einführen, die sich auf Ihren Code auswirken können. Vergleichen Sie zunächst die Seiten mit den Versionshinweisen Ihrer aktuellen Version mit denen der Zielversion, um festzustellen, ob es Änderungen an den Versionen der Abfragesprache oder andere wichtige Änderungen geben wird. Die beste Methode, eine neue Version zu testen, bevor Sie Ihren Produktions-DB-Cluster aktualisieren, besteht darin, den Produktions-Cluster zu klonen, so dass auf dem Klon die neue Engine-Version ausgeführt wird. Sie können dann Abfragen auf dem Klon ausführen, ohne dass der Produktions-DB-Cluster davon betroffen wird. ### Erstellen Sie vor einem Upgrade immer einen manuellen Snapshot Bevor Sie ein Upgrade durchführen, wird dringend empfohlen, immer einen manuellen Snapshot Ihres DB-Clusters zu erstellen. Ein automatischer Snapshot bietet nur kurzfristigen Schutz, wohingegen ein manueller Snapshot verfügbar bleibt, bis Sie ihn explizit löschen. In bestimmten Fällen erstellt Neptune im Rahmen des Upgrade-Prozesses einen manuellen Snapshot für Sie, aber Sie sollten sich nicht darauf verlassen und in jedem Fall Ihren eigenen manuellen Snapshot erstellen. Wenn Sie sicher sind, dass Sie Ihren DB-Cluster nicht auf den Zustand vor dem Upgrade zurücksetzen müssen, können Sie den manuellen Snapshot, den Sie selbst erstellt haben, sowie den manuellen Snapshot, den Neptune möglicherweise erstellt hat, explizit löschen. Wenn Neptune einen manuellen Snapshot erstellt, hat dieser einen Namen, der mit `preupgrade` beginnt, gefolgt vom Namen Ihres DB-Clusters, der Quell-Engine-Version, der Ziel-Engine-Version und dem Datum. **Anmerkung** Wenn Sie versuchen, ein Upgrade durchzuführen, während [eine ausstehende Aktion ausgeführt wird](manage-console-maintaining), kann ein Fehler wie der folgende auftreten: ``` 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. ``` Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann. Weitere Informationen zum Upgraden Ihrer Engine-Version finden Sie unter [Warten eines Amazon-Neptune-DB-Clusters](cluster-maintenance.md). Wenn Sie Fragen oder Bedenken haben, steht Ihnen das AWS Support-Team in den Community-Foren und über den [AWS Premium-Support](https://aws.amazon.com/support) zur Verfügung. # Amazon Neptune Engine-Version 1.2.0.0.R3 (15.12.2022) Ab dem 15.12.2022 wird die Engine-Version 1.2.0.0.R3 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist. **Anmerkung** **Bei einem Upgrade von einer Engine-Version vor 1.2.0.0:** Mit der [Engine-Version 1.2.0.0](engine-releases-1.2.0.0.md) wurde ein neues Format für benutzerdefinierte Parametergruppen und benutzerdefinierte Cluster-Parametergruppen eingeführt. Wenn Sie also von einer Engine-Version vor 1.2.0.0 auf Engine-Version 1.2.0.0 oder höher aktualisieren, müssen Sie alle vorhandenen benutzerdefinierten Parametergruppen und benutzerdefinierten Cluster-Parametergruppen mithilfe der Parametergruppenfamilie `neptune1.2` neu erstellen. In früheren Versionen wurde die Parametergruppenfamilie `neptune1` verwendet und diese Parametergruppen funktionieren nicht mit Version 1.2.0.0 und höher. Weitere Informationen finden Sie unter [Amazon-Neptune-Parametergruppen](parameter-groups.md). Mit der Engine-Version 1.2.0.0 wurde auch ein neues Format für Undo-Protokolle eingeführt. Daher müssen alle Undo-Logs, die von einer früheren Engine-Version erstellt wurden, gelöscht werden und die [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch Metrik muss auf Null fallen, bevor ein Upgrade von einer Version vor 1.2.0.0 gestartet werden kann. Wenn beim Versuch, ein Update zu starten, zu viele Undo-Protokolldatensätze (200.000 oder mehr) vorhanden sind, kann es beim Upgrade-Versuch zu einer Zeitüberschreitung kommen, während auf den Abschluss des Löschvorgangs der Undo-Protokolle gewartet wird. Sie können die Löschgeschwindigkeit beschleunigen, indem Sie die Writer-Instance des Clusters aktualisieren, in der das Löschen stattfindet. Wenn Sie dies tun, bevor Sie versuchen, das Upgrade durchzuführen, kann die Anzahl der Undo-Logs vor dem Start reduziert werden. Wenn Sie die Größe des Writers auf einen 24XL-Instance-Typ erhöhen, kann sich Ihre Löschrate auf mehr als eine Million Datensätze pro Stunde erhöhen. Wenn die `UndoLogsListSize` CloudWatch Metrik extrem umfangreich ist, kann Ihnen die Eröffnung eines Support-Falls dabei helfen, zusätzliche Strategien zu finden, um sie zu reduzieren. Schließlich wurde mit Version 1.2.0.0 eine bahnbrechende Änderung eingeführt, die sich auf früheren Code auswirkt, der das Bolt-Protokoll mit IAM-Authentifizierung verwendete. Ab Version 1.2.0.0 benötigt Bolt einen Ressourcenpfad für die IAM-Signatur. In Java könnte das Festlegen des Ressourcenpfads so aussehen: `request.setResourcePath("/openCypher"));`. In anderen Sprachen kann `/openCypher` an den Endpunkt-URI angehängt werden. Beispiele finden Sie unter [Verwenden des Bolt-Protokolls](access-graph-opencypher-bolt.md). ## Verbesserungen in dieser Engine-Version + Verbesserte Leistung von openCypher-Abfragen mit `MERGE` und `OPTIONAL MATCH`. + Die Leistung von openCypher-Abfragen, die `UNWIND` mit einer Liste von Zuordnungen mit Literalwerten beinhalten, wurde verbessert. + Verbesserte Leistung von openCypher-Abfragen, die einen `IN`-Filter für `id` haben. Zum Beispiel: ``` MATCH (n) WHERE id(n) IN ['1', '2', '3'] RETURN n ``` + Leistungsverbesserungen und Korrekturkorrekturen für verschiedene Gremlin-Operatoren, darunter `repeat`, `coalesce`, `store` und `aggregate`. ## In diesem Engine-Version behobene Fehler + Es wurde ein openCypher-Fehler behoben, bei dem Abfragen die Zeichenfolge, `"null"`, anstelle eines Nullwerts in Bolt und SPARQL-JSON zurückgaben. + Ein openCypher-Fehler wurde behoben, sodass der Parametertyp korrekt interpretiert werden konnte, wenn der Wert eine Liste oder eine Liste von Maps ist. + Es wurde ein Fehler im Auditprotokoll behoben, der dazu führte, dass unnötige Informationen protokolliert wurden und bestimmte Felder in den Protokollen fehlten. + Es wurde ein Auditprotokollfehler behoben, bei dem der IAM-ARN von HTTP-Anfragen an einen IAM-fähigen DB-Cluster nicht aufgezeichnet wurde. + Es wurde ein Fehler im Lookup-Cache behoben, sodass der inkrementelle Speicher, der für Schreibvorgänge in den Cache verwendet wurde, begrenzt wurde. + Es wurde ein Lookup-Cache-Fehler behoben, bei dem für den Lookup-Cache der Nur-Lese-Modus eingestellt wurde, wenn Schreibvorgänge fehlschlugen. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.0.0.R3 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist: + *Die älteste unterstützte Version von Gremlin:* `3.5.2` + *Die neueste unterstützte Version von Gremlin:* `3.5.4` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade-Pfade zum Engine-Release 1.2.0.0.R3 Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.2.0.0` ausführen. Sie können nur `1.2.0.0` manuell vom neuesten Patch-Release des [Engine-Release 1.1.1.0](engine-releases-1.1.1.0.md) auf Release aktualisieren. Frühere Engine-Versionen müssen zuerst auf die neueste Version von `1.1.1.0` aktualisiert werden, bevor sie auf `1.2.0.0` aktualisiert werden können. Wenn Sie zuerst auf Version `1.1.1.0` und dann sofort auf Version `1.2.0.0` aktualisieren, tritt möglicherweise ein Fehler wie der folgende auf: ``` 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. ``` Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann. ## Upgrade auf diesen Release Wenn auf einem DB-Cluster eine Engine-Version ausgeführt wird, für die es einen Upgrade-Pfad zu dieser Version gibt, kann sie jetzt aktualisiert werden. Sie können jeden geeigneten Cluster mithilfe der DB-Cluster-Operationen auf der Konsole oder mithilfe des SDK aktualisieren. Mit dem folgenden CLI-Befehl wird ein geeignetes Cluster sofort aktualisiert: Für Linux, OS X oder 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 ``` Für 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 ``` Statt `--apply-immediately` können Sie `--no-apply-immediately` angeben. Um ein Upgrade auf eine Hauptversion durchzuführen, ist der allow-major-version-upgrade Parameter erforderlich. Stellen Sie außerdem sicher, dass Sie die Engine-Version angeben, da Ihre Engine sonst möglicherweise auf eine andere Version aktualisiert wird. Wenn Ihr Cluster eine benutzerdefinierte Cluster-Parametergruppe verwendet, müssen Sie diesen Parameter einschließen, um ihn zu anzugeben: ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` Ebenso sollte für Instances im Cluster, die eine benutzerdefinierte DB-Parametergruppe verwenden, dieser Parameter eingeschlossen werden, um ihn zu spezifizieren: ``` --db-instance-parameter-group-name (name of the custom instance parameter group) ``` ### Testen Sie immer vor dem Upgrade Wenn eine neue Haupt- oder Nebenversion der Neptune-Engine veröffentlicht wird, testen Sie Ihre Neptune-Anwendungen immer zuerst dafür, bevor Sie sie dazu aktualisieren. Selbst ein Nebenversions-Upgrade könnte neue Features oder Verhaltensweisen einführen, die sich auf Ihren Code auswirken können. Vergleichen Sie zunächst die Seiten mit den Versionshinweisen Ihrer aktuellen Version mit denen der Zielversion, um festzustellen, ob es Änderungen an den Versionen der Abfragesprache oder andere wichtige Änderungen geben wird. Die beste Methode, eine neue Version zu testen, bevor Sie Ihren Produktions-DB-Cluster aktualisieren, besteht darin, den Produktions-Cluster zu klonen, so dass auf dem Klon die neue Engine-Version ausgeführt wird. Sie können dann Abfragen auf dem Klon ausführen, ohne dass der Produktions-DB-Cluster davon betroffen wird. ### Erstellen Sie vor einem Upgrade immer einen manuellen Snapshot Bevor Sie ein Upgrade durchführen, wird dringend empfohlen, immer einen manuellen Snapshot Ihres DB-Clusters zu erstellen. Ein automatischer Snapshot bietet nur kurzfristigen Schutz, wohingegen ein manueller Snapshot verfügbar bleibt, bis Sie ihn explizit löschen. In bestimmten Fällen erstellt Neptune im Rahmen des Upgrade-Prozesses einen manuellen Snapshot für Sie, aber Sie sollten sich nicht darauf verlassen und in jedem Fall Ihren eigenen manuellen Snapshot erstellen. Wenn Sie sicher sind, dass Sie Ihren DB-Cluster nicht auf den Zustand vor dem Upgrade zurücksetzen müssen, können Sie den manuellen Snapshot, den Sie selbst erstellt haben, sowie den manuellen Snapshot, den Neptune möglicherweise erstellt hat, explizit löschen. Wenn Neptune einen manuellen Snapshot erstellt, hat dieser einen Namen, der mit `preupgrade` beginnt, gefolgt vom Namen Ihres DB-Clusters, der Quell-Engine-Version, der Ziel-Engine-Version und dem Datum. **Anmerkung** Wenn Sie versuchen, ein Upgrade durchzuführen, während [eine ausstehende Aktion ausgeführt wird](manage-console-maintaining), kann ein Fehler wie der folgende auftreten: ``` 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. ``` Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann. Weitere Informationen zum Upgraden Ihrer Engine-Version finden Sie unter [Warten eines Amazon-Neptune-DB-Clusters](cluster-maintenance.md). Wenn Sie Fragen oder Bedenken haben, steht Ihnen das AWS Support-Team in den Community-Foren und über den [AWS Premium-Support](https://aws.amazon.com/support) zur Verfügung. # Amazon Neptune Engine-Version 1.2.0.0.R2 (14.10.2022) Ab dem 14.10.2022 wird die Engine-Version 1.2.0.0.R2 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist. **Anmerkung** **Bei einem Upgrade von einer Engine-Version vor 1.2.0.0:** Mit der [Engine-Version 1.2.0.0](engine-releases-1.2.0.0.md) wurde ein neues Format für benutzerdefinierte Parametergruppen und benutzerdefinierte Cluster-Parametergruppen eingeführt. Wenn Sie also von einer Engine-Version vor 1.2.0.0 auf Engine-Version 1.2.0.0 oder höher aktualisieren, müssen Sie alle vorhandenen benutzerdefinierten Parametergruppen und benutzerdefinierten Cluster-Parametergruppen mithilfe der Parametergruppenfamilie `neptune1.2` neu erstellen. In früheren Versionen wurde die Parametergruppenfamilie `neptune1` verwendet und diese Parametergruppen funktionieren nicht mit Version 1.2.0.0 und höher. Weitere Informationen finden Sie unter [Amazon-Neptune-Parametergruppen](parameter-groups.md). Mit der Engine-Version 1.2.0.0 wurde auch ein neues Format für Undo-Protokolle eingeführt. Daher müssen alle Undo-Logs, die von einer früheren Engine-Version erstellt wurden, gelöscht werden und die [`UndoLogsListSize`](cw-metrics.md#cw-metrics-UndoLogListSize) CloudWatch Metrik muss auf Null fallen, bevor ein Upgrade von einer Version vor 1.2.0.0 gestartet werden kann. Wenn beim Versuch, ein Update zu starten, zu viele Undo-Protokolldatensätze (200.000 oder mehr) vorhanden sind, kann es beim Upgrade-Versuch zu einer Zeitüberschreitung kommen, während auf den Abschluss des Löschvorgangs der Undo-Protokolle gewartet wird. Sie können die Löschgeschwindigkeit beschleunigen, indem Sie die Writer-Instance des Clusters aktualisieren, in der das Löschen stattfindet. Wenn Sie dies tun, bevor Sie versuchen, das Upgrade durchzuführen, kann die Anzahl der Undo-Logs vor dem Start reduziert werden. Wenn Sie die Größe des Writers auf einen 24XL-Instance-Typ erhöhen, kann sich Ihre Löschrate auf mehr als eine Million Datensätze pro Stunde erhöhen. Wenn die `UndoLogsListSize` CloudWatch Metrik extrem umfangreich ist, kann Ihnen die Eröffnung eines Support-Falls dabei helfen, zusätzliche Strategien zu finden, um sie zu reduzieren. Schließlich wurde mit Version 1.2.0.0 eine bahnbrechende Änderung eingeführt, die sich auf früheren Code auswirkt, der das Bolt-Protokoll mit IAM-Authentifizierung verwendete. Ab Version 1.2.0.0 benötigt Bolt einen Ressourcenpfad für die IAM-Signatur. In Java könnte das Festlegen des Ressourcenpfads so aussehen: `request.setResourcePath("/openCypher"));`. In anderen Sprachen kann `/openCypher` an den Endpunkt-URI angehängt werden. Beispiele finden Sie unter [Verwenden des Bolt-Protokolls](access-graph-opencypher-bolt.md). ## Verbesserungen in dieser Engine-Version + Verbesserte Leistung von Gremlin-`order-by`-Abfragen. Gremlin-Abfragen mit einem `order-by` am Ende eines `NeptuneGraphQueryStep` verwenden jetzt eine größere Chunk-Größe für bessere Leistung. Dies gilt nicht für `order-by` auf einem internen (Nicht-Wurzel-)Knoten des Abfrageplans. + Verbesserte Leistung von Gremlin-Update-Abfragen. Scheitelpunkte und Kanten müssen jetzt beim Hinzufügen von Edges oder Eigenschaften gegen Löschen gesperrt werden. Durch diese Änderung werden doppelte Sperren innerhalb einer Transaktion beseitigt, wodurch die Leistung verbessert wird. + Die Leistung von Gremlin-Abfragen, die `dedup()` innerhalb einer `repeat()` Unterabfrage verwendet werden, wurde verbessert, indem sie auf die native `dedup` Ausführungsebene verschoben wurden. + Der Gremlin-`Neptune#cardinalityEstimates`-Abfragehinweis wurde hinzugefügt. Wenn auf `false` gesetzt, werden Kardinalitätsschätzungen deaktiviert. + Es wurden benutzerfreundliche Fehlermeldungen für IAM-Authentifizierungsfehler hinzugefügt. Diese Nachrichten zeigen jetzt den ARN Ihres IAM-Benutzers oder Ihrer Rolle, den Ressourcen-ARN und eine Liste der nicht autorisierten Aktionen für die Anfrage. Anhand der Liste der nicht autorisierten Aktionen können Sie erkennen, was in der von Ihnen verwendeten IAM-Richtlinie möglicherweise fehlt oder ausdrücklich verweigert wurde. ## In diesem Engine-Version behobene Fehler + Es wurde ein Gremlin-Korrekturfehler im Zusammenhang mit `WherePredicateStep`-Übersetzungen behoben, bei dem die Abfrage-Engine von Neptune falsche Ergebnisse für Abfragen mit `where(P.neq('x'))` und Varianten davon lieferte. + Es wurde ein Gremlin-Fehler behoben, bei dem die Verwendung `PartitionStrategy` nach dem Upgrade auf TinkerPop 3.5 fälschlicherweise zu einem Fehler mit der Meldung „PartitionStrategy Funktioniert nicht mit anonymen Durchläufen“ führte, wodurch die Ausführung des Traversals verhindert wurde. + Es wurden verschiedene Gremlin-Fehler im Zusammenhang mit einem `joinTime` eines finalen Join und mit Statistiken innerhalb von `Project.ASK`-Untergruppen behoben. + Ein openCypher-Fehler in der `MERGE`-Klausel wurde behoben, der in einigen Fällen zur doppelten Erstellung von Knoten und Edges führte. + Es wurde ein Transaktionsfehler behoben, durch den eine Sitzung Grafikdaten einfügen und festschreiben konnte, selbst wenn die entsprechenden gleichzeitigen Wörterbucheinfügungen rückgängig gemacht wurden. + Es wurde ein Massenladerfehler behoben, der bei hohen Einfügebelatungen zu Leistungsregressionen führte. + Es wurde ein SPARQL-Fehler bei der Behandlung von Abfragen behoben, die `(NOT) EXISTS` innerhalb einer `OPTIONAL`-Klausel enthalten waren, wodurch in einigen Fällen Abfrageergebnisse fehlten. + Es wurde ein Fehler behoben, durch den Treiber scheinbar hängen blieben, wenn Anfragen aufgrund einer Zeitüberschreitung vor dem Start der Evaluierung storniert wurden. Es war möglich, in diesen Zustand zu gelangen, wenn alle Threads zur Abfrageverarbeitung auf dem Server verbraucht waren, während es bei Elementen in der Anforderungswarteschlange zu Zeitüberschreitungen kam. Da die Zeitüberschreitungen in der Anforderungswarteschlange nicht sofort auf das Senden von Nachrichten zurückzuführen waren, hatte der Client den Eindruck, dass die Antworten noch ausstehen würden. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.0.0.R2 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist: + *Die älteste unterstützte Version von Gremlin:* `3.5.2` + *Die neueste unterstützte Version von Gremlin:* `3.5.4` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade-Pfade zum Engine-Release 1.2.0.0.R2 Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.2.0.0` ausführen. Sie können nur `1.2.0.0` manuell vom neuesten Patch-Release des [Engine-Release 1.1.1.0](engine-releases-1.1.1.0.md) auf Release aktualisieren. Frühere Engine-Versionen müssen zuerst auf die neueste Version von `1.1.1.0` aktualisiert werden, bevor sie auf `1.2.0.0` aktualisiert werden können. Wenn Sie zuerst auf Version `1.1.1.0` und dann sofort auf Version `1.2.0.0` aktualisieren, tritt möglicherweise ein Fehler wie der folgende auf: ``` 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. ``` Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann. ## Upgrade auf diesen Release Wenn auf einem DB-Cluster eine Engine-Version ausgeführt wird, für die es einen Upgrade-Pfad zu dieser Version gibt, kann sie jetzt aktualisiert werden. Sie können jeden geeigneten Cluster mithilfe der DB-Cluster-Operationen auf der Konsole oder mithilfe des SDK aktualisieren. Mit dem folgenden CLI-Befehl wird ein geeignetes Cluster sofort aktualisiert: Für Linux, OS X oder 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 ``` Für 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 ``` Statt `--apply-immediately` können Sie `--no-apply-immediately` angeben. Um ein Hauptversions-Upgrade durchzuführen, ist der Parameter erforderlich. allow-major-version-upgrade Stellen Sie außerdem sicher, dass Sie die Engine-Version angeben, da Ihre Engine sonst möglicherweise auf eine andere Version aktualisiert wird. Wenn Ihr Cluster eine benutzerdefinierte Cluster-Parametergruppe verwendet, müssen Sie diesen Parameter einschließen, um ihn zu anzugeben: ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` Ebenso sollte für Instances im Cluster, die eine benutzerdefinierte DB-Parametergruppe verwenden, dieser Parameter eingeschlossen werden, um ihn zu spezifizieren: ``` --db-instance-parameter-group-name (name of the custom instance parameter group) ``` ### Testen Sie immer vor dem Upgrade Wenn eine neue Haupt- oder Nebenversion der Neptune-Engine veröffentlicht wird, testen Sie Ihre Neptune-Anwendungen immer zuerst dafür, bevor Sie sie dazu aktualisieren. Selbst ein Nebenversions-Upgrade könnte neue Features oder Verhaltensweisen einführen, die sich auf Ihren Code auswirken können. Vergleichen Sie zunächst die Seiten mit den Versionshinweisen Ihrer aktuellen Version mit denen der Zielversion, um festzustellen, ob es Änderungen an den Versionen der Abfragesprache oder andere wichtige Änderungen geben wird. Die beste Methode, eine neue Version zu testen, bevor Sie Ihren Produktions-DB-Cluster aktualisieren, besteht darin, den Produktions-Cluster zu klonen, so dass auf dem Klon die neue Engine-Version ausgeführt wird. Sie können dann Abfragen auf dem Klon ausführen, ohne dass der Produktions-DB-Cluster davon betroffen wird. ### Erstellen Sie vor einem Upgrade immer einen manuellen Snapshot Bevor Sie ein Upgrade durchführen, wird dringend empfohlen, immer einen manuellen Snapshot Ihres DB-Clusters zu erstellen. Ein automatischer Snapshot bietet nur kurzfristigen Schutz, wohingegen ein manueller Snapshot verfügbar bleibt, bis Sie ihn explizit löschen. In bestimmten Fällen erstellt Neptune im Rahmen des Upgrade-Prozesses einen manuellen Snapshot für Sie, aber Sie sollten sich nicht darauf verlassen und in jedem Fall Ihren eigenen manuellen Snapshot erstellen. Wenn Sie sicher sind, dass Sie Ihren DB-Cluster nicht auf den Zustand vor dem Upgrade zurücksetzen müssen, können Sie den manuellen Snapshot, den Sie selbst erstellt haben, sowie den manuellen Snapshot, den Neptune möglicherweise erstellt hat, explizit löschen. Wenn Neptune einen manuellen Snapshot erstellt, hat dieser einen Namen, der mit `preupgrade` beginnt, gefolgt vom Namen Ihres DB-Clusters, der Quell-Engine-Version, der Ziel-Engine-Version und dem Datum. **Anmerkung** Wenn Sie versuchen, ein Upgrade durchzuführen, während [eine ausstehende Aktion ausgeführt wird](manage-console-maintaining), kann ein Fehler wie der folgende auftreten: ``` 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. ``` Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann. Weitere Informationen zum Upgraden Ihrer Engine-Version finden Sie unter [Warten eines Amazon-Neptune-DB-Clusters](cluster-maintenance.md). Wenn Sie Fragen oder Bedenken haben, steht Ihnen das AWS Support-Team in den Community-Foren und über den [AWS Premium-Support](https://aws.amazon.com/support) zur Verfügung.