

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.0.2.2 09.03.2020
<a name="engine-releases-1.0.2.2"></a>

Ab dem 09.03.2023 wird die Engine-Version 1.0.2.2 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.

## Nachfolgende Patch-Veröffentlichungen für dieses Version
<a name="engine-releases-1.0.2.2-patches"></a>
+ [Release: 1.0.2.2.R2 (02.04.2020)](engine-releases-1.0.2.2.R2.md) 
+ [Release: 1.0.2.2.R3 (22.07.2020)](engine-releases-1.0.2.2.R3.md) 
+ [Release: 1.0.2.2.R4 (23.07.2020)](engine-releases-1.0.2.2.R4.md) 
+ [Release: 1.0.2.2.R5 (12.10.2020)](engine-releases-1.0.2.2.R5.md) 
+ [Release: 1.0.2.2.R6 (19.02.2021)](engine-releases-1.0.2.2.R6.md) 

## Verbesserungen in dieser Engine-Version
<a name="engine-releases-1.0.2.2-improvements"></a>
+ Der Status-API wurden Informationen zu Transaktionen hinzugefügt, die zurückgesetzt werden. Siehe [Instance-Status](access-graph-status.md).
+ Die Version von Apache wurde TinkerPop auf 3.4.3 aktualisiert.

  Version 3.4.3 ist abwärtskompatibel mit der von Neptune unterstützten Vorgängerversion (3.4.1). Mit ihr wird eine geringfügige Änderung des Verhaltens eingeführt: Gremlin gibt keinen Fehler mehr zurück, wenn Sie versuchen, eine Sitzung zu schließen, die nicht vorhanden ist (siehe [Fehler beim Schließen von nicht vorhandenen Sitzungen verhindern](https://issues.apache.org/jira/browse/TINKERPOP-2237)).
+ Es wurden Leistungsengpässe bei der Ausführung von Schritten der Gremlin-Volltextsuche beseitigt.

## In diesem Engine-Version behobene Fehler
<a name="engine-releases-1.0.2.2-defects"></a>
+ Es wurde ein SPARQL-Fehler bei der Behandlung von leeren Graphenmustern in Abfragen behoben.
+ Es wurde ein SPARQL-Fehler bei der Behandlung von unkodierten Semikolons in URL-kodierten Abfragen behoben.
+ Es wurde ein Gremlin-Fehler bei der Behandlung von wiederholten Vertices (Eckpunkten) im `Union`-Schritt behoben.
+ Es wurde ein Gremlin-Fehler behoben, der dazu führte, dass einige Abfragen mit einem `.simplePath()` oder `.cyclicPath()` innerhalb einer `.repeat()` fehlerhaften Ergebnisses zurückgaben.
+ Es wurde ein Gremlin-Fehler behoben, der dazu führte, dass `.project()` falsche Ergebnisse zurückgab, wenn sein untergeordnetes Traversal keine Lösungen zurückgab.
+ Es wurde ein Gremlin-Fehler behoben, bei dem Fehler aus Lese- und Schreibkonflikten eine `InternalFailureException` statt eine `ConcurrentModificationException` auslösten.
+ Es wurde ein Gremlin-Fehler behoben, der `.group().by(...).by(values("property"))`-Fehler verursachte.
+ Gremlin-Fehler in der Profilausgabe für Schritte wurden behoben. full-text-search
+ Ein Ressourcenleck in Gremlin-Sitzungen wurde behoben.
+ Es wurde ein Fehler behoben, der in einigen Fällen verhinderte, dass die Status-API die richtige bestellbare Version meldete.
+ Es wurde ein Fehler beim Massenladen behoben, der es ermöglichte, eine URL zu einem anderen Ort als als Quelle in einer Massenladeanforderung zu verwenden.
+ Es wurde ein Massen-Loader-Fehler im ausführlichen Ladestatus behoben.

## In dieser Version unterstützte Versionen in Abfragesprache
<a name="engine-releases-1.0.2.2-query-versions"></a>

Bevor Sie einen DB-Cluster auf Version 1.0.2.2 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist:
+ *Gremlin-Version:* `3.4.3`
+ *SPARQL-Version:* `1.1`

## Upgrade-Pfade zum Engine-Release 1.0.2.2
<a name="engine-releases-1.0.2.2-upgrade-paths"></a>

Sie können jeden vorherigen Neptune Engine-Release manuell auf diese Version aktualisieren.

Wenn der `AutoMinorVersionUpgrade`-Parameter des Clusters auf `True` eingestellt ist, wird der Cluster während eines Wartungsfensters zwei bis drei Wochen nach dem Datum dieses Releases automatisch auf diese Engine-Version aufgerüstet.

## Upgrade auf diesen Release
<a name="engine-releases-1.0.2.2-upgrading"></a>

Amazon Neptune 1.0.2.2 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.0.2.2 \
4.     --apply-immediately
```

Für Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2-snapshot-before-upgrading"></a>

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.0.2.2.R6 (19.02.2021)
<a name="engine-releases-1.0.2.2.R6"></a>

Ab dem 19.02.2020 wird die Engine-Version 1.0.2.2.R6 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.

## In diesem Engine-Version behobene Fehler
<a name="engine-releases-1.0.2.2.R6-defects"></a>
+ Es wurde ein Gremlin-Fehler behoben, bei dem unter bestimmten Umständen `InternalFailureException` als Antwortcode festgelegt wurde, wenn ein `ConcurrentModificationException` auftrat.
+ Es wurde ein Gremlin-Fehler behoben, bei dem das Aktualisieren von Edges oder Scheitelpunkten unter bestimmten Bedingungen zu einem transienten `InternalFailureException` führen konnte.

## In dieser Version unterstützte Versionen in Abfragesprache
<a name="engine-releases-1.0.2.2.R6-query-versions"></a>

Bevor Sie einen DB-Cluster auf Version 1.0.2.2.R6 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist:
+ *Gremlin-Version:* `3.4.8`
+ *SPARQL-Version:* `1.1`

## Upgrade-Pfade zum Engine-Release 1.0.2.2.R6
<a name="engine-releases-1.0.2.2.R6-upgrade-paths"></a>

Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.0.2.2` ausführen.

Sie können jeden vorherigen Neptune Engine-Release manuell auf diese Version aktualisieren.

## Upgrade auf diesen Release
<a name="engine-releases-1.0.2.2.R6-upgrading"></a>

Amazon Neptune 1.0.2.2.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.0.2.2 \
4.     --apply-immediately
```

Für Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2.R6-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2.R6-snapshot-before-upgrading"></a>

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.0.2.2.R5 (12.10.2020)
<a name="engine-releases-1.0.2.2.R5"></a>

Ab dem 12.10.2020 wird die Engine-Version 1.0.2.2.R5 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.

## Verbesserungen in dieser Engine-Version
<a name="engine-releases-1.0.2.2.R5-improvements"></a>
+ Verbesserte Leistung für den Gremlin-Schritt `properties()`.
+ Details zu `BindOp` und `MultiplexerOp` in Erklärungs- und Profilberichten hinzugefügt.
+ Für SPARQL-Abfrageantworten wurde dem Content-Type-Header `charset` hinzugefügt, sodass HTTP-Clients den verwendeten Zeichensatz automatisch erkennen können.

## In diesem Engine-Version behobene Fehler
<a name="engine-releases-1.0.2.2.R5-defects"></a>
+ Ein SPARQL-Fehler wurde behoben, bei dem `CancellationException` nicht behandelt wurde.
+ Es wurde ein SPARQL-Fehler behoben, bei dem Abfragen, die verschachtelte optionale Elemente enthielten, nicht korrekt funktionierten.
+ Es wurde ein SPARQL-Fehler in LOAD behoben, bei dem ein `ConcurrentModificationException` dazu führen konnte, dass eine Abfrage sich aufhängte.
+ Es wurde ein SPARQL-Fehler behoben, der verhinderte, dass Abfrageantworten gzip-komprimiert wurden.
+ Ein Gremlin-Fehler im `groupBy()`-Schritt wurde behoben.
+ Ein Gremlin-Fehler im Zusammenhang mit der Verwendung eines `aggregate()`-Schrittes innerhalb eines `local()`-Schrittes wurde behoben.
+ Ein Gremlin-Fehler im Zusammenhang mit der Verwendung von `bothE()` gefolgt von einem Prädikat, das Aggregatwerte verwendet, wurde behoben.
+ Ein Gremlin-Fehler im Zusammenhang mit der Verwendung des `bothE()`-Schrittes mit dem `repeat()`-Schritt wurde behoben.
+ Ein potenzielles Gremlin-Speicherleck im Zusammenhang mit dem `both()`-Schritt wurde behoben.
+ Es wurde ein Fehler behoben, bei dem Anforderungsmetriken fehlten, weil ein Endpunkt, der auf ‚/’ endete, nicht korrekt behandelt wurde.
+ Es wurde ein Fehler behoben, der ein `ThrottlingException` auslösen konnte, auch wenn die Warteschlange nicht voll ist.
+ Es wurde ein Fehler beim Abrufen des Ladestatus behoben, wenn ein Ladevorgang aus einem Grund wie `LOAD_DATA_FAILED_DUE_TO_FEED_MODIFIED_OR_DELETE` fehlschlägt.

## In dieser Version unterstützte Versionen in Abfragesprache
<a name="engine-releases-1.0.2.2.R5-query-versions"></a>

Bevor Sie einen DB-Cluster auf Version 1.0.2.2.R5 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist:
+ *Gremlin-Version:* `3.4.3`
+ *SPARQL-Version:* `1.1`

## Upgrade-Pfade zum Engine-Release 1.0.2.2.R5
<a name="engine-releases-1.0.2.2.R5-upgrade-paths"></a>

Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.0.2.2` ausführen.

Sie können jeden vorherigen Neptune Engine-Release manuell auf diese Version aktualisieren.

## Upgrade auf diesen Release
<a name="engine-releases-1.0.2.2.R5-upgrading"></a>

Amazon Neptune 1.0.2.2.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.0.2.2 \
4.     --apply-immediately
```

Für Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2.R5-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2.R5-snapshot-before-upgrading"></a>

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.0.2.2.R4 (23.07.2020)
<a name="engine-releases-1.0.2.2.R4"></a>

Ab dem 23.07.2020 wird die Engine-Version 1.0.2.2.R4 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.

## Verbesserungen in dieser Engine-Version
<a name="engine-releases-1.0.2.2.R4-improvements"></a>
+ Die Speichernutzung wurde verbessert, indem ungenutzter Speicher häufiger für das Betriebssystem freigegeben wurde.
+ Außerdem wurde die Speichernutzung für SPARQL GROUP BY-Abfragen verbessert.
+ Die maximale Dauer, die eine mit IAM authentifizierte WebSocket Verbindung bestehen kann, wurde von 36 Stunden auf 10 Tage erhöht.
+ Die `BufferCacheHitRatio` CloudWatch Metrik wurde hinzugefügt, die bei der Diagnose der Abfragelatenz und der Optimierung von Instance-Typen nützlich sein kann. Siehe [Neptune-Metriken](cw-metrics.md#cw-metrics-available). 

## In diesem Engine-Version behobene Fehler
<a name="engine-releases-1.0.2.2.R4-defects"></a>
+ Ein Fehler beim Schließen inaktiver oder abgelaufener WebSocket IAM-Verbindungen wurde behoben. Neptune sendet jetzt einen geschlossenen Frame, bevor die Verbindung geschlossen wird.
+ Ein SPARQL-Fehler bei der Auswertung von Abfragen, die verschachtelte FILTER EXISTS and/or FILTER NOT EXISTS-Bedingungen enthielten, wurde behoben.
+ Es wurde ein Fehler beim Beenden von SPARQL-Abfragen behoben, der unter bestimmten extremen Bedingungen zu blockierten Threads auf dem Server führte.
+ In diesem Schritt `hasLabel` wurde ein Gremlin-Fehler behoben, der Edge PathType betraf.
+ Ein Gremlin-Fehler wurde behoben, um `toV` und `fromV` individuell für jede Richtung auf `bothE` zu behandeln.
+ Es wurde ein Gremlin-Fehler behoben, der dazu führte, dass sideEffects verschwanden.

## In dieser Version unterstützte Versionen in Abfragesprache
<a name="engine-releases-1.0.2.2.R4-query-versions"></a>

Bevor Sie einen DB-Cluster auf Version 1.0.2.2.R4 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist:
+ *Gremlin-Version:* `3.4.3`
+ *SPARQL-Version:* `1.1`

## Upgrade-Pfade zum Engine-Release 1.0.2.2.R4
<a name="engine-releases-1.0.2.2.R4-upgrade-paths"></a>

Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.0.2.2` ausführen.

Sie können jeden vorherigen Neptune Engine-Release manuell auf diese Version aktualisieren.

## Upgrade auf diesen Release
<a name="engine-releases-1.0.2.2.R4-upgrading"></a>

Amazon Neptune 1.0.2.2.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.0.2.2 \
4.     --apply-immediately
```

Für Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2.R4-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2.R4-snapshot-before-upgrading"></a>

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.0.2.2.R3 (22.07.2020)
<a name="engine-releases-1.0.2.2.R3"></a>

Die Engine-Version 1.0.2.2.R3 wurde in den [Engine-Release 1.0.2.2.R4](engine-releases-1.0.2.2.R4.md) aufgenommen.

# Amazon Neptune Engine-Version 1.0.2.2.R2 (02.04.2020)
<a name="engine-releases-1.0.2.2.R2"></a>

Ab dem 02.04.2020 wird die Engine-Version 1.0.2.2.R2 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.

## Verbesserungen in dieser Engine-Version
<a name="engine-releases-1.0.2.2.R2-improvements"></a>
+ Sie können jetzt bis zu 64 Bulk-Ladeaufträge in die Warteschlange stellen, anstatt mit dem Starten eines Auftrags warten zu müssen, bis eine anderer fertig ist. Sie können mithilfe des Parameters `dependencies` des Befehls `load` die Ausführung einer Ladeanforderung in der Warteschlange auch davon abhängig machen, ob einer oder mehrere der zuvor in die Warteschlange eingestellten Ladeaufträge erfolgreich abgeschlossen wurden. Siehe [Neptune-Loader-Befehl](load-api-reference-load.md).
+ Full-text-search Die Ausgabe kann jetzt sortiert werden (siehe[Parameter für die Volltextsuche](full-text-search-parameters.md)).
+ Es gibt jetzt einen DB-Cluster-Parameter zum Aufrufen von Neptune-Streams, und das Feature wurde aus dem Labormodus verschoben. Siehe [Verwenden von Neptune-Streams](streams-using-enabling.md).

## In diesem Engine-Version behobene Fehler
<a name="engine-releases-1.0.2.2.R2-defects"></a>
+ Ein stochastischer Fehler beim Serverstart, der die Instance-Erstellung verzögert hat, wurde behoben.
+ Es wurde ein Optimierer-Problem behoben, bei dem `BIND`-Anweisungen in der Abfrage bewirkten, dass der Optimierer mit unselektiven Mustern in der Join-Order-Planung gestartet wurde.

## In dieser Version unterstützte Versionen in Abfragesprache
<a name="engine-releases-1.0.2.2.R2-query-versions"></a>

Bevor Sie einen DB-Cluster auf Version 1.0.2.2.R2 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist:
+ *Gremlin-Version:* `3.4.3`
+ *SPARQL-Version:* `1.1`

## Upgrade-Pfade zum Engine-Release 1.0.2.2.R2
<a name="engine-releases-1.0.2.2.R2-upgrade-paths"></a>

Ihr Cluster wird während des nächsten Wartungsfensters automatisch auf diese Patch-Version aktualisiert, wenn Sie die Modulversion `1.0.2.2` ausführen.

Sie können jeden vorherigen Neptune Engine-Release manuell auf diese Version aktualisieren.

## Upgrade auf diesen Release
<a name="engine-releases-1.0.2.2.R2-upgrading"></a>

Amazon Neptune 1.0.2.2.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.0.2.2 \
4.     --apply-immediately
```

Für Windows:

```
1. aws neptune modify-db-cluster ^
2.     --db-cluster-identifier (your-neptune-cluster) ^
3.     --engine-version 1.0.2.2 ^
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
<a name="engine-1.0.2.2.R2-test-before-upgrading"></a>

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
<a name="engine-1.0.2.2.R2-snapshot-before-upgrading"></a>

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.