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 Engines Valkey, Redis und Memcached aktualisiert wurden, aktualisieren möchten. OSS
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 Version 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 MAJOR Version verfügbar ist, sendet Ihnen ElastiCache Serverless eine Benachrichtigung in der Konsole und ein Ereignis in. EventBridge Sie können wählen, ob Sie Ihren Cache auf die neueste Hauptversion aktualisieren möchten, indem Sie Ihren Cache mithilfe der Konsole ändernCLI, oder API und die neueste Engine-Version auswählen.
Versionsverwaltung für selbst entworfene Cluster ElastiCache
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 Versionen und PATCH aktualisiert werden soll. MINOR 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-Cluster OSS
Anmerkung
-
Wenn ein Valkey- oder OSS Redis-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 (Redis-OSS) Versionen werden mit einer semantischen Version identifiziert, die eine UND-Komponente umfasst. MAJOR MINOR In Redis OSS 6.2 ist die Hauptversion beispielsweise 6 und die Nebenversion 2. Beim Betrieb selbst entworfener Cluster macht ElastiCache (RedisOSS) auch die PATCH Komponente verfügbar, z. B. Redis OSS 6.2.1, und die Patch-Version ist 1.
MAJORVersionen sind für API inkompatible Änderungen und MINOR Versionen für neue Funktionen, die abwärtskompatibel hinzugefügt wurden. PATCHVersionen sind für abwärtskompatible Bugfixes und nicht funktionale Änderungen vorgesehen.
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 OSS Redis-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 Valkey 7.2 und Redis OSS 6.0 ElastiCache wird für jede Nebenversion eine einzige Version angeboten, anstatt mehrere Patch-Versionen anzubieten.
Ab der OSS Redis-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 derselbe, kann jedoch während der DNS Ausbreitung eine längere Failover-Zeit in Anspruch nehmen (30—1 m).
-
Ab Redis OSS 7 wird ElastiCache das Umschalten zwischen Valkey oder Redis OSS (Clustermodus deaktiviert) und Valkey oder Redis (Clustermodus aktiviert) unterstützt. OSS
-
Der Upgrade-Prozess der Amazon ElastiCache (RedisOSS) Engine ist darauf ausgelegt, Ihre vorhandenen Daten bestmöglich beizubehalten, und erfordert eine erfolgreiche OSS Redis-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 OSS Redis-Clients mit wiederholten Fehlern 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 (Clustermodus aktiviert) aktualisieren, wenn Sie Ihre Engine OSS aktualisieren. Das folgende Verfahren zeigt Ihnen, wie Sie ein Upgrade von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis (Clustermodus aktiviert) durchführen. OSS
So führen Sie ein Upgrade von einer Valkey- oder Redis-Engine-Version OSS (Cluster-Modus deaktiviert) auf eine Valkey- oder OSS Redis-Engine-Version (Clustermodus aktiviert) durch
-
Erstellen Sie eine Sicherungskopie Ihres Valkey- oder Redis-Clusters oder Ihrer Replikationsgruppe OSS (Clustermodus deaktiviert). Weitere Informationen finden Sie unter Erstellen manueller Backups.
-
Verwenden Sie das Backup, um einen Valkey- oder Redis-Cluster OSS (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-Cluster oder die Redis-Cluster OSS (Cluster-Modus deaktiviert) oder die alte Replikationsgruppe. Weitere Informationen finden Sie unter Löschen eines Clusters in ElastiCache oder Löschen einer Replikationsgruppe.
-
Skalieren Sie den neuen Valkey- oder Redis-Cluster oder die Redis-Cluster OSS (Cluster-Modus aktiviert) oder die neue Replikationsgruppe 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 OSS Redis-Cluster und Cluster mit deaktiviertem Multi-AZ empfehlen wir, Redis ausreichend Speicher zur Verfügung zu stellen, wie unter beschrieben. OSS Stellen Sie sicher, dass Sie über genügend Speicherplatz verfügen, um einen Valkey- oder OSS Redis-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 OSS Redis-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.
