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.1.1.0 (19.04.2022)
Ab dem 19.04.2022 wird die Engine-Version 1.1.1.0 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.
**Wichtig**
**Ein Upgrade von einer früheren Version auf diese Engine-Version löst `1.1.0.0` auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Um das Upgrade erfolgreich abzuschließen, muss für jedes Subnetz in jeder Availability Zone (AZ) mindestens eine IP-Adresse pro Neptune-Instance verfügbar sein. Wenn es beispielsweise eine Writer-Instance und zwei Reader-Instances in Subnetz 1 und zwei Reader-Instances in Subnetz 2 gibt, muss Subnetz 1 mindestens 3 freie IP-Adressen und Subnetz 2 mindestens 2 freie IP-Adressen haben, bevor das Upgrade gestartet wird.
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für einige Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Nachfolgende Patch-Veröffentlichungen für dieses Version
+ [Wartungs-Release: 1.1.1.0.R2 (16.05.2022)](engine-releases-1.1.1.0.R2.md)
+ [Release: 1.1.1.0.R3 (07.06.2022)](engine-releases-1.1.1.0.R3.md)
+ [Release: 1.1.1.0.R4 (23.06.2022)](engine-releases-1.1.1.0.R4.md)
+ [Release: 1.1.1.0.R5 (21.07.2022)](engine-releases-1.1.1.0.R5.md)
+ [Release: 1.1.1.0.R6 (23.09.2022)](engine-releases-1.1.1.0.R6.md)
+ [Release: 1.1.1.0.R7 (23.01.2023)](engine-releases-1.1.1.0.R7.md)
## Neue Features in dieser Engine-Version
+ Die [openCypher-Abfragesprache](access-graph-opencypher.md) ist jetzt allgemein für den produktiven Einsatz verfügbar.
**Warnung**
In dieser Version gibt es eine signifikante Änderung für Code, der openCypher mit IAM-Authentifizierung verwendet. In der Neptune-Vorschau für openCypher enthielt der Host-String in der IAM-Signatur das Protokoll, zum Beispiel `bolt://`, wie folgt:
```
"Host":"bolt://(host URL):(port)"
```
Ab dieser Engine-Version muss das Protokoll weggelassen werden:
```
"Host":"(host URL):(port)"
```
Beispiele finden Sie unter [Verwenden des Bolt-Protokolls](access-graph-opencypher-bolt.md).
+ Unterstützung für hinzugefügt TinkerPop `3.5.2`. Zu den [Änderungen in dieser Version](https://github.com/apache/tinkerpop/blob/3.5.2/CHANGELOG.asciidoc#release-3-5-2) gehören die Unterstützung für Remote-Transaktionen und Bytecode-Unterstützung für Sitzungen (Unter Verwendung von [https://tinkerpop.apache.org/docs/current/reference/#transactions](https://tinkerpop.apache.org/docs/current/reference/#transactions)) sowie die Hinzufügung des `datetime()`-Features zur Gremlin-Sprache.
**Warnung**
In TinkerPop 3.5.0, 3.5.1 und 3.5.2 wurden mehrere wichtige Änderungen eingeführt, die sich auf Ihren Gremlin-Code auswirken können. Zum Beispiel funktioniert es nicht mehr, [Traversals, die von a erzeugt wurden, GraphTraversalSource als Kinder wie folgt zu verwenden](https://issues.apache.org/jira/browse/TINKERPOP-2361):. `g.V().union(identity(), g.V())`
Verwenden Sie jetzt stattdessen eine anonyme Traversal wie folgt: `g.V().union(identity(), __.V())`.
+ Unterstützung für [AWS globale Bedingungsschlüssel](iam-data-condition-keys.md#iam-data-global-condition-keys) hinzugefügt, die Sie in [IAM-Datenzugriffsrichtlinien](iam-admin-policies.md) verwenden können, die den Zugriff auf Daten steuern, die in Neptune, einem Neptune-DB-Cluster, gespeichert sind.
+ Die [Neptune DFE-Abfrage-Engine](neptune-dfe-engine.md) ist jetzt allgemein für den Produktionseinsatz mit der openCypher-Abfragesprache verfügbar, aber noch nicht für Gremlin- und SPARQL-Abfragen. Sie aktivieren sie jetzt mit ihrem eigenen [neptune\$1dfe\$1query\$1engine](parameters.md#parameters-instance-parameters-neptune_dfe_query_engine)-Instance-Parameter und nicht mit dem Lab-Modus-Parameter.
## Verbesserungen in dieser Engine-Version
+ [openCypher](access-graph-opencypher.md) wurde um neue Features erweitert, wie z. B. Unterstützung parametrisierter Abfragen, AST-Zwischenspeicherung (Abstract Syntax Tree) für parametrisierte Abfragen, Verbesserungen bei Pfaden mit variabler Länge (VLP) sowie neue Operatoren und Klauseln. Siehe [Einhaltung der OpenCypher-Spezifikationen in Amazon Neptune](feature-opencypher-compliance.md) für Informationen zum aktuellen Stand der Sprachunterstützung.
+ openCypher wurde für einfache Lese- und Schreib-Workloads erheblich verbessert, was zu einem höheren Durchsatz im Vergleich zu Version 1.1.0.0 führte.
+ Die bidirektionalen openCypher-Einschränkungen und die Tiefenbeschränkungen für Pfade variabler Länge wurden entfernt.
+ Die Unterstützung für Gremlin `within`- und `without`-Prädikate in der DFE-Engine wurde abgeschlossen, einschließlich Fällen, in denen sie mit anderen Prädikatoperatoren kombiniert werden. Zum Beispiel:
```
g.V().has('age', within(12, 15, 18).or(gt(30)))
```
+ Erweiterte Unterstützung in der DFE-Engine für den `order` Gremlin-Schritt, wenn der Gültigkeitsbereich global ist (d. h. nicht `order(local)`) und wenn keine `by()` Modulatoren verwendet werden. Zum Beispiel hätte diese Abfrage jetzt DFE-Unterstützung:
```
g.V().values("age").order()
```
+ Dem Antwortformat des [Neptune-Streams-Änderungsprotokolls](streams-using-api-reponse.md) wurde ein `isLastOp`-Feld hinzugefügt, um anzuzeigen, dass ein Datensatz die letzte Operation in seiner Transaktion ist.
+ Die Leistung der Audit-Protokollierung wurde deutlich verbessert und die Latenz reduziert, wenn die Audit-Protokollierung aktiviert ist.
+ WebSocket Gremlin-Bytecode und HTTP-Abfragen wurden in Audit-Logs in ein vom Benutzer lesbares Format konvertiert. Abfragen können jetzt direkt aus den Audit-Protokollen kopiert werden, um sie in Neptune-Notebooks und anderswo auszuführen. Beachten Sie, dass diese Änderung des aktuellen Audit-Protokollformats eine bahnbrechende Änderung darstellt.
## In diesem Engine-Version behobene Fehler
+ Es wurde ein seltener Gremlin-Fehler behoben, bei dem keine Ergebnisse zurückgegeben wurden, wenn verschachtelte `filter()`- und `count()`-Schritte kombiniert wurden, wie in der folgenden Abfrage:
```
g.V("1").filter(out("knows")
.filter(in("knows")
.hasId("notExists"))
.count())
```
+ Es wurde ein Gremlin-Fehler behoben, bei dem ein Fehler zurückgegeben wurde, wenn ein Scheitelpunkt verwendet wurde, der in einem Aggregatschritt gespeichert wurde, `to()` oder `from()` bei Durchläufen in Verbindung mit einem `addE`-Schritt. Ein Beispiel für eine solche Abfrage:
```
g.V("id").aggregate("v").out().addE().to(select("v").unfold()))
```
+ Es wurde ein Gremlin-Fehler behoben, bei dem der `not`-Schritt in Ausnahmefällen fehlschlug, wenn die DFE-Engine verwendet wurde. Zum Beispiel:
```
g.V().not(V())
```
+ Es wurde ein Gremlin-Fehler behoben, bei dem `sideEffect`-Werte innerhalb von `to()`- und `from()`-Traversalen nicht verfügbar waren.
+ Es wurde ein Fehler behoben, der gelegentlich dazu führte, dass ein schneller Reset einen Instance-Failover auslöste.
+ Es wurde ein Massenlader-Fehler behoben, bei dem eine fehlgeschlagene Transaktion nicht geschlossen wurde, bevor der nächste Ladejob gestartet wurde.
+ Es wurde ein Massenlader-Fehler behoben, bei dem ein unzureichender Speicherplatz zu einem Systemabsturz führen konnte.
+ Es wurde ein erneuter Versuch hinzugefügt, um einen Massenladerfehler zu beheben, bei dem der Lader nicht lange genug wartete, bis die IAM-Anmeldeinformationen nach einem Failover verfügbar wurden.
+ Es wurde ein Fehler behoben, bei dem der interne Cache für Anmeldeinformationen für Endpunkte, die keine Abfragen waren, wie z. B. den `status`-Endpunkt, nicht ordnungsgemäß gelöscht wurde.
+ Es wurde ein Streams-Fehler behoben, um sicherzustellen, dass die Sequenznummern der Stream-Commits korrekt angeordnet sind.
+ Es wurde ein Fehler behoben, bei dem lang andauernde Verbindungen auf IAM-fähigen Clustern nach weniger als zehn Tagen beendet wurden.
## In dieser Version unterstützte Versionen in Abfragesprache
Bevor Sie einen DB-Cluster auf Version 1.1.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.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.1.1.0
Sie können jeden vorherigen Neptune Engine-Release manuell auf diese Version aktualisieren. Beachten Sie, dass das Upgrade von Versionen vor der Hauptversions-Engine (1.1.0.0) auf diese Version länger dauern wird.
Es wird kein automatisches Upgrade auf diese Version durchgeführt.
## Upgrade auf diesen Release
**Wichtig**
**Ein Upgrade von einer früheren Version auf `1.1.0.0` löst auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für etwa 6 Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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 neptune \
4. --engine-version 1.1.1.0 \
5. --allow-major-version-upgrade \
6. --apply-immediately
```
Für Windows:
```
1. aws neptune modify-db-cluster ^
2. --db-cluster-identifier (your-neptune-cluster) ^
3. --engine neptune ^
4. --engine-version 1.1.1.0 ^
5. --allow-major-version-upgrade ^
6. --apply-immediately
```
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 ein vorheriges 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.1.1.0.R7 (23.01.2023)
Ab dem 23.01.2023 wird die Engine-Version 1.1.1.0.R7 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.
**Wichtig**
**Ein Upgrade von einer früheren Version auf diese Engine-Version löst `1.1.0.0` auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Um das Upgrade erfolgreich abzuschließen, muss für jedes Subnetz in jeder Availability Zone (AZ) mindestens eine IP-Adresse pro Neptune-Instance verfügbar sein. Wenn es beispielsweise eine Writer-Instance und zwei Reader-Instances in Subnetz 1 und zwei Reader-Instances in Subnetz 2 gibt, muss Subnetz 1 mindestens 3 freie IP-Adressen und Subnetz 2 mindestens 2 freie IP-Adressen haben, bevor das Upgrade gestartet wird.
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für einige Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
## Verbesserungen in dieser Engine-Version
+ 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
```
+ 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 eine Anfrage, die HTTP-Keep-Alive verwendete, fälschlicherweise geschlossen werden konnte, wenn sie nach einer fehlgeschlagenen Anfrage eingereicht wurde.
+ Es wurde ein openCypher-Fehler behoben, bei dem der Parametertyp für eine Liste oder eine Liste von Maps nicht immer korrekt interpretiert wurde.
+ Es wurde ein openCypher-Fehler behoben, bei dem Abfragen die Zeichenfolge, `"null"`, anstelle eines Nullwerts in Bolt und SPARQL-JSON zurückgaben.
+ OpenCypher-Fehlercodes und Fehlermeldungen für Abfrage-Timeout-Ausfälle und Fehler wurden behoben. out-of-memory
+ Es wurde ein Gremlin-Fehler behoben, der dazu führte, dass `valueMap()` bei einem `by()`-Traversal in der DFE-Engine nicht optimiert wurde.
+ Es wurde ein Problem mit der Deadlock-Detektorlogik behoben, das gelegentlich dazu führte, dass die Engine nicht reagierte.
+ Es wurde ein Fehler im Auditprotokoll behoben, der dazu führte, dass unnötige Informationen protokolliert wurden und bestimmte Felder in den Protokollen fehlten.
## In dieser Version unterstützte Versionen in Abfragesprache
Bevor Sie einen DB-Cluster auf Version 1.1.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.5.2`
+ *Die neueste unterstützte Version von Gremlin:* `3.5.3`
+ *openCypher-Version:* `Neptune-9.0.20190305-1.0`
+ *SPARQL-Version:* `1.1`
## Upgrade-Pfade zum Engine-Release 1.1.1.0.R7
Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.1.1.0` ausführen.
## Upgrade auf diesen Release
**Wichtig**
**Ein Upgrade von einer früheren Version auf `1.1.0.0` löst auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für etwa 6 Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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.1.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.1.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.1.1.0.R6 (23.09.2022)
Ab dem 23.09.2022 wird die Engine-Version 1.1.1.0.R6 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.
**Wichtig**
**Ein Upgrade von einer früheren Version auf diese Engine-Version löst `1.1.0.0` auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Um das Upgrade erfolgreich abzuschließen, muss für jedes Subnetz in jeder Availability Zone (AZ) mindestens eine IP-Adresse pro Neptune-Instance verfügbar sein. Wenn es beispielsweise eine Writer-Instance und zwei Reader-Instances in Subnetz 1 und zwei Reader-Instances in Subnetz 2 gibt, muss Subnetz 1 mindestens 3 freie IP-Adressen und Subnetz 2 mindestens 2 freie IP-Adressen haben, bevor das Upgrade gestartet wird.
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für einige Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Anmerkung**
In dieser Version gibt es eine signifikante Änderung für Code, der openCypher mit IAM-Authentifizierung verwendet. Bisher enthielt die Hostzeichenfolge in der IAM-Signatur das Protokoll, zum Beispiel `bolt://`, in etwa wie folgt:
```
"Host":"bolt://(host URL):(port)"
```
Ab Engine-Release `1.1.1.0` muss das Protokoll weggelassen werden:
```
"Host":"(host URL):(port)"
```
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.
## In diesem Engine-Version behobene Fehler
+ 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 Fehler bei der Behandlung von SPARQL-Abfragen behoben, die `(NOT) EXISTS` innerhalb einer `OPTIONAL`-Klausel enthalten waren, wodurch in einigen Fällen Abfrageergebnisse fehlten.
+ Es wurde ein Fehler behoben, der den Serverneustart verzögerte, wenn ein Massenladevorgang im Gange war.
+ Es wurde ein Fehler behoben, bei dem eine bidirektionale openCypher-Musterdurchquerung mit variabler Länge und einem Filter für die Beziehungseigenschaft zu einem Fehler führen würde. Ein Beispiel für ein solches Muster mit variabler Länge ist `(n)-[r*1..2]->(m)`.
+ Ein Fehler im Zusammenhang mit der Art und Weise, wie zwischengespeicherte Daten an den Client zurückgesendet wurden, wurde behoben, der in einigen Fällen zu einer unerwartet langen Latenz führte.
## In dieser Version unterstützte Versionen in Abfragesprache
Bevor Sie einen DB-Cluster auf Version 1.1.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.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.1.1.0.R6
Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.1.1.0` ausführen.
## Upgrade auf diesen Release
**Wichtig**
**Ein Upgrade von einer früheren Version auf `1.1.0.0` löst auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für etwa 6 Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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.1.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.1.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.1.1.0.R5 (21.07.2022)
Ab dem 21.07.2022 wird die Engine-Version 1.1.1.0.R5 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.
**Wichtig**
**Ein Upgrade von einer früheren Version auf diese Engine-Version löst `1.1.0.0` auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Um das Upgrade erfolgreich abzuschließen, muss für jedes Subnetz in jeder Availability Zone (AZ) mindestens eine IP-Adresse pro Neptune-Instance verfügbar sein. Wenn es beispielsweise eine Writer-Instance und zwei Reader-Instances in Subnetz 1 und zwei Reader-Instances in Subnetz 2 gibt, muss Subnetz 1 mindestens 3 freie IP-Adressen und Subnetz 2 mindestens 2 freie IP-Adressen haben, bevor das Upgrade gestartet wird.
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für einige Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Anmerkung**
In dieser Version gibt es eine signifikante Änderung für Code, der openCypher mit IAM-Authentifizierung verwendet. Bisher enthielt die Hostzeichenfolge in der IAM-Signatur das Protokoll, zum Beispiel `bolt://`, in etwa wie folgt:
```
"Host":"bolt://(host URL):(port)"
```
Ab Engine-Release `1.1.1.0` muss das Protokoll weggelassen werden:
```
"Host":"(host URL):(port)"
```
Beispiele finden Sie unter [Verwenden des Bolt-Protokolls](access-graph-opencypher-bolt.md).
## Verbesserungen in dieser Engine-Version
+ Es wurden Verbesserungen zur Unterstützung der Deadlock-Erkennung vorgenommen.
## In diesem Engine-Version behobene Fehler
+ Es wurde ein Fehler behoben, der ein fehlerfreies Herunterfahren von DB-Clustern unter bestimmten Bedingungen verhinderte.
## In dieser Version unterstützte Versionen in Abfragesprache
Bevor Sie einen DB-Cluster auf Version 1.1.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.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.1.1.0.R5
Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.1.1.0` ausführen.
## Upgrade auf diesen Release
**Wichtig**
**Ein Upgrade von einer früheren Version auf `1.1.0.0` löst auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für etwa 6 Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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.1.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.1.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.1.1.0.R4 (23.06.2022)
Ab dem 23.06.2022 wird die Engine-Version 1.1.1.0.R4 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.
**Wichtig**
**Ein Upgrade von einer früheren Version auf diese Engine-Version löst `1.1.0.0` auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Um das Upgrade erfolgreich abzuschließen, muss für jedes Subnetz in jeder Availability Zone (AZ) mindestens eine IP-Adresse pro Neptune-Instance verfügbar sein. Wenn es beispielsweise eine Writer-Instance und zwei Reader-Instances in Subnetz 1 und zwei Reader-Instances in Subnetz 2 gibt, muss Subnetz 1 mindestens 3 freie IP-Adressen und Subnetz 2 mindestens 2 freie IP-Adressen haben, bevor das Upgrade gestartet wird.
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für einige Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Anmerkung**
In dieser Version gibt es eine signifikante Änderung für Code, der openCypher mit IAM-Authentifizierung verwendet. Bisher enthielt die Hostzeichenfolge in der IAM-Signatur das Protokoll, zum Beispiel `bolt://`, in etwa wie folgt:
```
"Host":"bolt://(host URL):(port)"
```
Ab Engine-Release `1.1.1.0` muss das Protokoll weggelassen werden:
```
"Host":"(host URL):(port)"
```
Beispiele finden Sie unter [Verwenden des Bolt-Protokolls](access-graph-opencypher-bolt.md).
## Verbesserungen in dieser Engine-Version
+ Die Instanzkonfiguration für `x2g` Instance-Typen wurde aktualisiert.
+ Die Leistung von Scheitelpunkt-Drops wurde verbessert.
## In diesem Engine-Version behobene Fehler
+ Es wurde ein Gremlin-Fehler behoben, bei dem Lösungen für bestimmte Arten von ASK-Joins keine stabile Reihenfolge für eine Abfrage beibehielten, die mehrfach oder über mehrere Leser aufgerufen wurde.
+ Außerdem wurde der Umfang einer Änderung in der vorherigen Version eingeschränkt, die zu Leistungseinbußen bei bestimmten Arten von ASK-Joins in Gremlin führte.
+ Es wurde ein Gremlin-Fehler im `union()`-Schritt behoben, der auftrat, wenn eine Edge-Eingabe und eine Traversake zu einem Scheitelpunkt innerhalb untergeordneter Traversalen stattfanden.
+ Es wurde ein Fehler im Gremlin-Profil behoben, bei dem einige Schritte als nicht optimiert gemeldet wurden, obwohl sie es tatsächlich waren.
+ Es wurde ein SPARQL-Fehler behoben, bei dem Variablen, die in `FILTER` Ausdrücken verwendet wurden, die in `UNION` Klauseln verschachtelt waren, ungültige Bereichsinformationen zugewiesen wurden.
## In dieser Version unterstützte Versionen in Abfragesprache
Bevor Sie einen DB-Cluster auf Version 1.1.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.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.1.1.0.R4
Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.1.1.0` ausführen.
## Upgrade auf diesen Release
**Wichtig**
**Ein Upgrade von einer früheren Version auf `1.1.0.0` löst auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für etwa 6 Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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.1.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.1.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.1.1.0.R3 (07.06.2022)
Ab dem 07.06.2022 wird die Engine-Version 1.1.1.0.R3 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.
**Wichtig**
**Ein Upgrade von einer früheren Version auf diese Engine-Version löst `1.1.0.0` auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für einige Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Anmerkung**
In dieser Version gibt es eine signifikante Änderung für Code, der openCypher mit IAM-Authentifizierung verwendet. Bisher enthielt die Hostzeichenfolge in der IAM-Signatur das Protokoll, zum Beispiel `bolt://`, in etwa wie folgt:
```
"Host":"bolt://(host URL):(port)"
```
Ab Engine-Release `1.1.1.0` muss das Protokoll weggelassen werden:
```
"Host":"(host URL):(port)"
```
Beispiele finden Sie unter [Verwenden des Bolt-Protokolls](access-graph-opencypher-bolt.md).
## Verbesserungen in dieser Engine-Version
+ Unterstützung für Graviton2-basierte `x2g` Instance-Typen hinzugefügt, die für speicherintensive Workloads optimiert sind. Diese sind zunächst nur in vier Varianten erhältlich AWS-Regionen:
+ USA Ost (Nord-Virginia) (`us-east-1`)
+ USA Ost (Ohio) (`us-east-2`)
+ USA West (Oregon) (`us-west-2`)
+ Europa (Irland) (`eu-west-1`)
Weitere Informationen finden Sie in der [Neptune-Preisseite](https://aws.amazon.com/neptune/pricing/).
+ Verbesserte Leistung von Gremlin-Schritten, bei denen mehrere Edge- oder Scheitelpunkttraversalen, Eigenschaftssuche oder Label-Suche erforderlich sind.
## In diesem Engine-Version behobene Fehler
+ Es wurde ein Gremlin-Fehler bei der Verarbeitung des `otherV()`-Schrittes innerhalb einer untergeordneten Traversalen behoben.
+ Es wurde ein Gremlin-Fehler in Abfragen mit `union` behoben, bei denen nur Filterschritte als untergeordnete Elemente verwendet wurden. Zum Beispiel:
```
g.V().union(has("name"), out("knows")).out()
```
+ Es wurde ein SPARQL-Fehler behoben, bei dem Variablen, die in `FILTER` Ausdrücken verwendet wurden, die in `UNION` Klauseln verschachtelt waren, ungültige Bereichsinformationen zugewiesen wurden.
## In dieser Version unterstützte Versionen in Abfragesprache
Bevor Sie einen DB-Cluster auf Version 1.1.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.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.1.1.0.R3
Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.1.1.0` ausführen.
## Upgrade auf diesen Release
**Wichtig**
**Ein Upgrade von einer früheren Version auf `1.1.0.0` löst auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für etwa 6 Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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.1.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.1.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 Neptune-Wartungsrelease, Version 1.1.1.0.R2 (16.05.2022)
Ab dem 16.05.2022 wird die Engine-Version 1.1.1.0.R2 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.
**Wichtig**
**Ein Upgrade von einer früheren Version auf diese Engine-Version löst `1.1.0.0` auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Um das Upgrade erfolgreich abzuschließen, muss für jedes Subnetz in jeder Availability Zone (AZ) mindestens eine IP-Adresse pro Neptune-Instance verfügbar sein. Wenn es beispielsweise eine Writer-Instance und zwei Reader-Instances in Subnetz 1 und zwei Reader-Instances in Subnetz 2 gibt, muss Subnetz 1 mindestens 3 freie IP-Adressen und Subnetz 2 mindestens 2 freie IP-Adressen haben, bevor das Upgrade gestartet wird.
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für einige Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
**Anmerkung**
In dieser Version gibt es eine signifikante Änderung für Code, der openCypher mit IAM-Authentifizierung verwendet. Bisher enthielt die Hostzeichenfolge in der IAM-Signatur das Protokoll, zum Beispiel `bolt://`, in etwa wie folgt:
```
"Host":"bolt://(host URL):(port)"
```
Ab Engine-Release `1.1.1.0` muss das Protokoll weggelassen werden:
```
"Host":"(host URL):(port)"
```
Beispiele finden Sie unter [Verwenden des Bolt-Protokolls](access-graph-opencypher-bolt.md).
## In dieser Version unterstützte Versionen in Abfragesprache
Bevor Sie einen DB-Cluster auf Version 1.1.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.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.1.1.0.R2
Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Wartungs-Patch-Version aktualisiert, wenn Sie die Modulversion `1.1.1.0` ausführen.
Sie können jeden vorherigen Neptune Engine-Release manuell auf diese Version aktualisieren.
## Upgrade auf diesen Release
**Wichtig**
**Ein Upgrade von einer früheren Version auf `1.1.0.0` löst auch ein Betriebssystem-Upgrade auf allen Instances in Ihrem DB-Cluster aus. Da aktive Schreibanforderungen, die während des Betriebssystem-Upgrades auftreten, nicht verarbeitet werden, müssen Sie vor dem Start des Upgrades alle Schreib-Workloads für den Cluster, der aktualisiert wird, pausieren, einschließlich Massendatenladungen.**
Zu Beginn des Upgrades generiert Neptune einen Snapshot mit einem Namen, der sich aus `preupgrade` gefolgt von einer automatisch generierten Kennung zusammensetzt, die auf Ihren DB-Clusterinformationen basiert. Dieser Snapshot wird Ihnen nicht berechnet und Sie können ihn zur Wiederherstellung Ihres DB-Clusters verwenden, falls während des Upgrade-Vorgangs etwas schief geht.
Wenn das Engine-Upgrade selbst abgeschlossen ist, ist die neue Engine-Version kurzzeitig auf dem alten Betriebssystem verfügbar, aber in weniger als 5 Minuten beginnen alle Instances in Ihrem Cluster gleichzeitig mit einem Betriebssystem-Upgrade. Ihr DB-Cluster wird zu diesem Zeitpunkt für etwa 6 Minuten nicht verfügbar sein. Sie können die Schreib-Workloads fortsetzen, nachdem das Upgrade abgeschlossen ist.
Dieser Prozess generiert die folgenden Ereignisse:
Ereignismeldungen pro Cluster:
`Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-(autogenerated snapshot ID)]`
`Database cluster major version has been upgraded`
Ereignismeldungen pro Instance:
`Applying off-line patches to DB instance`
`DB instance shutdown`
`Finished applying off-line patches to DB instance`
`DB instance restarted`
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.1.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.1.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.