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

Übersicht

Wir aktualisieren unsere Amazon-ElastiCache-Flotte regelmäßig, wobei Patches und Upgrades nahtlos auf die Instances angewendet werden. Das wird auf eine der beiden folgenden Arten gehandhabt:

(a) ständige verwaltete Wartung und (b) Service-Updates. Derartige Wartungen und Service-Updates sind zum Einspielen von Updates und Upgrades erforderlich, die zur Steigerung von Sicherheit, Zuverlässigkeit und Betriebsleistung beitragen.

Die ständige verwaltete Wartung findet von Zeit zu Zeit und direkt in ihren Wartungsfenstern statt, ohne dass Sie irgendetwas dazu beitragen müssen.
Service-Updates bieten Ihnen die Flexibilität, sie selbst einspielen zu können. Sie sind zeitlich festgelegt und können ins Wartungsfenster geschoben werden, damit wir sie einspielen, wenn das Fälligkeitsdatum erreicht wird.

Sie haben die Möglichkeit zur eigenständigen Verwaltung von Updates zu einem beliebigen Zeitpunkt vor dem geplanten Wartungsfenster. Wenn Sie ein Update selbst planen, erhält Ihre Instance das Betriebssystemupdate, wenn Sie den Knoten neu starten. Ihr geplantes Wartungsfenster wird in diesem Fall abgebrochen.

Themen der Seite

Service-Updates
23
Updates im Rahmen der ständigen verwalteten Wartung
11

Service-Updates

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).

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.

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.

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.

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?

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

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.

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?“

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.

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

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.

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

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.

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.

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.

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.

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.

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. Ser Umfang von Updates wird durch die Service-Update-Attribute Engine und Engine Version angezeigt.

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.

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.

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.

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.

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.

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.

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ü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ü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.

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.

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.

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.

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 Szenarion 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.00 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.00 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.00 Uhr ersetzt.

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

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 Master-Knoten 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.

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