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.1.0 (08.03.2023) Ab dem 08.03.2023 wird die Engine-Version 1.2.1.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.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). ## Nachfolgende Patch-Veröffentlichungen für dieses Version + [Release: 1.2.1.0.R2 (02.05.2023)](engine-releases-1.2.1.0.R2.md) + [Release: 1.2.1.0.R3 (13.06.2023)](engine-releases-1.2.1.0.R3.md) + [Release: 1.2.1.0.R4 (10.08.2023)](engine-releases-1.2.1.0.R4.md) + [Release: 1.2.1.0.R5 (02.09.2023)](engine-releases-1.2.1.0.R5.md) + [Release: 1.2.1.0.R6 (12.09.2023)](engine-releases-1.2.1.0.R6.md) + [Release: 1.2.1.0.R7 (06.10.2023)](engine-releases-1.2.1.0.R7.md) ## Neue Features in dieser Engine-Version + Unterstützung für [TinkerPop 3.6.2](https://tinkerpop.apache.org/docs/3.6.2-SNAPSHOT/dev/provider/) hinzugefügt, wodurch viele neue Gremlin-Funktionen wie die neuen Schritte`mergeV()`, `mergeE()``element()`, und hinzugefügt werden. `fail()` Die Schritte `mergeV()` und `mergeE()` sind von besonderer Bedeutung, da sie eine lang erwartete deklarative Option für die Ausführung von upsert-ähnlichen Operationen bieten, was bestehende Codemuster erheblich vereinfachen und Gremlin lesbarer machen sollte. In der Version 3.6.x wurden außerdem Regex-Prädikate, eine neue Überladung des `property()`-Schrittes, die eine `Map` annimmt, und eine umfassende Überarbeitung des `by()`-Modulationsverhaltens hinzugefügt, das in allen Schritten, die es verwenden, viel konsistenter ist. Im [TinkerPopÄnderungsprotokoll](https://github.com/apache/tinkerpop/blob/3.6.0/CHANGELOG.asciidoc#release-3-6-0) und [auf der Upgrade-Seite](https://tinkerpop.apache.org/docs/current/upgrade/) finden Sie Informationen zu den Änderungen in Version 3.6 und zu den Dingen, die Sie beim Upgrade beachten sollten. Wenn Sie `fold().coalesce(unfold(), )` für bedingte Einfügungen arbeiten, empfehlen wir Ihnen, auf die neue `mergeV/E()` Syntax zu migrieren, die [hier](https://tinkerpop.apache.org/docs/3.6.0/reference/#mergevertex-step) und [hier](https://tinkerpop.apache.org/docs/3.6.0/reference/#mergeedge-step) beschrieben wird. Neptune verwendet ein engeres Sperrmuster für `Merge` als für`Coalesce`, wodurch die Anzahl gleichzeitiger Modifikationsausnahmen () reduziert werden kann. CMEs Weitere Informationen zu den neuen Funktionen in dieser TinkerPop Version finden Sie in Stephen Mallettes Blog [Exploring new features of Apache TinkerPop 3.6.x in](https://aws.amazon.com/blogs/database/exploring-new-features-of-apache-tinkerpop-3-6-x-in-amazon-neptune/) Amazon Neptune. + Es wurde Unterstützung für [R6i-Instance-Typen](https://aws.amazon.com/ec2/instance-types/r6i/) hinzugefügt, die auf skalierbaren Intel-Xeon-Prozessoren der 3. Generation basieren. Diese eignen sich ideal für speicherintensive Workloads und bieten bis zu 15% mehr compute/price Leistung und bis zu 20% mehr Speicherbandbreite pro vCPU als vergleichbare R5-Instance-Typen. + [API-Endpunkte für Graphzusammenfassungen](neptune-graph-summary.md) wurden sowohl für Eigenschaftsgraphen als auch für RDF-Graphen hinzugefügt, sodass Sie schnell einen zusammenfassenden Bericht über Ihren Graphen erhalten können. Bei Eigenschaftsgraphen (PG-Graphen) bietet die Graphübersichts-API eine schreibgeschützte Liste von Knoten- und Edgebezeichnungen und Eigenschaftsschlüsseln sowie die Anzahl der Knoten, Edges und Eigenschaften. Für RDF-Graphenbietet sie eine Liste von Klassen und Prädikatschlüsseln sowie die Anzahl der Quadrate, Subjekte und Prädikate. Die folgenden Änderungen gingen mit der neuen API für die Zusammenfassung von Graphen einher: + Eine neue Datenebenenaktion wurde hinzugefügt. [GetGraphSummary](iam-dp-actions.md#getgraphsummary) + Es wurde ein neuer `rdf/statistics`-Endpunkt hinzugefügt, der den `sparql/statistics`-Endpunkt ersetzt, der jetzt veraltet ist. + Der Name des `summary`-Felds in der Statistikstatusantwort wurde zu `signatureInfo` geändert, um es nicht mit den zusammenfassenden Informationen des Graphen zu verwechseln. Frühere Engine-Versionen werden weiterhin `summary` in der JSON-Antwort verwenden. + Die Genauigkeit des `date`-Felds in der Statistikstatusantwort wurde von Minute auf Millisekunde geändert. Das vorherige Format lautete `2020-05-07T23:13Z` (Minutengenauigkeit), das neue Format ist `2023-01-24T00:47:43.319Z` (Millisekundengenauigkeit). Beide sind ISO 8601-konform, aber diese Änderung kann den vorhandenen Code beschädigen, je nachdem, wie das Datum analysiert wird. + In der Workbench wurde ein neuer [`%statistics`](notebooks-magics.md#notebooks-line-magics-statistics)-Line Magic hinzugefügt, mit dem Sie Statistiken der DFE-Engine abrufen können. + In der Workbench wurde ein neuer [`%summary`](notebooks-magics.md#notebooks-line-magics-summary)-Line Magic hinzugefügt, mit dem Sie Informationen zur Graphzusammenfassung abrufen können. + Es wurde eine [Protokollierung für langsame Abfragen](slow-query-logs.md) hinzugefügt, um Abfragen zu protokollieren, deren Ausführung länger dauert als ein bestimmter Schwellenwert. Sie aktivieren und steuern die Protokollierung langsamer Abfragen mithilfe der beiden neuen dynamischen Parameter [neptune\$1enable\$1slow\$1query\$1log](parameters.md#parameters-db-cluster-parameters-neptune_enable_slow_query_log) und [neptune\$1slow\$1query\$1log\$1threshold](parameters.md#parameters-db-cluster-parameters-neptune_slow_query_log_threshold). + Unterstützung für zwei [dynamische Parameter](parameter-groups.md) wurde hinzugefügt, nämlich die neuen Cluster-Parameter [neptune\$1enable\$1slow\$1query\$1log](parameters.md#parameters-db-cluster-parameters-neptune_enable_slow_query_log) und [neptune\$1slow\$1query\$1log\$1threshold](parameters.md#parameters-db-cluster-parameters-neptune_slow_query_log_threshold). Wenn Sie einen dynamischen Parameter ändern, wird dieser Schritt sofort wirksam, ohne dass ein Neustart der Instance erforderlich ist. + Es wurde eine Neptun-spezifische OpenCypher [removeKeyFromMap ()](access-graph-opencypher-extensions.md#opencypher-compliance-removeKeyFromMap-function) -Funktion hinzugefügt, die einen bestimmten Schlüssel aus einer Map entfernt und die resultierende neue Map zurückgibt. ## Verbesserungen in dieser Engine-Version + Die Unterstützung von Gremlin DFE wurde auf `limit`-Schritte mit lokalem Geltungsbereich erweitert. + `by()`-Modulationsunterstützung für `DedupGlobalStep` für die Gremlin DFE-Engine hinzugefügt. + DFE-Unterstützung für Gremlin `SelectStep` und `SelectOneStep` hinzugefügt. + Leistungsverbesserungen und Korrekturkorrekturen für verschiedene Gremlin-Operatoren, darunter `repeat`, `coalesce`, `store` und `aggregate`. + Verbesserte Leistung von openCypher-Abfragen mit `MERGE` und `OPTIONAL MATCH`. + Verbesserte Leistung von openCypher-Abfragen, die eine Liste `UNWIND` von Zuordnungen mit Literalwerten beinhalten. + 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 ``` + Es wurde die Möglichkeit hinzugefügt, den Basis-IRI für SPARQL-Abfragen mithilfe der BASE-Anweisung anzugeben (siehe [Standard-Basis-IRI für Abfragen und Updates](feature-sparql-compliance.md#opencypher-compliance-default-iri)). + Die Wartezeit bei der Ladeverarbeitung für Gremlin- und openCypher-Only-Edge-Massenladungen wurde verkürzt. + Massenladungen wurden asynchron fortgesetzt, wenn Neptune neu gestartet wird, um lange Wartezeiten aufgrund von Amazon S3-Verbindungsproblemen zu vermeiden, bevor Wiederaufnahmeversuche fehlschlagen. + Verbesserte Handhabung von SPARQL DESCRIBE-Abfragen, bei denen der [DescribeMode-Abfragehinweis](sparql-query-hints-for-describe.md#sparql-query-hints-describeMode) auf `"CBD"` (kurze, begrenzte Beschreibung) gesetzt ist und die eine große Anzahl leerer Knoten beinhalten. ## 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. + Es wurde ein openCypher-Fehler im Listenverständnis behoben, der anstelle der für die Listenelemente angegebenen Werte einen Nullwert erzeugte. + Es wurde ein openCypher-Fehler behoben, bei dem Bytewerte nicht korrekt serialisiert wurden. + Es wurde ein Gremlin-Fehler in `UnionStep` behoben, der auftrat, wenn es sich bei der Eingabe um eine Edge handelte, die zu einem Scheitelpunkt innerhalb eines untergeordneten Traversalen führte. + Es wurde ein Gremlin-Fehler behoben, der dazu führte, dass ein Schritt-Label, das mit einem Schritt verknüpft war, nicht korrekt auf den letzten Schritt jeder untergeordneten Traversale übertragen wurde. + Es wurde ein Gremlin-Fehler für den `dedup`-Schritt behoben, bei dem Labels auf einen Schritt folgten, bei dem die an den `repeat`-Schritt angehängten Beschriftungen nicht für die weitere Verwendung in `dedup`-Abfragen verfügbar waren. + Es wurde ein Gremlin-Fehler behoben, bei dem die Übersetzung des `repeat`-Schritts innerhalb eines `union`-Schritts aufgrund eines internen Fehlers fehlschlug. + Behebung von Gremlin-Korrektheitsproblemen bei DFE-Abfragen mit `limit` als untergeordneter Traversal von Nicht-Union-Schritten durch Rückgriff auf Tinkerpop. Abfragen in einem Formular wie diesem sind betroffen: ``` g.withSideEffect('Neptune#useDFE', true).V().as("a").select("a").by(out().limit(1)) ``` + Es wurde ein SPARQL-Fehler behoben, bei dem `SPARQL GRAPH`-Muster den durch eine `FROM NAMED`-Klausel bereitgestellten Datensatz nicht berücksichtigten. + Es wurde ein SPARQL-Fehler behoben, bei dem SPARQL `DESCRIBE` mit einigen `FROM` and/or `FROM NAMED` Klauseln Daten aus dem Standarddiagramm nicht immer korrekt verwendete und manchmal eine Ausnahme auslöste. Siehe [Verhalten von SPARQL DESCRIBE in Bezug auf das Standarddiagramm](sparql-default-describe.md). + Es wurde ein SPARQL-Fehler behoben, sodass die richtige Ausnahmemeldung zurückgegeben wurde, wenn Nullzeichen zurückgewiesen wurden. + Es wurde ein [SPARQL-Erklärungsfehler](sparql-explain.md) behoben, der Pläne betraf, die einen Operator enthielten. [PipelinedHashIndexJoin](sparql-explain-operators.md#sparql-explain-operator-pipeline-hash-index-join) + Es wurde ein Fehler behoben, der dazu führte, dass ein interner Fehler ausgelöst wurde, wenn eine Abfrage, die einen konstanten Wert zurückgibt, gesendet wurde. + Es wurde ein Problem mit der Deadlock-Detektorlogik behoben, das gelegentlich dazu führte, dass die Engine nicht reagierte. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.1.0 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist: + *Die älteste unterstützte Version von Gremlin:* `3.6.2` + *Die neueste unterstützte Version von Gremlin:* `3.6.2` + *openCypher-Version:* `Neptune-9.0.20190305-1.1` + *SPARQL-Version:* `1.1` ## Upgrade-Pfade zum Engine-Release 1.2.1.0 Sie können ein manuelles Upgrade auf diese Version von jedem früheren Neptune-Engine-Release ab [1.1.0.0](engine-releases-1.1.0.0.md) durchführen. **Anmerkung** Ab [Engine-Version 1.2.0.0](engine-releases-1.2.0.0.md) `1.2.0.0` müssen alle benutzerdefinierten Parametergruppen und benutzerdefinierten Cluster-Parametergruppen, die Sie mit früheren Engine-Versionen verwendet haben, jetzt mithilfe der Parametergruppenfamilie `neptune1.2` neu erstellt werden. In früheren Versionen wurde die Parametergruppenfamilie `neptune1` verwendet, und diese Parametergruppen funktionieren ab Version `1.2.0.0` nicht mehr. Weitere Informationen finden Sie unter [Amazon-Neptune-Parametergruppen](parameter-groups.md). Es wird kein automatisches Upgrade auf diesen großen Versions-Release durchgeführt. ## Upgrade auf diesen Release Amazon Neptune 1.2.1.0 ist jetzt allgemein verfügbar. 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.1.0 \ 4. --apply-immediately ``` Für Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.1.0 ^ 4. --apply-immediately ``` Updates werden auf alle Instances in einem DB-Cluster gleichzeitig angewendet. Ein Update erfordert einen Datenbankneustart auf diesen Instances. Daher kommt es zu einer Ausfallzeit von 20–30 Sekunden bis zu mehreren Minuten. Anschließend können Sie die Nutzung Ihres DB-Clusters fortsetzen. ### 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.1.0.R7 (06.10.2023) Seit dem 06.10.2023 wird die Engine-Version 1.2.1.0.R7 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). ## In diesem Engine-Version behobene Fehler + Es wurde ein Fehler behoben, bei dem in einigen Fällen eine fehlgeschlagene Transaktion nicht korrekt abgeschlossen wurde. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.1.0.R7 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist: + *Die älteste unterstützte Version von Gremlin:* `3.6.2` + *Die neueste unterstützte Version von Gremlin:* `3.6.2` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade auf diesen Release Amazon Neptune 1.2.1.0.R7 ist jetzt allgemein verfügbar. 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.1.0 \ 4. --apply-immediately ``` Für Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.1.0 ^ 4. --apply-immediately ``` Updates werden auf alle Instances in einem DB-Cluster gleichzeitig angewendet. Ein Update erfordert einen Datenbankneustart auf diesen Instances. Daher kommt es zu einer Ausfallzeit von 20–30 Sekunden bis zu mehreren Minuten. Anschließend können Sie die Nutzung Ihres DB-Clusters fortsetzen. ### 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.1.0.R6 (12.09.2023) Ab dem 12.09.2023 wird die Engine-Version 1.2.1.0.R6 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). ## Neue Features in dieser Engine-Version + Die [Neptune-Daten-API](data-api.md) wurde veröffentlicht. Die Amazon Neptune-Daten-API bietet SDK-Unterstützung für das Laden von Daten, das Ausführen von Abfragen, das Abrufen von Informationen über die Daten und das Ausführen von Machine-Learning-Operationen. Sie unterstützt die Abfragesprachen Gremlin und openCypher in Neptune und ist in allen SDK-Sprachen verfügbar. Sie signiert automatisch API-Anfragen und vereinfacht die Integration von Neptune in Anwendungen erheblich. ## In diesem Engine-Version behobene Fehler + Es wurde ein Fehler behoben, der bei hoher Auslastung zu CPU-Spitzen führen konnte, wenn Slow Query-Protokolle aktiviert waren. + Es wurde ein Gremlin-Fehler behoben, durch den beim Hinzufügen einer Edge und ihrer Eigenschaften gefolgt von `inV()` oder `outV()` ein `InternalFailureException` ausgelöst wurde. + Es wurden mehrere Probleme mit der IAM-Rollenverkettung behoben, die in einigen Fällen zu einer verminderten Massenladerleistung führten. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.1.0.R6 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist: + *Die älteste unterstützte Version von Gremlin:* `3.6.2` + *Die neueste unterstützte Version von Gremlin:* `3.6.2` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade auf diesen Release Amazon Neptune 1.2.1.0.R6 ist jetzt allgemein verfügbar. 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.1.0 \ 4. --apply-immediately ``` Für Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.1.0 ^ 4. --apply-immediately ``` Updates werden auf alle Instances in einem DB-Cluster gleichzeitig angewendet. Ein Update erfordert einen Datenbankneustart auf diesen Instances. Daher kommt es zu einer Ausfallzeit von 20–30 Sekunden bis zu mehreren Minuten. Anschließend können Sie die Nutzung Ihres DB-Clusters fortsetzen. ### 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.1.0.R5 (2023-09-02) Ab dem 02.09.2023 wird die Engine-Version 1.2.1.0.R5 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). ## Neue Features in dieser Engine-Version + Die [Neptune-Daten-API](data-api.md) wurde veröffentlicht. Die Amazon Neptune-Daten-API bietet SDK-Unterstützung für das Laden von Daten, das Ausführen von Abfragen, das Abrufen von Informationen über die Daten und das Ausführen von Machine-Learning-Operationen. Sie unterstützt die Abfragesprachen Gremlin und openCypher in Neptune und ist in allen SDK-Sprachen verfügbar. Sie signiert automatisch API-Anfragen und vereinfacht die Integration von Neptune in Anwendungen erheblich. ## In diesem Engine-Version behobene Fehler + Es wurde ein Gremlin-Fehler behoben, durch den beim Hinzufügen einer Edge und ihrer Eigenschaften gefolgt von `inV()` oder `outV()` ein `InternalFailureException` ausgelöst wurde. + Es wurden mehrere Probleme mit der IAM-Rollenverkettung behoben, die in einigen Fällen zu einer verminderten Massenladerleistung führten. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.1.0.R5 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist: + *Die älteste unterstützte Version von Gremlin:* `3.6.2` + *Die neueste unterstützte Version von Gremlin:* `3.6.2` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade auf diesen Release Amazon Neptune 1.2.1.0.R5 ist jetzt allgemein verfügbar. 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.1.0 \ 4. --apply-immediately ``` Für Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.1.0 ^ 4. --apply-immediately ``` Updates werden auf alle Instances in einem DB-Cluster gleichzeitig angewendet. Ein Update erfordert einen Datenbankneustart auf diesen Instances. Daher kommt es zu einer Ausfallzeit von 20–30 Sekunden bis zu mehreren Minuten. Anschließend können Sie die Nutzung Ihres DB-Clusters fortsetzen. ### 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.1.0.R4 (2023-08-10) Ab dem 10.08.2023 wird die Engine-Version 1.2.1.0.R4 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist. **Wichtig** Die in dieser Engine-Version eingeführten Änderungen können in einigen Fällen dazu führen, dass Sie eine verringerte Leistung beim Laden von Massenladevorgängen feststellen. Aus diesem Grund wurden die Upgrades dieser Version vorübergehend ausgesetzt, bis das Problem behoben 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 + [GraphSON-1.0](https://tinkerpop.apache.org/docs/3.4.1/dev/io/#graphson)-Unterstützung für Gremlin hinzugefügt. Um GraphSON-1.0 zu verwenden, passieren Sie `Accept header` mit einem Wert von: ``` application/vnd.gremlin-v1.0+json;types=false ``` ## In diesem Engine-Version behobene Fehler + 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 openCypher-Fehler bei der Transaktionsverarbeitung von Bolt behoben. + Es wurde ein Parallelitätsproblem auf der Speicherebene behoben, das zu einem Absturz führen konnte. + Es wurde ein Fehler in Protokollen für langsame Abfragen behoben, um sicherzustellen, dass sie nicht aktiv sind, wenn sie deaktiviert sind. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.1.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.6.2` + *Die neueste unterstützte Version von Gremlin:* `3.6.5` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade-Pfade zum Engine-Release 1.2.1.0.R4 ## Upgrade auf diesen Release Amazon Neptune 1.2.1.0.R4 ist jetzt allgemein verfügbar. 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.1.0 \ 4. --apply-immediately ``` Für Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.1.0 ^ 4. --apply-immediately ``` Updates werden auf alle Instances in einem DB-Cluster gleichzeitig angewendet. Ein Update erfordert einen Datenbankneustart auf diesen Instances. Daher kommt es zu einer Ausfallzeit von 20–30 Sekunden bis zu mehreren Minuten. Anschließend können Sie die Nutzung Ihres DB-Clusters fortsetzen. ### 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.1.0.R3 (13.06.2023) Ab dem 13.06.2023 wird die Engine-Version 1.2.1.0.R3 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist. **Wichtig** Die in dieser Engine-Version eingeführten Änderungen können in einigen Fällen dazu führen, dass Sie eine verringerte Leistung beim Laden von Massenladevorgängen feststellen. Aus diesem Grund wurden die Upgrades dieser Version vorübergehend ausgesetzt, bis das Problem behoben 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). ## Neue Features in dieser Engine-Version + Unterstützung für kontoübergreifendes Massenladen mithilfe der [IAM-Rollenverkettung](bulk-load-tutorial-chain-roles.md) wurde hinzugefügt. ## Verbesserungen in dieser Engine-Version + Der `fail()`-Schritt von Gremlin wurde verbessert, um die erzeugte Ausnahme von einer generischen Ausnahme zu unterscheiden `InternalFailureException` und sicherzustellen, dass alle vom Benutzer bereitgestellten Nachrichten an den Aufrufer zurückgesendet wurden. + Die Optimierungen der Gremlin-Abfrage-Engine für `store`, `aggregate`, `cap`, `limit` und `hasLabel` wurden verbessert. + Unterstützung für trignometrische Features von openCypher hinzugefügt: + `acos()` + `asin()` + `atan()` + `atan2()` + `cos()` + `cot()` + `degrees()` + `pi()` + `radians()` + `sin()` + `tan()` + Unterstützung für mehrere Aggregationsfunktionen von openCypher hinzugefügt: + `percentileDisc()` + `stDev()` + Unterstützung für die openCypher-`epochmillis()`-Funktion hinzugefügt, die ein `datetime` in `epochmillis` umwandelt. Zum Beispiel: ``` MATCH (n) RETURN epochMillis(n.someDateTime) 1698972364782 ``` + Unterstützung für den openCypher-Operator modulo (`%`) hinzugefügt. + Unterstützung für das openCypher Static Debug-Erklärungs-Tool hinzugefügt. + Unterstützung für die openCypher-`randomUUID()`-Funktion hinzugefügt. + Verbesserung der Leistung von openCypher: + Der Parser und der Abfrageplaner wurden verbessert. + Verbesserung der CPU-Auslastung in der DFE-Engine. + Die Leistung von Abfragen mit mehreren Aktualisierungsklauseln, die dieselben Variablen wiederverwenden, wurde verbessert. Beispiele sind: ``` MERGE (n {name: 'John'}) or MERGE (m {name: 'Jim'}) or MERGE (n)-[:knows {since: 2023}]→(m) ``` + Optimierte Abfragepläne für Multi-Hop-Abfragemuster wie: ``` MATCH (n)-->()-->()-->(m) RETURN n m ``` + Die Leistung der Listen- und Map-Injection durch parametrisierte Abfragen wurde verbessert. Zum Beispiel: ``` UNWIND $idList as id MATCH (n {`~id`: id}) RETURN n.name ``` + Die Ausführung von Abfragen mit `WITH` wurde verbessert, indem es zu einer geeigneten Barriere gemacht wurde. + Optimiert, um eine redundante Materialisierung von Werten in `Unfold` und Aggregationsfunktionen zu vermeiden. + Die Leistung von SPARQL-Abfragen, die eine große Anzahl statischer Eingaben in der `VALUES`-Klausel enthalten, wie z. B.: ``` SELECT ?n WHERE { VALUES (?name) { ("John") ("Jim") ... many values ... } ?n a ?n_type . ?n ?name . } ``` + Verbesserung der SPARQL CBD-Abfrageleistung. ## In diesem Engine-Version behobene Fehler + Es wurde ein Gremlin-Fehler behoben, bei dem lange Abfragen mit tiefer Verschachtelung zu einer hohen CPU-Auslastung und Abfrage-Timeouts während der Abfrageplanungsphase führten. + Es wurde ein Gremlin-Fehler behoben, durch den bei Verwendung von `mergeV` oder `mergeE` ein ungültiges `NullPointerException` ausgegeben werden konnte. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.1.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.6.2` + *Die neueste unterstützte Version von Gremlin:* `3.6.2` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade-Pfade zum Engine-Release 1.2.1.0.R3 ## Upgrade auf diesen Release Amazon Neptune 1.2.1.0.R3 ist jetzt allgemein verfügbar. 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.1.0 \ 4. --apply-immediately ``` Für Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.1.0 ^ 4. --apply-immediately ``` Updates werden auf alle Instances in einem DB-Cluster gleichzeitig angewendet. Ein Update erfordert einen Datenbankneustart auf diesen Instances. Daher kommt es zu einer Ausfallzeit von 20–30 Sekunden bis zu mehreren Minuten. Anschließend können Sie die Nutzung Ihres DB-Clusters fortsetzen. ### 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.1.0.R2 (02.05.2023) Ab dem 02.05.2023 wird die Engine-Version 1.2.1.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 + 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. + Unterstützung für mehrere Labels für Gremlin `mergeV()` und `mergeE()` hinzugefügt. ## In diesem Engine-Version behobene Fehler + Es wurde ein openCypher-Fehler behoben, durch den Aktualisierungs- und Rückgabeanfragen `orderBy`, `limit` oder `skip` nicht richtig behandelt haben. + 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 behoben, bei dem langsame Abfrageprotokolle nicht die korrekten Abfragezeiten enthielten. + Es wurde ein Gremlin-Fehler behoben, durch den ein Transaktionsleck auftreten konnte, wenn eine Abfrage mit `GroupCountStep` als Zeichenfolge gesendet wurde. + Es wurde ein Gremlin-Fehler behoben, bei dem WebSocket Abfragen fehlschlugen, wenn langsame Abfrageprotokolle aktiviert waren. + Es wurde ein Gremlin-Fehler behoben, bei dem Storage-Counter-Debug-Logs in den langsamen Abfrageprotokollen für Anfragen fehlten. WebSocket + Es wurden mehrere Gremlin-Fehler mit `mergeV()` und `mergeE()` behoben. + Es wurde ein SPARQL-Fehler behoben, bei dem die Kosten für benannte Graph-Abfragen falsch geschätzt wurden, was zu suboptimalen Abfrageplänen und Fehlern führte. out-of-memory + Es wurde ein Fehler behoben, der sich auf die Autorisierung von Gremlin- und openCypher-Abfragen auf einem IAM-fähigen Cluster auswirkte. ## In dieser Version unterstützte Versionen in Abfragesprache Bevor Sie einen DB-Cluster auf Version 1.2.1.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.6.2` + *Die neueste unterstützte Version von Gremlin:* `3.6.2` + *openCypher-Version:* `Neptune-9.0.20190305-1.0` + *SPARQL-Version:* `1.1` ## Upgrade-Pfade zum Engine-Release 1.2.1.0.R2 ## Upgrade auf diesen Release Amazon Neptune 1.2.1.0.R2 ist jetzt allgemein verfügbar. 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.1.0 \ 4. --apply-immediately ``` Für Windows: ``` 1. aws neptune modify-db-cluster ^ 2. --db-cluster-identifier (your-neptune-cluster) ^ 3. --engine-version 1.2.1.0 ^ 4. --apply-immediately ``` Updates werden auf alle Instances in einem DB-Cluster gleichzeitig angewendet. Ein Update erfordert einen Datenbankneustart auf diesen Instances. Daher kommt es zu einer Ausfallzeit von 20–30 Sekunden bis zu mehreren Minuten. Anschließend können Sie die Nutzung Ihres DB-Clusters fortsetzen. ### 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.