Hilfeseite zur verwalteten Wartung und zu Service-Updates in Amazon ElastiCache

F: Was sind Service-Updates in Amazon ElastiCache?

Service-Updates sind ein Feature in Amazon ElastiCache, mit der Sie bestimmte Service-Updates nach eigenem Ermessen anwenden können. Diese Updates sind entweder Sicherheitspatches oder kleinere Softwareupdates. Durch diese Updates werden Sicherheit, Zuverlässigkeit und Betriebsleistung Ihrer Cluster verbessert.

Der Wert dieser Service-Updates besteht darin, dass Sie steuern können, wann das Update eingespielt wird. So können Sie beispielsweise das Einspielen von Service-Updates verzögern, falls ein wichtiges geschäftliches Ereignis erfordert, dass die ElastiCache-Cluster rund um die Uhr verfügbar sind.

Informationen zu den einzelnen Service-Updates entnehmen Sie dem Wert des Attributs „Update Description“ (Update-Beschreibung). 

F: Wie werde ich über verfügbare ElastiCache-Service-Updates benachrichtigt?

Sobald Service-Updates für Ihre Cluster verfügbar sind, werden Sie über diverse Kanäle darüber benachrichtigt, z. B. über die Amazon-ElastiCache-Konsole, per E-Mail, über Amazon Simple Notification Service (SNS), AWS Personal Health Dashboard und Amazon CloudWatch Events.

F: Wie unterscheidet sich das Einspielen von Updates im Wartungsfenster von Service-Updates?

Updates, die über unsere ständige verwaltete Wartungsfunktion zur Verfügung gestellt werden, sind von den Service-Updates klar abgetrennt. Updates, die über die ständige verwaltete Wartung eingespielt werden, werden direkt in Ihr Wartungsfenster gelegt, ohne dass Sie etwas dazu beitragen müssen. Service-Updates sind zeitlich festgelegt und bieten Ihnen die Möglichkeit, selbst zu entscheiden, wann Sie sie bis zum empfohlenen Einspieldatum (Recommended Apply by Date) einspielen möchten. Wenn sie bis dahin nicht eingespielt sind, verschiebt ElastiCache diese Updates unter Umständen in Ihr Wartungsfenster.

F: Wie stelle ich fest, ob ich die verfügbaren Service-Updates einspielen sollte?

Wenn Ihr ElastiCache-Cluster an einem HIPAA-, PCI- oder FedRAMP-Compliance-Programm teilnimmt müssen Sie die Service-Updates bis zum jeweiligen empfohlenen Einspieldatum einspielen, um die Compliance zu wahren. Weitere Informationen finden Sie unter Self-Service-Sicherheits-Updates für Compliance.

Für andere Cluster empfehlen wir, dass Sie die Service-Updates dem Rhythmus Ihres Unternehmens entsprechend einspielen. Selbst, wenn Sie nicht in der Lage sind, ein Service-Update bis zum jeweiligen empfohlenen Einspieldatum (Recommended Apply by Date) einzuspielen, sind Sie in der Lage, es bis zum Update-Ablaufdatum (Update Expiration Date) einzuspielen. Allerdings kann sich das Ablaufdatum des Updates, abhängig von der Verfügbarkeit neuer Updates, jederzeit ändern.

F: Worin bestehen die Auswirkungen des Einspielens eines Service-Updates in ElastiCache-Cluster? Verliere ich Daten oder die Verbindung zu meinen Clustern?

Wenn Sie oder Amazon ElastiCache ein Service-Update auf einen oder mehrere Cluster anwenden, wird das Update auf nicht mehr als einen Knoten in jedem Shard angewendet, bis alle ausgewählten Cluster aktualisiert sind. Die Knoten, die aktualisiert werden, haben eine Ausfallzeit von wenigen Sekunden, während der Rest des Clusters den Datenverkehr weiterhin bedient.

• Die Konfiguration des Clusters wird nicht verändert.
• In den CloudWatch-Metriken tritt eine Verzögerung auf, die jedoch schnellstmöglich aufgeholt wird.

Service-Updates werden genauso angewendet wie „Updates im Rahmen der ständigen verwalten Wartung“, über den Austausch von Knoten. Bitte lesen Sie die folgenden Fragen im Abschnitt Updates im Rahmen der ständigen verwalten Wartung auf dieser Seite, um zu erfahren, wie das Update angewendet wird und wie Sie Ihre Anwendung vorbereiten können, um die Auswirkungen zu minimieren.

• Wie wirkt sich ein Knotenaustausch auf meine Anwendung aus?
  
• Welche bewährten Methoden sollte ich für einen reibungslosen Austausch und für minimalen Datenverlust anwenden?
• Mit welchen bewährten Methoden bei der Clientkonfiguration lassen sich Anwendungsausfälle bei der Wartung minimieren?
  

F: Tritt in Zusammenhang mit dem Einspielen des Updates bei ElastiCache für Memcached-Cluster eine Ausfallzeit auf?

Ja, der Knoten wird durch einen neuen, leeren Knoten ersetzt. Der Inhalt des Cache wird nicht mehr vorhanden sein.

F: Kann ich das Einspielen von Service-Updates verweigern?

Sie können feststellen, ob Sie ein Service-Update abbestellen können, indem Sie den Wert des Attributs „Automatische Aktualisierung nach Fälligkeitsdatum“ überprüfen. Wenn der Wert des Attributs „Automatische Aktualisierung nach Fälligkeitsdatum“ eines Service-Updates „nein“ ist, kann dieses Service-Update deaktiviert werden. Wenn der Wert des Attributs „Automatische Aktualisierung nach Fälligkeitsdatum“ eines Service-Updates jedoch „Ja“ ist und die empfohlene Frist für „Bis zum folgenden Datum anwenden“ abgelaufen ist, plant ElastiCache das Service-Update während eines bevorstehenden Wartungsfensters automatisch für alle verbleibenden Cluster. Dieses automatische Service-Update wird vor dem „Ablaufdatum des Updates“ geplant und Sie erhalten eine Woche vor dem Update eine Benachrichtigung mit der geplanten Uhrzeit. Wir empfehlen dringend, Sicherheitsupdates zu installieren, auch wenn sie deaktiviert werden können.  Wenn Sie das Service-Update für die verbleibenden Cluster vor dem Wartungsfenster einspielen, spielt ElastiCache das Service-Update während des Wartungsfensters nicht noch einmal ein.

F: Warum könne die Service-Updates nicht direkt von ElastiCache im Rahmen von Wartungsfenstern eingespielt werden?

Der Zweck von Service-Updates besteht darin, Ihnen die Möglichkeit zu geben, flexibel zu entscheiden, wann sie eingespielt werden. Cluster, die nicht an den von ElastiCache unterstützten Compliance-Programmen teilnehmen, müssen diese Updates nicht einspielen bzw. können Sie über das Jahr verteilt mit geringerer Häufigkeit einspielen. Die trifft nur zu, wenn das Service-Update-Attribut Auto-Update after Due Date (Nach Fälligkeitsdatum automatisch aktualisieren) den Wert no (Nein) aufweist. Weitere Informationen finden Sie im Abschnitt „Kann ich das Einspielen von Service-Updates verweigern?“

F: Kann ich Service-Updates verwenden, um auf die Amazon ElastiCache-Servicewartung zu verzichten und die verfügbaren Updates selbst einzuspielen?

Nein, Service-Updates und die von Amazon ElastiCache im Rahmen der ständigen verwalteten Wartung direkt in den Wartungsfenstern Ihrer Cluster eingespielten Updates schließen sich gegenseitig aus.

F: Wo befindet sich die Liste aller Service-Update-Attribute?

Eine vollständige Liste der Attribute und ihrer Beschreibungen finden Sie unter Anwenden der Self-Service-Updates.

F: Verfügen alle Service-Updates über dieselbe Einspiel-Timeline?

Das Service-Update-Attribut Severity (Dringlichkeit) liefert einen Anhaltspunkt dazu, wie bald verfügbare Service-Updates eingespielt werden sollten. Es weist die folgenden Werte auf (geordnet nach Priorität):

1. critical (kritisch): Sollten sofort eingespielt werden (innerhalb von 14 Tagen oder weniger)
2. important (wichtig): Sollten eingespielt werden, sobald der Verlauf der Geschäftstätigkeit es ermöglicht (innerhalb von 30 Tagen oder weniger)
3. medium (mittel): Sollten innerhalb von 60 Tagen oder weniger eingespielt werden
4. low (niedrig): Sollten innerhalb von 90 Tagen oder weniger eingespielt werden

Weitere Details finden Sie in der öffentlichen Dokumentation zum Anwenden von Updates.

F: Wie oft werden Service-Updates veröffentlicht?

Der Veröffentlichungszeitplan orientiert sich an der Wichtigkeit der Service-Updates.

Q: Was ist das Attribut Service Update SLA Met (Service-Update-SLA erfüllt)?

Diese Attribut zeigt, ob der Cluster bis zum empfohlenen Einspieldatum (Recommended Apply by Date) aktualisiert wurde. Falls ein Service-Update nach dem empfohlenen Einspieldatum eingespielt wurde, wird für das Attribut Service-Update-SLA erfüllt der Wert Nein festgelegt.

Diese Informationen sind relevant für Amazon-ElastiCache-Cluster, die an HIPAA-, PCI- und FedRAMP-Compliance-Programmen teilnehmen. Weitere Informationen finden Sie unter Self-Service-Sicherheits-Updates für Compliance.

F: Falls ich ein Service-Update verpasst habe, kann ich sie später noch einspielen?

Ja. Sofern im Service-Update-Attribut Description (Beschreibung) nicht anders beschrieben, sind Service-Updates immer kumulativ: Falls Sie sie nicht bis zum Update-Ablaufdatum (Update Expiration Date) einspielen, sind sie im nächsten Service-Update enthalten. Service-Updates des Typs security (Sicherheit) fallen in diese kumulative Kategorie.

F: Kann ich Service-Updates bei bestimmten Knoten eines ElastiCache-Clusters einspielen?

Nein, Service-Updates werden auf Clusterebene eingespielt. Falls Sie ein laufendes Update abbrechen, kann es vorkommen, dass einige Knoten aktualisiert sind und manche nicht. In diesem Fall wird der Cluster weiterhin in der Liste der Cluster aufgeführt, auf die das Service-Update noch eingespielt werden muss. Der Cluster kann ganz normal weiter verwendet werden.

F: Warum wurde der Updatestatus hinsichtlich eines Knotens meiner ElastiCache-Cluster von „not-applied“ (nicht eingespielt) in „complete“ (abgeschlossen) geändert, obwohl ich das Service-Update nicht eingespielt habe?

Dies kann in zwei Fällen vorkommen:

(a) Wenn Sie das Einspielen eines optionalen Service-Updates verpasst haben und das Update nun den Status „expired“ (abgelaufen) aufweist. Aus diesem Grund müssen für Server, die an Compliance-Programmen teilnehmen, stets alle Service-Updates eingespielt werden.
(b) Falls Ihre Knoten aus irgendeinem anderen Grund ausgetauscht wurden, z. B. einer geplanten Wartung oder einem Knoten-Failover, stellt Amazon ElastiCache neue Knoten bereit, bei denen die neuesten Service-Updates schon eingespielt sind.

In beiden Fällen kann der Cluster ganz normal weiter verwendet werden.

F: Was, wenn ich bei Knoten abgelaufene Service-Updates einspielen möchte? Muss ich auf das nächste Service-Update warten?

Neue Knoten enthalten alle anwendbaren Service-Updates, daher können Sie die bestehenden Knoten, die nicht anhand der letzten Service-Updates aktualisiert wurden, manuell austauschen.

F: Sind die Service-Updates spezifisch auf die jeweilige Engine ausgelegt?

Ja. Service-Updates können nur für Redis OSS, nur für Memcached oder für sowohl Redis OSS als auch Memcached verfügbar sein. Der Umfang von Updates wird durch die Service-Update-Attribute Engine und Engine Version angezeigt.

F: Kann ich einen anderen Zeitpunkt für das geplante Service-Update festlegen? Was geschieht mit dem geplanten Update, wenn ich das Wartungsfenster ändere?

Ja, Sie können das Service-Update aufschieben, indem Sie das Wartungsfenster ändern. Das geplante Update wird nur dann auf den Cluster angewendet, wenn das geplante Datum mit dem Wartungsfenster des Clusters übereinstimmt. Wenn Sie das Wartungsfenster ändern und das geplante Datum verstrichen ist, wird das Service-Update auf das neu festgelegte Zeitfenster in den folgenden Wochen verschoben. Sie erhalten eine Woche vor Erreichen des neuen Termins eine neue Benachrichtigung.

Sicherheit bei AWS ist eine geteilte Verantwortung. Wir empfehlen Ihnen dringend, das Update so schnell wie möglich durchzuführen.

F: Warum habe ich Benachrichtigungen für mehrere Updates für denselben Cluster erhalten? Muss ich alle anwenden?

Ihr Cluster kann an verschiedenen Service-Updates beteiligt sein. Für die meisten Updates ist es nicht erforderlich, sie separat anzuwenden. Wenn Sie ein Update auf Ihren Cluster anwenden, werden die anderen Updates gegebenenfalls als abgeschlossen markiert. Möglicherweise müssen Sie mehrere Updates separat auf den Cluster anwenden, wenn der Status nicht automatisch auf „abgeschlossen“ wechselt.

F: Wie werden Service-Updates gemäß dem „empfohlenen Einspieldatum“ (Recommended Apply By Date) geplant und angewendet?

ElastiCache plant das Service-Update auf den verbleibenden Clustern nach dem empfohlenen Einspieldatum (Recommended Apply By Date), wenn das Attribut „Auto-Update after Due Date“ (Nach Fälligkeitsdatum automatisch aktualisieren) den Wert „yes“ (Ja) hat. Das Update wird im Wartungsfenster des Clusters geplant und Sie erhalten eine Woche im Voraus eine neue Benachrichtigung mit dem geplanten Datum, bevor die Updates angewendet werden.

Ein geplantes Service-Update wird genauso auf die Cluster angewendet wie „Updates im Rahmen der ständigen verwalten Wartung“. Im folgenden Abschnitt erfahren Sie, wie das Update angewendet wird, wie Sie das geplante Update ändern können und wie Sie Ihre Anwendung auf ein geplantes Update vorbereiten können, um die Auswirkungen zu minimieren.

F: Was geschieht, wenn das Service-Update nicht innerhalb eines einzigen Wartungsfensters auf den gesamten Cluster angewendet werden kann?

Um die Stabilität des Clusters aufrechtzuerhalten, wendet ElastiCache Updates immer nur auf einen Knoten innerhalb jedes Shards an. Wenn das Service-Update nicht innerhalb eines einzigen Wartungsfensters auf den gesamten Cluster angewendet werden kann, wird es in den nächsten Wartungsfenstern fortgesetzt. Sie erhalten neue Benachrichtigungen über den nächsten geplanten Termin und können sich entsprechend vorbereiten.

F: Kann ich ein Service-Update rückgängig machen?

Der Kunde kann das Service-Update nicht mehr rückgängig machen, sobald es gestartet ist. Wenn Sie nach der Anwendung eines Service-Updates ein Problem feststellen, wenden Sie sich bitte an das AWS-Support-Team.

Was sind Updates im Rahmen der ständigen verwalteten Wartung?

Diese Updates sind verpflichtend und werden direkt in Ihren Wartungsfenstern eingespielt, ohne dass Sie etwas dazu beitragen müssen. Diese Updates sind von den Service-Updates klar abgetrennt.

F: Wie lange dauert der Austausch eines Knotens?

Ein Austausch dauert in der Regel nur wenige Sekunden. Der Austausch kann in bestimmten Instance-Konfigurationen und Verkehrsmustern länger dauern. Beispielsweise haben Redis-OSS-Primärknoten möglicherweise nicht genügend freien Speicherplatz und erfahren einen hohen Schreibverkehr. Wenn ein leeres Replikat von diesem primären Knoten synchronisiert wird, kann es sein, dass dem Primärknoten der bei dem Versuch, die eingehenden Schreibvorgänge zu adressieren und das Replikat zu synchronisieren, der Speicher ausgeht. In diesem Fall trennt der Master das Replikat und startet den Synchronisationsvorgang neu. Es kann mehrere Versuche dauern, bis das Replikat erfolgreich synchronisiert wurde. Es kann auch passieren, dass Replikate gar nicht synchronisiert werden, sollte der eingehende Schreibverkehr weiterhin hoch bleiben.

Memcached-Knoten müssen nicht synchronisiert werden, sodass ihre Ersetzung schneller abgeschlossen ist, unabhängig von der Knotengröße.

F: Wie wirkt sich ein Knotenaustausch auf meine Anwendung aus?

Für Redis-OSS-Knoten soll der Austausch Ihre vorhandenen Daten möglichst beibehalten. Eine erfolgreiche Replikation ist erforderlich. Für Cluster mit nur einem Knoten erstellt ElastiCache dynamisch ein Replikat, repliziert die Daten und führt dann einen Failover aus. Für Replikationsgruppen, die aus mehreren Knoten bestehen, ersetzt ElastiCache die vorhandenen Replikate und synchronisiert Daten von den primären auf den neuen Replikaten. Wenn Multi-AZ mit automatischem Failover aktiviert ist, löst der Austausch des Primärservers einen Failover auf ein Lese-Replikat aus. Bei Cluster-Konfigurationen, die Cluster-Clients verwenden, und Nicht-Cluster-Konfigurationen mit aktiviertem automatischen Failover wird der geplante Knotenaustausch ausgeführt, während der Cluster eingehende Schreibanforderungen bedient. Wenn Multi-AZ deaktiviert ist, ersetzt ElastiCache das primäre Replikat und synchronisiert dann die Daten aus einem Lesereplikat. Während dieser Zeit ist der primäre Knoten nicht verfügbar; dies führt zu einer längeren Schreibunterbrechung.

Für Memcached-Knoten hat der Austausch einen leeren neuen Knoten zur Folge. Der aktuelle Knoten wird außerdem beendet. Während der Umstellung ist der neue Knoten für kurze Zeit nicht verfügbar. Nach der Umstellung werden Sie möglicherweise eine Leistungsbeeinträchtigung Ihrer Anwendung beobachten, während der leere neue Knoten mit Cachedaten gefüllt wird.

F: Welche bewährten Methoden sollte ich für einen reibungslosen Austausch und für minimalen Datenverlust anwenden?

Für Redis-OSS-Knoten soll der Austausch Ihre vorhandenen Daten möglichst beibehalten. Eine erfolgreiche Replikation ist erforderlich. Wir versuchen, gerade genug Knoten aus demselben Cluster gleichzeitig zu ersetzen, um den Cluster stabil zu halten. Sie können Primär-Replikate und Read Replicas in verschiedenen Availability Zones bereitstellen. In diesem Fall werden beim Ersetzen eines Knotens die Daten von einem Peer-Knoten in einer anderen Availability Zone synchronisiert. Wir empfehlen außerdem, dass Sie Ihre Redis-OSS-Version auf 5.0.6 oder höher aktualisieren, da diese Engine-Versionen eine verbesserte Stabilität aufweisen und es Ihren Clustern ermöglichen, eingehende Schreibanfragen während der Patching-Aktivitäten kontinuierlich zu bedienen, wenn sie Auto-Failover aktiviert haben. Wenn Ihre Konfiguration nur ein primäres und ein einzelnes Replikat pro Shard umfasst, empfehlen wir, vor dem Patching zusätzliche Replikate hinzuzufügen. Dadurch werden eingeschränkte Verfügbarkeit und Risiken während des Patching-Prozesses vermieden. Für Cluster mit nur einem Knoten sollte Redis OSS ausreichend Arbeitsspeicher zur Verfügung gestellt werden, wie hier beschrieben ist. Für Replikationsgruppen mit mehreren Knoten sollten Sie außerdem den Austausch in einem Zeitraum mit geringem eingehenden Schreibdatenverkehr planen.

Planen Sie das Wartungsfenster bei Memcached-Knoten während eines Zeitraums mit geringem eingehenden Schreibverkehr, testen Sie Ihre Anwendung auf Failover und verwenden Sie den von ElastiCache bereitgestellten „intelligenteren“ Client. Sie können Datenverlust nicht vermeiden, da Memcached Daten nur im Speicher hat.

F: Mit welchen bewährten Methoden bei der Clientkonfiguration lassen sich Anwendungsausfälle bei der Wartung minimieren?

Bei Redis OSS verspricht eine Konfiguration im Clustermodus die beste Verfügbarkeit während verwalteter und nicht verwalteter Vorgänge. Daher wird in jedem Fall ein Client empfohlen, der vom Clustermodus unterstützt wird und sich mit dem Erkennungsendpunkt des Clusters verbindet. Bei deaktiviertem Clustermodus wird für alle Schreibvorgänge der primäre Endpunkt empfohlen. Die einzelnen Knotenendpunkte der Replica-Knoten können für alle Lesevorgänge verwendet werden. Bei einem Cluster mit automatischem Failover kann sich der primäre Knoten ändern. Die Anwendung sollte daher die Rolle des Knoten überprüfen und alle Leseendpunkte aktualisieren, um sicherzustellen, dass der Master nicht überlastet wird. Bei einem Cluster mit deaktiviertem automatischen Failover ändert sich die Rolle des Knoten nicht. Die Ausfallzeiten bei verwalteten oder nicht verwalteten Vorgängen sind jedoch im Vergleich zu Clustern mit automatischem Failover größer. Vermeiden Sie die Weiterleitung von Leseanforderungen nur an Lese-Replikate. Wenn Sie Ihren Client so konfigurieren, dass Leseanforderungen nur an Lese-Replikate weitergeleitet werden, stellen Sie sicher, dass Sie über mindestens zwei Lese-Replikate verfügen, um Leseunterbrechungen während der Wartung zu vermeiden.

F: Wie kann ich Knotenersetzungen selbst verwalten?

Sie sollten es ElastiCache ermöglichen, den Austausch für Ihren Knoten innerhalb des geplanten Wartungsfensters einzurichten. Über das wöchentliche Wartungsfenster können Sie beim Anlegen eines ElastiCache-Clusters Ihre bevorzugte Zeit für das Ersetzen angeben. Für das Ändern des Wartungsfenster auf eine passendere Zeit können Sie die ModifyCacheCluster-API verwenden oder in der ElastiCache Management Console auf "Modify" klicken.

Wenn Sie sich dafür entscheiden, den Austausch selbst vorzunehmen, können Sie je nach Anwendungsfall und Cluster-Konfiguration eine Vielzahl von Aktionen vornehmen:

• Ändern Sie das Wartungsfenster.
• Starten Sie Ihre Instance mithilfe des Prozesses Sicherung und Wiederherstellung erneut.
• Wenn in Ihrer Cluster-Konfiguration der Cluster-Modus deaktiviert ist

o Ersetzen Sie ein Lesereplikat (Cluster-Modus deaktiviert) – Eine Prozedur für das manuelle Ersetzen eines Lesereplikats in einer Replikationsgruppe.
o Ersetzen Sie den Primärknoten (Cluster-Modus deaktiviert) – Eine Prozedur für das manuelle Ersetzen des Primärknotens in einer Replikationsgruppe.
o Ersetzen Sie einen eigenständigen Knoten (Cluster-Modus deaktiviert) – Zwei verschiedene Prozeduren für das Ersetzen eines eigenständigen Knotens.

• Wenn in Ihrer Cluster-Konfiguration der Cluster-Modus aktiviert ist

o Ersetzen Sie einen Knotens im Cluster durch einen oder mehrere Shards – Sie können zum Ersetzen der Knoten entweder die Backup- und Wiederherstellungsfunktion nutzen oder nach oben und anschließend nach unten skalieren.

Weitere Anweisungen zu diesen Optionen finden Sie auf der Seite Actions You Can Take When a Node is Scheduled for Replacement.

Bei Memcached können Sie die Cluster einfach löschen und neu erstellen. Nach dem Austausch sollte der Instance kein geplantes Ereignis mehr zugeordnet sein.

F: Wie erhalte ich Informationen zu bevorstehenden geplanten Austauschprozessen?

Um Benachrichtigungen zu erhalten, können Sie Amazon-SNS-Benachrichtigungen für wichtige Ereignisse, wie z. B. ein geplantes Ersatzereignis, einrichten. Dazu können Sie den Abschnitt „Ereignisse“ der ElastiCache-Managementkonsole oder die API „describe-events“ verwenden, um nach dem kommenden Ereignis „ElastiCache:NodeReplacementScheduled“ zu suchen.

Zum Einrichten von SNS-Benachrichtigungen nutzen Sie die hier bereitgestellten Informationen.

F: Kann ich einen besser geeigneten Zeitpunkt für die geplante Wartung festlegen?

Ja. Sie können das Wartungsfenster Ihres Clusters auf eine andere Zeit verlegen. Für das Ändern des Wartungsfenster auf eine passendere Zeit können Sie die ModifyCacheCluster-API (ModifyCacheCluster oder ModifyReplicationGroup) verwenden oder in der ElastiCache Management Console auf "Modify" klicken.

Nachdem Sie Ihr Wartungsfenster geändert haben, wird der ElastiCache-Service Ihren Knoten für die wöchentliche Wartung im neu definierten Zeitfenster einplanen. Wie sich Änderungen auswirken, sehen in den folgenden Beispielen.

Lassen Sie uns annehmen,

es ist gerade Donnerstag der 9. November 15:00 Uhr und das nächste Wartungsfenster ist für Freitag den 10. November um 17:00 Uhr vorgesehen. Die folgenden drei Szenarien führen zu unterschiedlichen Ergebnissen:

Im ersten Fall verlegen Sie das Zeitfenster auf Freitag 16 Uhr (der Zeitpunkt liegt nach dem aktuellen Beispieldatum, aber vor dem nächsten geplanten Zeitfenster). Der Knoten wird dann am Freitag, den 10. November um 16 Uhr ersetzt.
Im zweiten Fall verlegen Sie das Zeitfenster auf Samstag, 16 Uhr (der Zeitpunkt liegt nach dem aktuellen Beispieldatum und nach dem nächsten ursprünglich geplanten Zeitfenster). Der Knoten wird dann am Samstag, den 11. November um 16 Uhr ersetzt.
Im dritten Fall verlegen Sie das Zeitfenster auf Mittwoch, 16 Uhr (früher in der Woche als das aktuelle Beispieldatum). Der Knoten wird dann am nächsten Mittwoch, den 15. November um 16 Uhr ersetzt.

F: Warum erfolgt ein Knotenaustausch?

Ein Austausch ist erforderlich, um obligatorische Softwareupdates auf dem zugrunde liegenden Host zu installieren. Durch Updates werden Sicherheit, Zuverlässigkeit und Betriebsleistung verbessert.

F: Beeinflussen diese Ersetzungen meine Knoten in mehreren Availability Zones zur gleichen Zeit?

Es kann sein, dass wir mehrere Knoten aus demselben Cluster ersetzen. Dies hängt von der Clusterkonfiguration ab. Grundsätzlich wird darauf geachtet, das Clusters stabil zu halten. In Clustern mit Sharding achten wir darauf, im gleichen Shard nicht gleichzeitig mehrere Knoten zu ersetzen. Darüber hinaus achten wir darauf, in allen Shards die Mehrheit der Hauptknoten im Cluster nicht zu ersetzen.
Damit die Clusterstabilität nicht gefährdet wird, versuchen wir in Clustern ohne Sharding, die Ersetzung der Knoten so weit wie möglich über die Wartungsfenster zu staffeln.

F: Können die Knoten in verschiedenen Clustern aus verschiedenen Regionen gleichzeitig ersetzt werden?

Ja, es ist möglich, dass diese Knoten gleichzeitig ersetzt werden, wenn für diese Cluster dasselbe Wartungsfenster festgelegt wurde.