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.
Engine-Versionen und Upgrades
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.
Anmerkung
Wenn ein 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.
Versionsverwaltung für Serverless ElastiCache
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.
Sie starten Engine-Versions-Upgrades für Ihren Cluster oder Ihre Replikationsgruppe, indem Sie ihn bzw. sie ändern und eine neue Engine-Version angeben. Weitere Informationen finden Sie hier:
Ü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
Beachten Sie bei Upgrades eines selbst entworfenen Clusters die folgenden Ausführungen.
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.
Ab Redis OSS 6.0 wird ElastiCache (RedisOSS) eine einzige Version für jede OSS Redis-Nebenversion anbieten, 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 unterstützt ElastiCache (RedisOSS) das Umschalten zwischen Redis (Clustermodus deaktiviert) und Redis OSS (Clustermodus aktiviert). 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 beendet ElastiCache (RedisOSS) bestehende Client-Verbindungen. 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 Redis OSS (Clustermodus deaktiviert) auf Redis (Clustermodus aktiviert) aktualisieren, wenn Sie Ihre Engine aktualisieren. OSS Das folgende Verfahren zeigt Ihnen, wie Sie ein Upgrade von Redis OSS (Clustermodus deaktiviert) auf Redis OSS (Clustermodus aktiviert) durchführen.
So führen Sie ein Upgrade von einer Redis-Engine-Version OSS (Clustermodus deaktiviert) auf eine Redis-Engine-Version OSS (Clustermodus aktiviert) durch
-
Erstellen Sie eine Sicherungskopie Ihres Redis-Clusters oder Ihrer Redis-Replikationsgruppe OSS (Clustermodus deaktiviert). Weitere Informationen finden Sie unter Erstellen manueller Backups.
-
Verwenden Sie das Backup, um einen 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 Seeding eines neuen selbst entworfenen Clusters mit einem extern erstellten Backup.
-
Löschen Sie den alten Redis-Cluster oder die Replikationsgruppe OSS (Clustermodus deaktiviert). Weitere Informationen finden Sie unter Löschen eines Clusters oder Löschen einer Replikationsgruppe.
-
Skalieren Sie den neuen Redis-Cluster OSS (Clustermodus aktiviert) oder die neue Replikationsgruppe auf die Anzahl der Shards (Knotengruppen), die Sie benötigen. Weitere Informationen finden Sie unter Skalierung von Clustern in 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, OSS Redis ausreichend Speicher zur Verfügung zu stellen, wie unter beschrieben. Sicherstellen, dass Sie über genügend Arbeitsspeicher verfügen, um einen 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 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.
So führen Sie ein Upgrade von Engine-Versionen aus
Sie initiieren Versionsupgrades für Ihren Cluster oder Ihre Replikationsgruppe, indem Sie ihn mithilfe der ElastiCache Konsole AWS CLI, der oder der ändern ElastiCache API und eine neuere Engine-Version angeben. Weitere Informationen finden Sie unter den folgenden Themen.
So ändern Sie Cluster und Replikationsgruppen | |
---|---|
Cluster | Replikationsgruppen |
Mit dem AWS Management Console | Unter Verwendung der AWS Management Console |
Verwenden Sie AWS CLI | Verwenden des AWS CLI |
Verwenden der ElastiCache API | Verwenden der API ElastiCache |
Blockierte OSS Redis-Engine-Upgrades lösen
Wie in der folgenden Tabelle dargestellt, ist Ihr OSS Redis-Engine-Upgrade-Vorgang blockiert, wenn ein Scale-Up-Vorgang aussteht.
Ausstehende Vorgänge | Blockierte Vorgänge |
---|---|
Aufwärtsskalierung | Unmittelbares Engine-Upgrade |
Engine-Upgrade | Unmittelbares Aufwärtsskalieren |
Aufwärtsskalierung und Engine-Upgrade | Unmittelbares Aufwärtsskalieren |
Unmittelbares Engine-Upgrade |
Um ein blockiertes OSS Redis-Engine-Upgrade zu beheben
Führen Sie eine der folgenden Aktionen aus:
-
Planen Sie Ihren OSS Redis-Engine-Upgrade-Vorgang für das nächste Wartungsfenster, indem Sie das Kontrollkästchen Sofort anwenden deaktivieren.
Verwenden
--no-apply-immediately
Sie mit CLI dem. Mit demAPI, benutzeApplyImmediately=false
. -
Warten Sie bis zum nächsten Wartungsfenster (oder danach), um Ihr OSS Redis-Engine-Upgrade durchzuführen.
-
Fügen Sie dieser Cluster-Änderung den OSS Redis-Scale-Up-Vorgang hinzu, indem Sie das Kontrollkästchen Sofort anwenden aktivieren.
Verwenden
--apply-immediately
Sie mit CLI dem. Mit demAPI, benutzeApplyImmediately=true
.Dieser Ansatz bricht das Engine-Upgrade während des nächsten Wartungsfensters effektiv ab, indem es direkt ausgeführt wird.
-