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.
Versionsverwaltung für ElastiCache
Sie können festlegen, wie Sie Ihre ElastiCache Caches und selbst entworfenen Cluster, die für die OSS-Engines Valkey, Memcached und Redis aktualisiert wurden, aktualisieren möchten.
ElastiCache Versionsverwaltung für Serverless Cache
Verwalten Sie, ob und wann der ElastiCache Serverless Cache aktualisiert wird, und führen Sie Versionsupgrades zu Ihren eigenen Bedingungen und Zeitplänen durch.
ElastiCache Serverless wendet automatisch die neueste MINOR- und PATCH-Softwareversion auf Ihren Cache an, ohne dass dies Auswirkungen oder Ausfallzeiten auf Ihre Anwendung hat. Von Ihrer Seite aus ist keine Aktion erforderlich.
Wenn eine neue HAUPTversion verfügbar ist, sendet Ihnen ElastiCache Serverless eine Benachrichtigung in der Konsole und ein Ereignis in. EventBridge Sie können Ihren Cache auf die neueste Hauptversion aktualisieren, indem Sie ihn mithilfe der Konsole, CLI oder API ändern und die neueste Engine-Version auswählen.
Versionsverwaltung für selbst ElastiCache entworfene Cluster
Wenn Sie mit selbst entworfenen ElastiCache Clustern arbeiten, können Sie steuern, wann die Software, die Ihren Cache-Cluster unterstützt, auf neue Versionen aktualisiert wird, die von unterstützt werden. ElastiCache Sie können steuern, wann Ihr Cache auf die neuesten verfügbaren MAJOR-, MINOR- und PATCH-Versionen aktualisiert werden soll. Sie starten Engine-Versions-Upgrades für Ihren Cluster oder Ihre Replikationsgruppe, indem Sie ihn bzw. sie ändern und eine neue Engine-Version angeben.
Sie können steuern, ob und wann die protokollkonforme Software, die Ihren Cache-Cluster unterstützt, auf neue Versionen aktualisiert wird, die von unterstützt werden. ElastiCache Mit diesem Maß an Kontrolle können Sie die Kompatibilität mit bestimmten Versionen aufrechterhalten, neue Versionen mit Ihrer Anwendung testen, bevor Sie sie für die Produktion bereitstellen, und Versions-Upgrades nach Ihren eigenen Vorgaben und Zeitplänen durchführen lassen.
Da Versions-Upgrades ggf. mit Kompatibilitätsrisiken verbunden sind, können sie nicht automatisch eingestellt werden. Sie müssen von Ihnen selbst installiert werden.
Valkey- und Redis OSS-Cluster
Anmerkung
-
Wenn ein Valkey- oder Redis OSS-Cluster in einer oder mehreren Regionen repliziert wird, wird die Engine-Version für sekundäre Regionen und dann für die primäre Region aktualisiert.
ElastiCache für Redis werden OSS-Versionen mit einer semantischen Version identifiziert, die aus einer MAJOR- und MINOR-Komponente besteht. In Redis OSS 6.2 ist die Hauptversion beispielsweise 6 und die Nebenversion 2. Beim Betrieb selbst entworfener Cluster wird ElastiCache für Redis OSS auch die PATCH-Komponente verfügbar gemacht, z. B. Redis OSS 6.2.1, und die Patch-Version ist 1.
MAJOR-Versionen stehen für API-inkompatible Änderungen und MINOR-Versionen für neue Funktionen, die abwärtskompatibel hinzugefügt wurden. PATCH-Versionen stehen für abwärtskompatible Fehlerbehebungen und nicht funktionale Änderungen.
Mit Valkey und Redis OSS initiieren Sie Engine-Versions-Upgrades für Ihren Cluster oder Ihre Replikationsgruppe, indem Sie ihn ändern und eine neue Engine-Version angeben. Weitere Informationen finden Sie unter Ändern einer Replikationsgruppe.
Memcached
Bei Memcached müssen Sie für ein Upgrade auf eine neuere Version Ihren Cache-Cluster ändern und die neue Engine-Version angeben, die Sie verwenden möchten. Das Upgrade auf eine neuere Memcached-Version ist ein destruktiver Prozess – Sie verlieren Ihre Daten und beginnen mit einem kalten Cache. Weitere Informationen finden Sie unter Einen ElastiCache Cluster ändern.
Beim Upgraden einer älteren Memcached-Version auf Memcached Version 1.4.33 oder höher sind folgende Anforderungen zu beachten. CreateCacheCluster und ModifyCacheCluster schlagen unter den folgenden Bedingungen fehl:
-
Wenn
slab_chunk_max > max_item_size. -
Wenn
max_item_size modulo slab_chunk_max != 0. -
Wenn
max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4).Der Wert
(max_cache_memory - memcached_connections_overhead)ist der für Daten nutzbare Speicher des Knotens. Weitere Informationen finden Sie unter Overhead von Memcached-Verbindungen.
Ü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 Serverless. ElastiCache
Ü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 nicht direkt von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis OSS (Clustermodus aktiviert) aktualisieren, wenn Sie Ihre Engine aktualisieren. 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. ElastiCache behält sich jedoch das Recht vor, Ihren Cluster für den unwahrscheinlichen Fall einer kritischen Sicherheitslücke im System oder in der Cache-Software zu patchen.
-
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.
