Wartung von Amazon DocumentDB

Amazon DocumentDB führt regelmäßig zwei Arten von Wartungsarbeiten durch:

Engine-Patches und Betriebssystem-Updates verwenden dieselben drei Lebenszykluskategorien — optional , erforderlich und erzwungen — mit derselben Benachrichtigung und demselben Anwendungsverhalten für jede Kategorie. Engine-Versionen haben auch eine vierte Kategorie: Nebenversionen, auf die Sie manuell aktualisieren. Die Kategorien sind:

Engine-Patches werden in einer einzigen Kategorie (optional, erforderlich oder erzwungen) veröffentlicht und bleiben dort. Fortschritte bei Betriebssystemupdates: Die meisten sind zunächst optional und werden, wenn sie nicht angewendet werden, in die Kategorie „Erforderlich“ und schließlich in die Kategorie „Erzwingung“ übergehen. Der genaue Zeitpunkt hängt vom Patch ab und wird in der AHD-Benachrichtigung und in den von zurückgegebenen Datumsfeldern veröffentlicht describe-pending-maintenance-actions (sieheTermine anwenden). In den Amazon DocumentDB-Versionshinweisen werden diese Kategorienamen verwendet, wenn Änderungen an der Engine angekündigt werden.

Durch das Anwenden eines Engine-Patches wird der Cluster kurzzeitig offline geschaltet. Im Rest dieses Themas wird beschrieben, wie Wartungsfenster funktionieren, wie Sie ausstehende Arbeiten finden, wie Engine-Patches und Nebenversionen angewendet werden, wie Betriebssystemupdates funktionieren und wie spezielle Verfahren für globale Cluster behandelt werden.

Wartungsmaßnahmen für Amazon DocumentDB

Die folgenden Wartungsmaßnahmen gelten für Amazon DocumentDB-Cluster:

Die folgenden Wartungsmaßnahmen gelten für Amazon DocumentDB-Instances:

Versionsnummerierung der Engine

Amazon DocumentDB verwendet zwei separate Versionskennungen:

Sie können die Engine-Version anhand des Präfixes der Engine-Patch-Version ermitteln, wie in der folgenden Tabelle dargestellt.

Um die Patch-Version zu überprüfen, auf der Ihr Cluster ausgeführt wird, stellen Sie eine Verbindung her und führen db.runCommand({getEngineVersion: 1}) Sie ihn aus.

Eine Liste der veröffentlichten Engine-Patch-Versionen und deren Inhalt finden Sie unterVersionshinweise.

Verwaltung Ihrer Amazon DocumentDB-Wartungsfenster

Jeder Cluster und jede Instance hat ihr eigenes wöchentliches Wartungsfenster von 30 Minuten — den Zeitraum, in dem geplante Änderungen und Software-Patches ausgeführt werden. Die meisten Ereignisse werden innerhalb von 30 Minuten abgeschlossen; größere Ereignisse können länger dauern.

Wenn Sie bei der Erstellung der Ressource kein Zeitfenster wählen, weist Amazon DocumentDB innerhalb eines für die Region definierten 8-stündigen Tagesblocks an einem zufällig ausgewählten Tag eines nach dem Zufallsprinzip zu. Wählen Sie Fenster, die die Auswirkungen auf Ihre Anwendung so gering wie möglich halten, z. B. abends oder am Wochenende.

Für Upgrades der Datenbank-Engine verwendet Amazon DocumentDB das Fenster des Clusters, nicht die Fenster einzelner Instances.

Die folgende Tabelle zeigt die Standard-Zeitblöcke pro Region.

Ändern Sie Ihre Amazon DocumentDB-Wartungsfenster

Wählen Sie das Fenster mit dem niedrigsten Verkehrsaufkommen, das Sie können, und passen Sie es im Laufe der Zeit an, wenn sich Ihre Verkehrsmuster ändern. Der Cluster oder die Instance ist während des Zeitfensters nur dann nicht verfügbar, wenn eine Systemänderung — z. B. ein Scale-Storage-Vorgang oder eine Änderung der Instance-Klasse — einen Ausfall erfordert, und zwar nur so lange, wie diese Änderung tatsächlich erforderlich ist.

Benachrichtigungen für Amazon DocumentDB-Engine-Patches

Wenn ein erforderlicher Engine-Patch in einer AWS Region verfügbar wird, erhält jedes AWS Konto mit einem betroffenen Amazon DocumentDB-Cluster in dieser Region eine Benachrichtigung über das Health Dashboard (AHD) und per E-Mail (gesendet an die Root-Benutzeradresse des AWS Kontos). Eine Benachrichtigung wird pro betroffener Amazon DocumentDB-Engine-Version zugestellt. Sie finden sie im AHD unter Geplante Änderungen. In jeder Benachrichtigung sind der Zeitpunkt der Patch-Verfügbarkeit, der Zeitplan für die automatische Anwendung, die betroffenen Cluster und die Versionshinweise aufgeführt.

Für erforderliche Engine-Patches gilt eine einzige Vorlaufzeit von etwa 30 Tagen. Wenn ein Patch in Ihrer Region verfügbar ist, sendet Amazon DocumentDB die oben beschriebene Benachrichtigung. Zu diesem Zeitpunkt AutoAppliedAfterDate ist der Patch auf etwa 30 Tage später festgelegt. Bis zu diesem Datum steht der Patch noch aus: Sie können ihn jederzeit anwenden oder ihn verschieben, indem Sie das Wartungsfenster Ihres Clusters auf einen späteren Tag verschieben. An oder nach dem wird der AutoAppliedAfterDate Patch während des nächsten Wartungsfensters für den Cluster automatisch angewendet.

Beispiel: Ein erforderlicher Patch, der am 1. Juni 2026 verfügbar wird, hat einen Gültigkeitszeitraum AutoAppliedAfterDate von ungefähr dem 1. Juli 2026. Sie erhalten die Benachrichtigung am 1. Juni 2026, und wenn Sie keine Maßnahmen ergreifen, wird der Patch während des ersten Wartungsfensters Ihres Clusters am oder nach dem 1. Juli 2026 automatisch angewendet.

Nach Erhalt der Benachrichtigung haben Sie zwei Möglichkeiten: Sie können den Patch vor dem Datum der automatischen Anwendung selbst anwenden oder warten, bis er während eines bevorstehenden Wartungsfensters automatisch angewendet wird (Standardeinstellung). Um sich selbst zu installieren, öffnen Sie die Registerkarte Wartung und Backups des Clusters und suchen Sie nach dem entsprechenden Eintrag. system-update

Optionale Patches und neue Nebenversionen generieren keine AHD- oder E-Mail-Benachrichtigungen. Um sie zu verfolgen, schauen Sie sich die Amazon DocumentDB-Versionshinweise an.

Erzwungene Patches (die seltenste Kategorie, die den kritischsten Sicherheitsupdates vorbehalten ist) werden ebenfalls per AHD und E-Mail angekündigt. Im Gegensatz zu erforderlichen Patches werden sie außerhalb Ihres Wartungsfensters angewendet, sodass das obige Beispiel für die automatische Anwendung nicht zutrifft.

Programmgesteuertes Reagieren auf Patch-Benachrichtigungen

AWS Health ist in Amazon integriert EventBridge, sodass Sie ereignisgesteuerte Anwendungen für mehr als 20 Ziele erstellen können, einschließlich AWS Lambda Amazon Simple Queue Service (SQS). Um programmgesteuert auf die Verfügbarkeit von Engine-Patches zu reagieren, konfigurieren Sie die Konfiguration entsprechend dem Ereignis. EventBridge AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_SCHEDULED Von dort aus können Sie Eventdaten erfassen, zusätzliche Ereignisse auslösen, Push-Benachrichtigungen über das versenden oder jede andere Aktion ergreifen AWS Console Mobile Application, die Sie benötigen.

Wenn Amazon DocumentDB einen Patch storniert (selten), erhalten Sie eine AHD-Benachrichtigung und eine E-Mail über die Kündigung. Verwenden Sie den AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_CANCELLED Eventcode bei Amazon EventBridge , um diesen Fall zu bearbeiten. Weitere Informationen zum Schreiben von Regeln finden Sie im EventBridge Amazon-Benutzerhandbuch.

Ausstehende Wartungsmaßnahmen für Amazon DocumentDB anzeigen

Verwenden Sie AWS-Managementkonsole oder die AWS CLI , um zu überprüfen, welche Wartungsarbeiten für einen Cluster oder eine Instance ausstehen.

Ausstehende Updates werden mit dem Aktionstyp angezeigtsystem-update, der sowohl Engine-Patches als auch Betriebssystemupdates abdeckt.

Wenn ein Update aussteht, können Sie:

Das Wartungsfenster steuert, wann ausstehende Operationen beginnen, nicht, wie lange sie dauern, bis sie abgeschlossen sind.

Termine anwenden

Für jede ausstehende Wartungsmaßnahme gelten bis zu drei Anwendungsdaten. Sie erscheinen in der AWS CLI Ausgabe für describe-pending-maintenance-actions und geben an, wann die Aktion ausgeführt wird. Felder sind null für die optionale Wartung vorgesehen.

Um eine ausstehende Aktion aufzuschieben, verschieben Sie Ihr Wartungsfenster auf einen späteren Tag zuvorAutoAppliedAfterDate. Sobald der AutoAppliedAfterDate Vorgang abgeschlossen ist, wird die Aktion im nächsten Wartungsfenster automatisch angewendet. Sobald der ForcedApplyDate Vorgang abgeschlossen ist, ist kein weiterer Aufschub mehr möglich. Das genaue Zeitfenster für den Aufschub ist je nach Patch unterschiedlich. Die Daten werden in der AHD-Benachrichtigung und in der Ausgabe veröffentlicht. AWS CLI

Aktualisierungen der Amazon DocumentDB-Engine

Wenn Sie einen ausstehenden Engine-Patch identifiziert haben, wenden Sie eines der folgenden Verfahren an, um ihn anzuwenden oder zu planen. Sie können diese Prozeduren entweder von AWS-Managementkonsole oder von ausführen AWS CLI.

Lesen Sie die Verfügbarkeit beim Patchen

Die Amazon DocumentDB-Engine 5.0 und 8.0 behalten die Leseverfügbarkeit beim Patchen bei, wenn der Cluster mehrere Instances hat. Amazon DocumentDB patcht die Reader-Instances fortlaufend in drei Gruppen, sodass die verbleibenden Reader weiterhin den Datenverkehr verarbeiten. Der Writer ist während der Patches kurzzeitig nicht verfügbar. Um keine Ausfallzeiten beim Lesen zu erreichen, legen Sie Ihre Leseeinstellungen so fest, dass Lesevorgänge auf den Writer zurückgreifen können: secondaryPreferred oder primaryPreferred funktionieren; primary oder secondary allein kann es zu Leseausfällen kommen.

Während die Leser patchen, sinkt der gesamte Cluster-Lesedurchsatz vorübergehend. Um den Durchsatz konstant zu halten, sollten Sie vor dem Upgrade zusätzliche Lesegeräte bereitstellen und sie nach Abschluss des Upgrades entfernen.

Auf Engine 3.6 und 4.0 gelten diese Funktionen zur Leseverfügbarkeit nicht: Ein Engine-Patch verursacht längere Ausfallzeiten, die sich sowohl auf Lese- als auch auf Schreibvorgänge auswirken. Informationen zum Upgrade auf eine Hauptversion, bei der dies der Fall ist, finden Sie unter. Direktes Upgrade der Hauptversion von Amazon DocumentDB

Dauer der Patch-Ausfallzeit

Engine-patch Die Ausfallzeiten variieren. Die wichtigsten Faktoren sind die CPU-Auslastung und die Speicherbelastung der Instance zum Zeitpunkt des Patches. Daher ist die richtige Dimensionierung Ihrer Instances von entscheidender Bedeutung. Um Ausfallzeiten zu minimieren, führen Sie die neueste Version der Amazon DocumentDB-Haupt-Engine aus und verteilen Sie die Instances auf mehrere Availability Zones.

Patch-Updates und -Ersetzungen

Amazon DocumentDB überwacht Patches nach der Veröffentlichung. In dem seltenen Fall, dass ein Problem erkannt wird, unterbricht Amazon DocumentDB den Rollout, während eine aktualisierte Version vorbereitet wird. In diesem Fall sehen Cluster, die den Patch noch nicht erhalten haben, ihn nicht mehr als verfügbare Wartungsaktion an, und die entsprechende Benachrichtigung über geplante Änderungen in der Health Dashboard wird zurückgezogen. Cluster, auf denen die betroffene Version bereits ausgeführt wird, funktionieren weiterhin normal und erfordern keine Maßnahmen Ihrerseits.

Ein aktualisierter Patch folgt in Kürze. Sobald es in Ihrer Region verfügbar ist, erhalten Sie eine neue Benachrichtigung per E-Mail Health Dashboard und, wie unter beschriebenBenachrichtigungen für Amazon DocumentDB-Engine-Patches.

Unterversion-Upgrades

Amazon DocumentDB veröffentlicht Nebenversionen zusätzlich zur Hauptversion 5.0 und höher (z. B.5.0.1). Für Hauptversionen vor 5.0 werden keine Nebenversionen veröffentlicht. Nebenversionen verhalten sich anders als erforderliche und optionale Engine-Patches:

Lesen Sie mehr:Upgrade der Nebenversion von Amazon DocumentDB.

Aktualisierungen des Amazon DocumentDB-Betriebssystems

Instances benötigen gelegentlich Betriebssystem-Updates. Amazon DocumentDB aktualisiert das Betriebssystem, um die Leistung zu verbessern und die Sicherheit zu erhöhen. Bei Betriebssystemaktualisierungen bleiben die Cluster-Engine-Version und die Instance-Klasse unverändert. Wie Engine-Patches verwenden Betriebssystemupdates den oben in diesem Thema beschriebenen optionalen /erforderlich/erzwungenen Lebenszyklus. Im Gegensatz zu Engine-Patches kann ein Betriebssystemupdate diese Kategorien im Laufe der Zeit durchgehen, wenn Sie es verschieben. Wenden Sie Betriebssystemupdates an, sobald sie verfügbar sind, und legen Sie die Wartungsfenster für Cluster und Instances auf Zeiten fest, die Ihren Geschäftsanforderungen entsprechen.

Verwenden Sie die os-upgrade Wartungsaktion auf Cluster-Ebene, um Betriebssystem-Updates auf alle Instances in einem Cluster anzuwenden. Amazon DocumentDB aktualisiert Instances fortlaufend, einige nacheinander, und aktualisiert die primäre Instance zuletzt, um Failovers zu minimieren. Das Update wird während des Cluster-Wartungsfensters ausgeführt — nicht während des Wartungsfensters für einzelne Instances —, das Sie konfigurieren.

Nachdem eine Instanz ein Betriebssystem-Update erhalten hat, beginnt ihr Puffercache leer. Bis das Working Set wieder aus dem Speichervolume aufgefüllt ist, kann es bei Abfragen auf dieser Instance zu einer höheren und niedrigeren BufferCacheHitRatio Latenz kommen.

Wenn Amazon DocumentDB die primäre Instance aktualisiert, stuft ein Failover ein Replikat zur neuen primären Instance herauf. Verwenden Sie den Cluster-Endpunkt, damit Ihre Anwendung dies transparent handhabt. Um die Leseverfügbarkeit während der Aktualisierung von Instances aufrechtzuerhalten, setzen Sie Ihre Lesepräferenz auf secondaryPreferred oder, primaryPreferred sodass Lesevorgänge auf eine verfügbare Instance zurückgreifen können. Halten Sie potenzielle Failover-Ziele (Replikate mit der höchsten Prioritätsstufe) in derselben Instance-Klasse wie die primäre Instance-Klasse. Dadurch wird eine Verschlechterung der Schreibleistung nach einer Heraufstufung vermieden. Details hierzu finden Sie unter Amazon DocumentDB-Failover.

Sowohl die Aktionen auf Clusterebene os-upgrade als auch auf Instanzebene werden möglicherweise gleichzeitig als system-update verfügbare Aktionen angezeigt. describe-pending-maintenance-actions Sie können jedoch nicht beide gleichzeitig planen. Wenn system-update Aktionen auf Instanzebene auf einer Instance aktiv geplant sind, müssen Sie sie abbrechen oder abschließen, bevor Sie die os-upgrade Aktion auf Clusterebene planen, und umgekehrt.

Wenn Sie über ein Ereignis informiert werden möchten, wenn ein neues optionales Betriebssystemupdate eintrifft, melden Sie sich RDS-EVENT-0230 in der Event-Kategorie für Sicherheitspatches an. Weitere Informationen finden Sie unter Amazon DocumentDB DocumentDB-Veranstaltungen abonnieren.

Betriebssystem-Updates sind an bestimmte Instance-Klassen gebunden, sodass verschiedene Instances zu unterschiedlichen Zeiten in Frage kommen. Wenn Ihr Cluster nicht über den neuesten Engine-Patch verfügt, wird das Betriebssystem-Update möglicherweise nicht angezeigt. Wenden Sie zuerst den neuesten Engine-Patch an (sieheAktualisierungen der Amazon DocumentDB-Engine).

Verwenden Sie AWS-Managementkonsole oder AWS CLI , um zu überprüfen, ob ein Update verfügbar ist.

User-initiated aktualisiert

Einige Änderungen beginnen Sie selbst, z. B. indem Sie eine Instanzklasse gegen eine mit mehr oder weniger Arbeitsspeicher austauschen oder die Parametergruppe des Clusters ändern. Amazon DocumentDB behandelt diese anders als Aktualisierungen, die es initiiert. Details hierzu finden Sie unter:

Gehen Sie wie folgt vor, um vom Benutzer initiierte Änderungen aufzulisten, die noch ausstehen:

aws docdb describe-db-instances \
    --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'

aws docdb describe-db-instances ^
    --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'

[
    [
        "sample-cluster",
        "sample-cluster-instance",
        {
            "DBInstanceClass": "db.r5.xlarge"
        }
    ],
    [
        "sample-cluster",
        "sample-cluster-instance-2",
        {}
    ]
]

Patchen globaler Cluster

In einem globalen Cluster wird jeder Mitgliedscluster — primärer und sekundärer — während seines eigenen Wartungsfensters aktualisiert. Wenn ein erforderlicher Engine-Patch in jeder Region verfügbar ist, erhalten Sie eine AHD- und E-Mail-Benachrichtigung. Optionale Patches und neue Nebenversionen generieren keine Benachrichtigungen. Diese finden Sie in den Amazon DocumentDB-Versionshinweisen.

Wenn Sie sich selbst bewerben, patchen Sie die sekundären Patches immer zuerst und die primäre zuletzt. Bei dieser Reihenfolge sind Failover und Switchover während des gesamten Rollouts verfügbar.

Wenn Sie keine Maßnahmen ergreifen, wird der Patch im nächsten Wartungsfenster jedes Clusters automatisch angewendet: zuerst die sekundären, dann der primäre in seinem Fenster, sobald die sekundären Wartungsarbeiten abgeschlossen sind.

Behalten Sie für den primären und den sekundären DB-Cluster dieselbe Version bei. Ein verwaltetes regionsübergreifendes Failover funktioniert nur in einer globalen Datenbank, wenn alle Cluster dieselbe Engine-Version und dieselbe Patch-Level verwenden. Das Gleiche gilt, wenn Sie eine neue sekundäre Engine-Version hinzufügen, die eine neuere Engine-Version als die primäre Version verwendet. Erstellen Sie neue sekundäre Engines in der Version der primären Engine, bevor Sie sie der globalen Datenbank hinzufügen.

Führen Sie nach einer Patch-Benachrichtigung zum frühestmöglichen Zeitpunkt ein Upgrade der primären und sekundären Version auf die neueste Version durch, damit Failover und Switchover weiterhin funktionieren. Wenn eine Failover- oder Switchover-Anfrage abgelehnt wird, vergleichen Sie die Engine-Patch-Versionen der Cluster. Wenn sie nicht übereinstimmen, wenden Sie den verfügbaren Patch auf die verzögerten Cluster an.