Amazon Neptune Engine-Version 1.1.1.0 (19.04.2022) - Amazon Neptune
Patch-VeröffentlichungenNeue FeaturesVerbesserungenBehobene 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.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

Neue Features in dieser Engine-Version

  • Die openCypher-Abfragesprache 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.

  • Unterstützung für TinkerPop 3.5.2 wurde hinzugefügt. Zu den Änderungen in dieser Version gehören die Unterstützung für Remote-Transaktionen und Bytecode-Unterstützung für Sitzungen (Unter Verwendung von g.tx) 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 signifikante Änderungen eingeführt, die sich auf Ihren Gremlin-Code auswirken können. Zum Beispiel wird es nicht mehr funktionieren, Traversalen, die von einer GraphTraversalSource erzeugt wurden, als untergeordnete Elemente wie folgt zu verwenden: 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 hinzugefügt, die Sie in IAM-Datenzugriffsrichtlinien verwenden können, die den Zugriff auf Daten steuern, die in Neptune, einem Neptune-DB-Cluster, gespeichert sind.

  • Die Neptune DFE-Abfrage-Engine 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_dfe_query_engine-Instance-Parameter und nicht mit dem Lab-Modus-Parameter.

Verbesserungen in dieser Engine-Version

  • openCypher 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 openCypher Einhaltung der Spezifikationen in Amazon Neptune 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. 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 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.

  • Gremlin WebSocket-Bytecode und HTTP-Abfragen wurden in Audit-Protokolle 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. 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:

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

Für Windows:

aws neptune modify-db-cluster ^
    --db-cluster-identifier (your-neptune-cluster) ^
    --engine neptune ^
    --engine-version 1.1.1.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 ein vorheriges 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.