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 selbst entworfenen Clustern
Anmerkung
Die folgenden Überlegungen gelten nur für Upgrades von selbst entworfenen Clustern. Sie gelten nicht für ElastiCache Serverless.
Überlegungen zu Valkey und Redis OSS
Beachten Sie beim Upgrade eines selbst entworfenen 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 eine kritische Sicherheitslücke im System oder in der Cache-Software auftritt.
Ab ElastiCache 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 Redis OSS Engine Version 5.0.6 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 wird ElastiCache das Umschalten zwischen Valkey oder Redis OSS (Clustermodus deaktiviert) und Valkey oder Redis OSS (Clustermodus aktiviert) unterstützt.
-
Der Upgrade-Prozess ElastiCache für die Amazon for Redis OSS-Engine ist darauf ausgelegt, Ihre vorhandenen Daten bestmöglich beizubehalten, 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, bewährte Methoden für Redis OSS-Clients mit Fehlerwiederholungen und exponentiellem Backoff sowie bewährte Methoden zur Minimierung von Ausfallzeiten während der Wartung zu implementieren.
-
Sie können beim Upgrade Ihrer Engine kein direktes Upgrade von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis OSS (Clustermodus aktiviert) durchführen. Das folgende Verfahren zeigt Ihnen, wie Sie von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis OSS (Clustermodus aktiviert) aktualisieren.
Um ein Upgrade von einer Valkey- oder Redis OSS-Engine-Version (Cluster-Modus deaktiviert) auf eine Valkey- oder Redis OSS-Engine-Version (Clustermodus aktiviert) durchzuführen
-
Erstellen Sie eine Sicherungskopie Ihres Valkey- oder Redis OSS-Clusters oder Ihrer Replikationsgruppe (Clustermodus deaktiviert). Weitere Informationen finden Sie unter Erstellen manueller Backups.
-
Verwenden Sie das Backup, um einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mit einem Shard (Knotengruppe) zu erstellen und zu starten. 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, selbst entworfenen Clusters mit einem extern erstellten Backup.
-
Löschen Sie den alten Valkey- oder Redis OSS-Cluster oder die alte Replikationsgruppe (Clustermodus deaktiviert). Weitere Informationen finden Sie unter Löschen eines Clusters in ElastiCache oder Löschen einer Replikationsgruppe.
-
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 Skalierung von Clustern in Valkey oder Redis OSS (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 deaktiviertem Multi-AZ empfehlen wir, Redis OSS ausreichend Speicher zur Verfügung zu stellen, wie unter beschrieben. Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher 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 aktiviertem Multi-AZ 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 werden alle Replicas verarbeitet, bevor der Primärknoten verarbeitet wird. Wenn es in einem Shard weniger Replicas gibt, kann der Primärknoten in diesem Shard verarbeitet werden, bevor die Verarbeitung der Replicas in anderen Shards abgeschlossen wird.
-
Die Primärknoten für alle Shards werden seriell verarbeitet. Es erfolgt jeweils nur ein Upgrade für einen Primärknoten gleichzeitig.
-
-
Wenn die Verschlüsselung in Ihrem aktuellen Cluster oder Ihrer Replikationsgruppe aktiviert ist, können Sie nicht auf eine Engine-Version aktualisieren, die keine Verschlüsselung unterstützt, z. B. von 3.2.6 auf 3.2.10.
Überlegungen zu Memcached
Beachten Sie beim Upgrade eines selbst entworfenen Memcached-Clusters Folgendes.
Versionsverwaltung der Enginge ist so entwickelt, dass Sie so viel Kontrolle wie möglich darüber haben, wie Patchen erfolgt. Behält sich jedoch ElastiCache das Recht vor, Ihren Cluster in Ihrem Namen zu patchen, sollte der unwahrscheinliche Fall eintreten, dass das System oder die Cache-Software eine kritische Sicherheitslücke aufweist.
-
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.
