View a markdown version of this page

Überlegungen zum Upgrade bei der Arbeit mit knotenbasierten Clustern - Amazon ElastiCache

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.

Überlegungen zum Upgrade bei der Arbeit mit knotenbasierten Clustern

Anmerkung

Die folgenden Überlegungen gelten nur für das Upgrade von knotenbasierten Clustern. Sie gelten nicht für Serverless. ElastiCache

Überlegungen zu Valkey und Redis OSS

Beachten Sie beim Upgrade eines knotenbasierten Valkey- oder Redis OSS-Clusters Folgendes.

  • Versionsverwaltung der Enginge ist so entwickelt, dass Sie so viel Kontrolle wie möglich darüber haben, wie Patchen erfolgt. ElastiCache behält sich jedoch das Recht vor, Ihren Cluster in Ihrem Namen zu patchen, falls im unwahrscheinlichen Fall einer kritischen Sicherheitslücke im System oder in der Cache-Software eine kritische Sicherheitslücke auftritt.

  • ElastiCache Beginnend mit Version 7.2 für Valkey und ElastiCache Version 6.0 für Redis OSS ElastiCache wird für jede Nebenversion eine einzige Version angeboten, anstatt mehrere Patch-Versionen anzubieten.

  • Ab Version 5.0.6 der Redis OSS Engine können Sie Ihre Cluster-Version mit minimaler Ausfallzeit aktualisieren. Der Cluster kann während des gesamten Upgrades gelesen und in der Regel auch beschrieben werden, ausgenommen während der Failover-Operation, der nur einige Sekunden dauert.

  • Sie können Ihre ElastiCache Cluster auch mit Versionen vor 5.0.6 aktualisieren. Der Prozess ist identisch, kann jedoch längere Failover-Zeit während der DNS-Ausbreitung (30 Sek. - 1 Min.) verursachen.

  • Ab Redis OSS 7 ElastiCache unterstützt es das Umschalten zwischen Valkey oder Redis OSS (Clustermodus deaktiviert) und Valkey oder Redis OSS (Clustermodus aktiviert).

  • Der Upgrade-Prozess ElastiCache für die Amazon for Redis OSS-Engine wurde so konzipiert, dass Ihre vorhandenen Daten bestmöglich erhalten bleiben, und erfordert eine erfolgreiche Redis OSS-Replikation.

  • Beim Upgrade der Engine ElastiCache werden bestehende Client-Verbindungen beendet. Um Ausfallzeiten bei Engine-Upgrades zu minimieren, empfehlen wir Ihnen, Best Practices für Redis OSS-Clients mit wiederholten Fehlern und exponentiellem Backoff sowie die Best Practices zur Minimierung von Ausfallzeiten während der Wartung zu implementieren.

  • Sie können beim Upgrade Ihrer Engine nicht direkt von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis OSS (Clustermodus aktiviert) aktualisieren. Das folgende Verfahren zeigt Ihnen, wie Sie ein Upgrade von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis OSS (Clustermodus aktiviert) durchführen.

    So führen Sie ein Upgrade von einer Valkey- oder Redis OSS (Clustermodus deaktiviert) auf eine Valkey- oder Redis OSS-Engine-Version (Clustermodus aktiviert) durch

    1. Erstellen Sie eine Sicherungskopie Ihres Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) oder Ihrer Replikationsgruppe. Weitere Informationen finden Sie unter Erstellen manueller Backups.

    2. Verwenden Sie das Backup, um einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mit einem Shard (Knotengruppe) zu erstellen und zu seamen. Geben Sie die neue Engine-Version an und aktivieren Sie den Cluster-Modus, wenn Sie den Cluster oder die Replikationsgruppe erstellen. Weitere Informationen finden Sie unter Tutorial: Seeding eines neuen knotenbasierten Clusters mit einem extern erstellten Backup.

    3. Löschen Sie den alten Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) oder die alte Replikationsgruppe. Für weitere Informationen siehe Löschen eines Clusters in ElastiCache oder Löschen einer Replikationsgruppe.

    4. Skalieren Sie den neuen Valkey- oder Redis OSS-Cluster oder die neue Replikationsgruppe (Clustermodus aktiviert) auf die Anzahl der Shards (Knotengruppen), die Sie benötigen. Weitere Informationen finden Sie unter Skalieren von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert).

  • Beim Upgrade von Hauptversionen der Engine, beispielsweise von 5.0.6 auf 6.0, müssen Sie auch eine neue Parametergruppe auswählen, die mit der neuen Engine-Version kompatibel ist.

  • Für einzelne Redis OSS-Cluster und Cluster mit Multi-AZ deaktivierter Funktion empfehlen wir, Redis OSS ausreichend Arbeitsspeicher zur Verfügung zu stellen, wie unter beschrieben. Stellen Sie sicher, dass Sie über genügend Speicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen In diesen Fällen steht der primäre Knoten während des Upgrade-Prozesses für Serviceanfragen nicht zur Verfügung.

  • Für Redis OSS-Cluster mit Multi-AZ aktivierter Funktion empfehlen wir außerdem, Engine-Upgrades in Zeiten mit geringem eingehendem Schreibverkehr zu planen. Bei einem Upgrade auf Redis OSS 5.0.6 oder höher steht der primäre Cluster während des Upgrade-Vorgangs weiterhin für Serviceanfragen zur Verfügung.

    Cluster und Replikationsgruppen mit mehreren Shards werden wie folgt verarbeitet und gepatcht:

    • Alle Shards werden parallel verarbeitet. Es wird jeweils nur eine Upgrade-Operation für einen Shard gleichzeitig durchgeführt.

    • In jedem Shard ElastiCache erstellt Amazon einen neuen Satz von Knoten, auf denen die neue Engine-Version ausgeführt wird. Ein neuer Knoten wird mit dem vorhandenen primären Knoten synchronisiert. Nach Abschluss der Synchronisierung stuft ein Failover den neuen Knoten zum Primärknoten herauf. Die verbleibenden neuen Knoten werden dann mit dem neuen Primärknoten synchronisiert, und die alten Knoten werden aus dem Cluster entfernt.

    • Während dieses Vorgangs gibt es einen kurzen Zeitraum, in dem sowohl alte als auch neue Knoten in der Cluster-Topologie sichtbar sind. Clients, die eine Verbindung zu neuen Replikatknoten herstellen, die noch Daten laden, erhalten möglicherweise Fehler. Um diesen vorübergehenden Zustand zu bewältigen, empfehlen wir die Implementierung Bewährte Methoden für Kunden (Valkey und Redis OSS) mit wiederholten Fehlern und exponentiellem Backoff.

    • Auf allen Shards werden primäre Failovers seriell verarbeitet. Es erfolgt jeweils nur ein Failover für einen primären Knoten.

  • Wenn die Verschlüsselung in Ihrem aktuellen Cluster oder Ihrer Replikationsgruppe aktiviert ist, können Sie kein Upgrade auf eine Engine-Version durchführen, die Verschlüsselung nicht unterstützt.

Überlegungen zu Memcached

Beachten Sie beim Upgrade eines knotenbasierten Memcached-Clusters Folgendes.

  • Versionsverwaltung der Enginge ist so entwickelt, dass Sie so viel Kontrolle wie möglich darüber haben, wie Patchen erfolgt. ElastiCache behält sich jedoch das Recht vor, Ihren Cluster in Ihrem Namen zu patchen, falls der unwahrscheinliche Fall einer kritischen Sicherheitslücke im System oder in der Cache-Software auftritt.

  • Da die Memcached-Engine keine Persistenz unterstützt, stellen Versions-Upgrades der Memcached-Engine immer einen Störfall dar, bei dem alle Cache-Daten im Cluster gelöscht werden.