Amazon Neptune Engine-Version 1.2.0.0.R4 (29.09.2023) - Amazon Neptune
VerbesserungenBehobene FehlerUnterstützte Versionen in AbfragespracheUpgrade-PfadeWird geupgradet

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Amazon Neptune Engine-Version 1.2.0.0.R4 (29.09.2023)

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

Anmerkung

Bei einem Upgrade von einer Engine-Version vor 1.2.0.0:

  • Mit der Engine-Version 1.2.0.0 wurde ein neues Format für benutzerdefinierte Parametergruppen und benutzerdefinierte Cluster-Parametergruppen eingeführt. Wenn Sie also von einer Engine-Version vor 1.2.0.0 auf Engine-Version 1.2.0.0 oder höher aktualisieren, müssen Sie alle vorhandenen benutzerdefinierten Parametergruppen und benutzerdefinierten Cluster-Parametergruppen mithilfe der Parametergruppenfamilie neptune1.2 neu erstellen. In früheren Versionen wurde die Parametergruppenfamilie neptune1 verwendet und diese Parametergruppen funktionieren nicht mit Version 1.2.0.0 und höher. Weitere Informationen finden Sie unter Amazon-Neptune-Parametergruppen.

  • Mit der Engine-Version 1.2.0.0 wurde auch ein neues Format für Undo-Protokolle eingeführt. Daher müssen alle Undo-Protokolle, die von einer früheren Engine-Version erstellt wurden, gelöscht werden und die CloudWatch-Metrik UndoLogsListSize muss auf Null fallen, bevor ein Upgrade von einer Version vor 1.2.0.0 gestartet werden kann. Wenn beim Versuch, ein Update zu starten, zu viele Undo-Protokolldatensätze (200.000 oder mehr) vorhanden sind, kann es beim Upgrade-Versuch zu einer Zeitüberschreitung kommen, während auf den Abschluss des Löschvorgangs der Undo-Protokolle gewartet wird.

    Sie können die Löschgeschwindigkeit beschleunigen, indem Sie die Writer-Instance des Clusters aktualisieren, in der das Löschen stattfindet. Wenn Sie dies tun, bevor Sie versuchen, das Upgrade durchzuführen, kann die Anzahl der Undo-Logs vor dem Start reduziert werden. Wenn Sie die Größe des Writers auf einen 24XL-Instance-Typ erhöhen, kann sich Ihre Löschrate auf mehr als eine Million Datensätze pro Stunde erhöhen.

    Wenn die UndoLogsListSize-CloudWatch-Metrik extrem umfangreich ist, kann Ihnen die Eröffnung eines Support-Falls dabei helfen, zusätzliche Strategien zu finden, um sie zu reduzieren.

  • Schließlich wurde mit Version 1.2.0.0 eine bahnbrechende Änderung eingeführt, die sich auf früheren Code auswirkt, der das Bolt-Protokoll mit IAM-Authentifizierung verwendete. Ab Version 1.2.0.0 benötigt Bolt einen Ressourcenpfad für die IAM-Signatur. In Java könnte das Festlegen des Ressourcenpfads so aussehen: request.setResourcePath("/openCypher"));. In anderen Sprachen kann /openCypher an den Endpunkt-URI angehängt werden. Beispiele finden Sie unter Verwenden des Bolt-Protokolls.

Verbesserungen in dieser Engine-Version

  • Allen Neptune ML-APIs wurde ein enableInterContainerTrafficEncryption-Parameter hinzugefügt, mit dem Sie die Verschlüsselung des Datenverkehrs zwischen Containern in Trainings- oder Hyperparameter-Tuning-Jobs aktivieren und deaktivieren können.

  • Für Serverless-DB-Cluster wurde die Einstellung für die Mindestkapazität auf 1,0 NCU und die niedrigste gültige Maximaleinstellung auf 2,5 NCU geändert. Weitere Informationen finden Sie unter Kapazitätsskalierung in einem Neptune-Serverless-DB-Cluster (((vor dem Release muss sich diese Änderung auch auf der Serverless-Seite widerspiegeln))).

In diesem Engine-Version behobene Fehler

  • Es wurde ein openCypher-Fehler behoben, durch den Aktualisierungs- und Rückgabeanfragen orderBy, limit oder skip nicht richtig behandelt haben.

  • Es wurde ein openCypher-Fehler behoben, durch den Parameter, die in einer Anfrage enthalten waren, durch Parameter in einer anderen gleichzeitigen Anfrage überschrieben werden konnten.

  • Es wurde ein openCypher-Fehler bei der Transaktionsverarbeitung von Bolt behoben.

  • Behebung von Gremlin-Korrektheitsproblemen bei DFE-Abfragen mit limit als untergeordneter Traversal von Nicht-Union-Schritten durch Rückgriff auf Tinkerpop. Zum Beispiel für Abfragen wie diese:

    g.withSideEffect('Neptune#useDFE', true)
 .V()
 .as("a")
 .select("a")
 .by(out()
 .limit(1))

  • Es wurde ein Gremlin-Fehler behoben, bei dem eine Abfrage fehlschlug, weil sie zu viele TinkerPop-Schritte enthielt und dann nicht bereinigt wurde.

  • Es wurde ein Gremlin-Fehler behoben, bei dem Zeichenkettenausgaben von order() nicht richtig sortiert wurden, wenn einige von ihnen ein Leerzeichen enthielten.

  • Es wurde ein Gremlin-Fehler behoben, durch den ein Transaktionsleck auftreten konnte, wenn eine Abfrage als Zeichenfolge gesendet wurde und GroupCountStep enthalten hat.

  • Es wurde ein Gremlin-Fehler behoben, bei dem es zu einem Transaktionsleck kam, wenn der Endpunkt des Gremlin-Abfragestatus auf Abfragen mit Prädikaten in untergeordneten Durchläufen für Schritte überprüft wurde, die nicht nativ verarbeitet wurden.

  • Es wurde ein Gremlin-Fehler behoben, durch den beim Hinzufügen einer Edge und ihrer Eigenschaften gefolgt von inV() oder outV() ein InternalFailureException verursacht wurde.

  • Ein Problem mit der Parallelität in der Speicherebene wurde behoben.

In dieser Version unterstützte Versionen in Abfragesprache

Bevor Sie einen DB-Cluster auf Version 1.2.0.0.R4 aktualisieren, stellen Sie sicher, dass Ihr Projekt mit den folgenden Versionen in Abfragesprache kompatibel ist:

  • Die älteste unterstützte Version von Gremlin: 3.5.2

  • Die neueste unterstützte Version von Gremlin: 3.5.6

  • openCypher-Version: Neptune-9.0.20190305-1.0

  • SPARQL-Version: 1.1

Upgrade-Pfade zum Engine-Release 1.2.0.0.R4

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

Sie können nur 1.2.0.0 manuell vom neuesten Patch-Release des Engine-Release 1.1.1.0 auf Release aktualisieren. Frühere Engine-Versionen müssen zuerst auf die neueste Version von 1.1.1.0 aktualisiert werden, bevor sie auf 1.2.0.0 aktualisiert werden können.

Wenn Sie zuerst auf Version 1.1.1.0 und dann sofort auf Version 1.2.0.0 aktualisieren, tritt möglicherweise ein Fehler wie der folgende auf:

   We're sorry, your request to modify DB cluster (cluster identifier) has failed.
   Cannot modify engine version because instance (instance identifier) is
   running on an old configuration. Apply any pending maintenance actions on the instance before
   proceeding with the upgrade.

Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann.

Upgrade auf diesen Release

Wenn auf einem DB-Cluster eine Engine-Version ausgeführt wird, für die es einen Upgrade-Pfad zu dieser Version gibt, kann sie jetzt aktualisiert werden. Sie können jeden geeigneten Cluster mithilfe der DB-Cluster-Operationen auf der Konsole oder mithilfe des SDK aktualisieren. Mit dem folgenden CLI-Befehl wird ein geeignetes Cluster sofort aktualisiert:

Für Linux, OS X oder Unix:

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

Für Windows:

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

Statt --apply-immediately können Sie --no-apply-immediately angeben. Für die Durchführung eines Hauptversions-Upgrades ist der allow-major-version-upgrade-Parameter erforderlich. Stellen Sie außerdem sicher, dass Sie die Engine-Version angeben, da Ihre Engine sonst möglicherweise auf eine andere Version aktualisiert wird.

Wenn Ihr Cluster eine benutzerdefinierte Cluster-Parametergruppe verwendet, müssen Sie diesen Parameter einschließen, um ihn zu anzugeben:

    --db-cluster-parameter-group-name (name of the custom DB cluster parameter group)

Ebenso sollte für Instances im Cluster, die eine benutzerdefinierte DB-Parametergruppe verwenden, dieser Parameter eingeschlossen werden, um ihn zu spezifizieren:

    --db-instance-parameter-group-name (name of the custom instance parameter group)

Testen Sie immer vor dem Upgrade

Wenn eine neue Haupt- oder Nebenversion der Neptune-Engine veröffentlicht wird, testen Sie Ihre Neptune-Anwendungen immer zuerst dafür, bevor Sie sie dazu aktualisieren. Selbst ein Nebenversions-Upgrade könnte neue Features oder Verhaltensweisen einführen, die sich auf Ihren Code auswirken können.

Vergleichen Sie zunächst die Seiten mit den Versionshinweisen Ihrer aktuellen Version mit denen der Zielversion, um festzustellen, ob es Änderungen an den Versionen der Abfragesprache oder andere wichtige Änderungen geben wird.

Die beste Methode, eine neue Version zu testen, bevor Sie Ihren Produktions-DB-Cluster aktualisieren, besteht darin, den Produktions-Cluster zu klonen, so dass auf dem Klon die neue Engine-Version ausgeführt wird. Sie können dann Abfragen auf dem Klon ausführen, ohne dass der Produktions-DB-Cluster davon betroffen wird.

Erstellen Sie vor einem Upgrade immer einen manuellen Snapshot

Bevor Sie ein Upgrade durchführen, wird dringend empfohlen, immer einen manuellen Snapshot Ihres DB-Clusters zu erstellen. Ein automatischer Snapshot bietet nur kurzfristigen Schutz, wohingegen ein manueller Snapshot verfügbar bleibt, bis Sie ihn explizit löschen.

In bestimmten Fällen erstellt Neptune im Rahmen des Upgrade-Prozesses einen manuellen Snapshot für Sie, aber Sie sollten sich nicht darauf verlassen und in jedem Fall Ihren eigenen manuellen Snapshot erstellen.

Wenn Sie sicher sind, dass Sie Ihren DB-Cluster nicht auf den Zustand vor dem Upgrade zurücksetzen müssen, können Sie den manuellen Snapshot, den Sie selbst erstellt haben, sowie den manuellen Snapshot, den Neptune möglicherweise erstellt hat, explizit löschen. Wenn Neptune einen manuellen Snapshot erstellt, hat dieser einen Namen, der mit preupgrade beginnt, gefolgt vom Namen Ihres DB-Clusters, der Quell-Engine-Version, der Ziel-Engine-Version und dem Datum.

Anmerkung

Wenn Sie versuchen, ein Upgrade durchzuführen, während eine ausstehende Aktion ausgeführt wird, 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. Bei Fragen oder Bedenken steht Ihnen das AWS Support-Team in den Community-Foren und über AWS Premium Support zur Verfügung.