Informationen zur Wartung von Cloud SQL-Instanzen

Auf dieser Seite wird erläutert, wie Wartungsupdates für Cloud SQL-Instanzen ausgeführt werden und wie Sie den Zeitpunkt dieser Updates steuern können. Die ersten Schritte finden Sie unter Wartungsfenster finden und einrichten.

Übersicht

Cloud SQL aktualisiert als verwalteter Dienst Instanzen automatisch, um dafür zu sorgen, dass die zugrunde liegende Hardware, das Betriebssystem und das Datenbankmodul zuverlässig, leistungsfähig, sicher und aktuell sind. Die meisten dieser Aktualisierungen werden durchgeführt, während Ihre Cloud SQL-Instanz ausgeführt wird. Bestimmte Systemupdates erfordern jedoch eine kurze Dienstunterbrechung. Diese Updates werden als Wartung bezeichnet.

Bei einer Wartung wird das Datenbankmodul und in einigen Fällen auch das Betriebssystem aktualisiert. Da für diese Updates die Instanz neu gestartet werden muss, kommt es zu einer Ausfallzeit. Wartungsupdates bieten folgende Vorteile:

  • Cloud SQL-Features. Zur Einführung neuer Features wird das Datenbankmodul aktualisiert und neue Plug-ins für die Datenbank installiert.

  • Upgrades der Datenbankversion. Der Anbieter der Datenbanksoftware, der SQL Server entwickelt, veröffentlicht mehrmals pro Jahr neue Nebenversionen. Zu jeder neuen Version gehören Fehlerkorrekturen, Sicherheitspatches, Leistungsverbesserungen und neue Datenbankfeatures. Die neueste Nebenversion, die Cloud SQL for SQL Server unterstützt, finden Sie in den Versionshinweisen oder unter Datenbankversionen und Versionsrichtlinien. Cloud SQL-Instanzen werden kurz nach der Veröffentlichung auf die neueste Datenbankversion aktualisiert, sodass Sie von der Ausführung der neuesten Datenbanksoftware profitieren.

  • Betriebssystem-Patches. Wir halten kontinuierlich Ausschau nach neuen Sicherheitslücken im Betriebssystem. Bei der Erkennung patchen wir das Betriebssystem, um Sie vor neuen Risiken zu schützen.

Auswirkungen der Wartung

Cloud SQL plant in der Regel alle paar Monate ein Wartungsupdate. Das Wartungsupdate kann für jede Instanz etwa 5 bis 10 Minuten dauern. Wenn die Instanz Lesereplikate hat, kann die Gesamtdauer des Wartungsupdates länger dauern. Während eines Wartungsupdates wird jedoch die Verbindung jeder Instanz der Cloud SQL Enterprise-Version im Durchschnitt für weniger als 120 Sekunden unterbrochen. Die Ausfallzeit kann bei einer Instanz höher sein, die während des Wartungsupdates aktiv ist oder ein sehr großes Dataset hat.

Sie können sicherstellen, dass die Wartung sich so wenig wie möglich auf Ihre Vorgänge auswirkt. Nutzen Sie dafür unsere Wartungseinstellungen und machen Sie Ihre Systeme resistent gegenüber vorübergehenden Fehlern..

Geplante Wartung ohne Ausfallzeiten

Bei einer geplanten Wartung ohne Ausfallzeiten verlieren Instanzen der Cloud SQL Enterprise Plus-Version mit Hochverfügbarkeit die Verbindung während der geplanten Wartung normalerweise für weniger als 1 Sekunde.

Die Ausfallzeit kann für Instanzen höher sein, die während der Wartung eine hohe Aktivität haben.

Voraussetzungen und Einschränkungen

  • Während der Wartung enthalten die Datenbanklogs Nachrichten von zwei verschiedenen VMs.
  • Wenn während der geplanten Wartung eine DDL ausgegeben wird, haben die Änderungen möglicherweise einen Zeitstempel für die Erstellung oder Änderung, der nach dem Wartungszeitstempel liegt.

Geplante Wartung ohne Ausfallzeiten simulieren

Wenn Sie die geplante Wartung der primären Instanz von Cloud SQL Enterprise Plus testen möchten, ohne die Datenbankinstanz zu aktualisieren, können Sie eine geplante Wartung simulieren, die praktisch ohne Ausfallzeiten erfolgt.

Rufen Sie dazu die Simulation eines Wartungsereignisses auf einer Cloud SQL Enterprise Plus-Instanz auf, die für eine geplante Wartung ohne Ausfallzeiten infrage kommt. Die Simulationsanfrage führt zu einem Instanzaktualisierungsvorgang für dieselbe Wartungsversion vor dem Vorgang.

Sie können die Simulation auch dann ausführen, wenn für die Instanz ein Wartungsupdate aussteht. Die Instanzversion bleibt während der Simulation gleich.

Verwenden Sie den folgenden Befehl der gcloud CLI, um ein geplantes Wartungsereignis mit nahezu null Ausfallzeit zu simulieren:

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz, in der das simulierte Wartungsereignis ausgeführt werden soll.

Wartungseinstellungen

Cloud SQL bietet Ihnen die Möglichkeit, Wartungsupdates über eine Reihe von Wartungseinstellungen zu konfigurieren.

Sie können die Wartung so konfigurieren, dass sie zu Zeiten geplant werden, zu denen kurze Ausfallzeiten für Ihre Anwendungen die geringste Auswirkung haben. Für jede Cloud SQL-Instanz können Sie Folgendes konfigurieren:

  • Wartungszeitpunkt (vorher Reihenfolge des Updates) Die Woche des Roll-out-Zeitraums, in dem Ihre Cloud SQL-Instanz aktualisiert wird. Dafür gibt es zwei Möglichkeiten:

    • Any: Das Wartungsupdate kann jederzeit erfolgen, normalerweise aber innerhalb von Woche 1.
    • Week 1: Die Wartung erfolgt 7 bis 14 Tage nach dem Senden der Wartungsbenachrichtigung.
    • Week 2: Das Wartungsupdate wird 15 bis 21 Tage nach dem Versenden der Benachrichtigung durchgeführt.
    • Week 5: Das Wartungsupdate wird 35 bis 42 Tage nach dem Versenden der Benachrichtigung durchgeführt.

    Sie legen den Zeitplan der Wartungsaktualisierung beim Konfigurieren eines Wartungsfensters fest.

  • Wartungsfenster. Der Wochentag und die Stunde, in der die Cloud SQL die Wartung plant. Wartungsfenster dauern eine Stunde. Weitere Informationen finden Sie unter Wartungsfenster konfigurieren.

  • Zeitraum für Wartungsausschluss. Ein Block von Tagen, in dem Cloud SQL die Wartung nicht plant. Sie können einen Zeitraum für den Wartungsausschluss bis zu 90 Tage festlegen. Weitere Informationen finden Sie unter Zeitraum für den Wartungsausschluss konfigurieren.

Standardwartungsfenster

Wenn Sie kein Wartungsfenster festlegen, aktualisiert Cloud SQL Ihre Instanz in den folgenden Standardfenstern entsprechend der Zeitzone Ihrer Instanz:

  • Wochentagsfenster (Montag bis Freitag): 22:00 bis 6:00 Uhr
  • Wochenendfenster: Freitag, 22:00 Uhr bis Montag, 6:00 Uhr

Beispiel für die Wartung

Angenommen, Sie sind Entwickler bei einem Einzelhändler und verwalten einen Einkaufswagendienst. Sie haben eine Cloud SQL-Instanz für eine Produktionsumgebung und eine zweite für eine Staging-Umgebung. Sie möchten, dass Ihre Instanz gerade dann gewartet wird, wenn Ihre Instanz den geringsten Traffic verarbeitet, also sonntags um Mitternacht. Außerdem sollten Sie die Wartung während der geschäftigen Weihnachtssaison überspringen.

In diesem Fall legen Sie die Wartungseinstellungen der Produktionsinstanz auf Folgendes fest:

  • Wartungsfenster: Sonntags zwischen 00:00 Uhr und 1:00 Uhr ET (UTC-4/-5)
  • Wartungszeitpunkt: Week 2
  • Zeitraum für den Wartungsausschluss: 1. November bis 15. Januar.

Die Wartungseinstellungen für Ihre Staging-Umgebung sind identisch, nur der Zeitpunkt der Wartung ist auf Week 2 festgelegt. Dadurch können Sie mindestens 7 Tage, bevor die Wartung in der Produktion eingeführt wird, operative Akzeptanztests für einen Wartungsrelease im Staging ausführen. Wenn in der Staging-Umgebung ein Fehler auftritt, haben Sie Zeit, das Problem zu diagnostizieren und zu beheben oder einen Zeitraum für den Wartungsausschluss einzurichten, in dem Ihre Produktionsumgebung nicht betroffen ist.

Benachrichtigungen über anstehende Wartungen

Sie können eine Benachrichtigung über bevorstehende Wartungen mindestens eine Woche vor der geplanten Wartung an Ihre E-Mail-Adresse erhalten. Der Betreff der E-Mail lautet Anstehende Wartung für Ihre Cloud SQL-Instanz instancename, falls Sie einen E-Mail-Filter für Benachrichtigungen einrichten möchten.

Wartungsbenachrichtigungen werden nicht standardmäßig gesendet. Sie müssen Wartungsbenachrichtigungen aktivieren. Bevor Sie Benachrichtigungen erhalten können, müssen Sie auch ein Wartungsfenster auswählen.

Benachrichtigungen werden an die E-Mail-Adresse Ihres Google-Kontos gesendet. Ein benutzerdefinierter E-Mail-Alias wie ein Team-E-Mail-Alias kann nicht konfiguriert werden.

Sie aktivieren Wartungsbenachrichtigungen für alle Cloud SQL-Instanzen einem bestimmten Projekt, die in Wartungsfenster haben. Sie erhalten eine Benachrichtigung pro Instanz. Für Lesereplikate werden keine Benachrichtigungen zu bevorstehenden Wartungen gesendet.

Sie können sich auch anstehende Wartungsinformationen in der Google Cloud Console ansehen.

  • In der Liste Instanzen in der Spalte Wartung. Wenn eine Wartung geplant ist, werden das Datum und die Uhrzeit für den geplanten Wartungsbeginn angezeigt. Sie können die Instanzliste nach dem Begriff Wartung filtern, um alle Instanzen zu finden, die gewartet werden sollen. Die Spalte Wartung wird nur angezeigt, wenn für eine oder mehrere Instanzen im Projekt eine Wartung geplant ist. Ist keine Wartung geplant, wird die Spalte ausgeblendet.
  • Auf der Seite Instanzdetails im Bereich Wartung. Wenn eine Wartung geplant ist, werden unter Anstehend ein Datum und eine Uhrzeit für den geplanten Wartungsbeginn angezeigt.

  • Sie können in der Google Cloud Console auf der Seite AKTIVITÄT eine Liste der für die Wartung geplanten Instanzen aufrufen. Wenn eine Wartung geplant ist, sehen Sie für die Instanz die Nachricht SQL-Wartung sowie das Datum und die Uhrzeit für den geplanten Wartungsbeginn.

Wartung verschieben

Wenn es ein Wartungsfenster für Ihre Instanz gibt, können Sie das Wartungsupdate bis zu 24 Stunden vor dem geplanten Wartungsupdate verschieben. Wenn Sie beispielsweise während eines geplanten Wartungsfensters einen neuen Service starten, sollten Sie das Wartungsupdate auf einige Tage nach dem Start verschieben.

Es gibt einige Einschränkungen für die Neuplanung von Wartungsupdates. Nachdem Cloud SQL die Benachrichtigungs-E-Mail gesendet hat, führt Cloud SQL das Wartungsupdate innerhalb von sieben Wochen durch, um eine Überschneidung mit dem nächsten Cloud SQL-Wartungsupdate zu vermeiden. Wenn Sie beispielsweise als Wartungszeitpunkt Woche 1 oder Woche 2 auswählen, können Sie das Wartungsupdate maximal 4 Wochen (28 Tage) nach dem ursprünglich geplanten Datum verschieben. Wenn Sie für Ihre Instanz den Wartungszeitpunkt auf Woche 5 festlegen, können Sie das Wartungsereignis nur bis maximal eine Woche (7 Tage) nach dem ursprünglichen Datum verschieben. Sie können die Wartung mehrmals verschieben, solange das verschobene Wartungsereignis innerhalb des Zeitraums für die Verschiebung liegt, der durch den für Ihre Instanz konfigurierten Wartungszeitplan definiert ist.

Informationen zu allen anderen Einschränkungen finden Sie unter Einschränkungen bei Verschiebungen.

Für das neue Wartungsfenster haben Sie einige Planungsoptionen:

  • Updates sofort vornehmen. Sie können das Update sofort auf die Instanz anwenden, anstatt auf das Eintreten des geplanten Wartungsfensters zu warten. In diesem Fall beginnt die Wartung in der Regel innerhalb von fünf Minuten.

  • Auf einen anderen Zeitpunkt verschieben. Sie können ein geplantes Wartungsereignis auf zwei Arten verschieben:

    • Nächstes verfügbares Fenster. Mit dieser Option wird die Wartung auf das nächste verfügbare Wartungsfenster nach der aktuell geplanten Wartungszeit, das normalerweise eine Woche später ist, verschoben.
    • Bestimmter Zeitpunkt. Mit dieser Option können Sie die Dauer der Neuplanung, die durch den für Ihre Instanz konfigurierten Wartungszeitplan definiert ist, auf einen bestimmten Zeitpunkt festlegen.
      • 28 Tage, wenn Sie als Wartungszeitpunkt Woche 1 oder Woche 2 auswählen
      • 7 Tage, wenn Sie als Wartungszeitpunkt Woche 5 auswählen

Eine Anleitung zum Verschieben der Wartung finden Sie unter Geplante Wartung verschieben.

Funktionsweise der Wartung

Um die Wartung kurz zu halten, verwendet Cloud SQL einen Wartungs-Failover-Workflow, der weitgehend unserem Workflow mit automatischem Failover für hochverfügbare Instanzen ähnelt.

Es werden folgende Schritte ausgeführt:

  1. Eine aktualisierte VM mit der neuen Software einrichten
  2. Beenden Sie die Datenbank auf der ursprünglichen VM.
  3. Das Laufwerk und die statische IP-Adresse zur aktualisierten VM wechseln
  4. Starten Sie die Datenbank auf der aktualisierten VM.

Gehen Sie die folgenden Tabs durch, um Details des Workflows einschließlich vor und nach der Wartung anzuzeigen.

Vor der Wartung

Vor der Wartung kommuniziert der Client mit der ursprünglichen VM über eine statische IP-Adresse. Die Daten werden auf einem nichtflüchtigen Speicher gespeichert, der an die ursprüngliche VM angehängt ist. In diesem Beispiel ist die Cloud SQL-Instanz mit Hochverfügbarkeit konfiguriert. Das bedeutet, dass sich eine andere VM im Standby-Modus befindet, um bei einem ungeplanten Ausfall zu übernehmen. Die Cloud SQL-Instanz stellt Traffic zur Anwendung bereit.

Grafik: Diagramm mit dem Status vor der Wartung

Schritt 1

Neue VM einrichten

Eine neue virtuelle Maschine (VM) wird mit der neuesten Datenbanksoftware und dem neuesten VM-Betriebssystem eingerichtet. Das aktualisierte VM-Betriebssystem wird gestartet. An diesem Punkt wurde das Datenbankmodul noch nicht gestartet. Bei hochverfügbaren Instanzen wird auch eine neue Standby-VM eingerichtet.

Die Gesamtausfallzeit wird erheblich verkürzt, wenn das Softwareupdate auf einer anderen VM installiert wird, während die ursprüngliche Cloud SQL-Instanz weiterhin Traffic verarbeitet.

Grafik: Diagramm zur Einrichtung der VM

Schritt 2

Beenden Sie die Datenbank auf der ursprünglichen VM.

Das Datenbankmodul wird heruntergefahren, sodass das Laufwerk von der ursprünglichen VM getrennt und an die aktualisierte VM angehängt werden kann. Vor dem Herunterfahren wartet das Datenbankmodul einige Sekunden, bis für laufende Transaktionen ein Commit ausgeführt wird und die Anfragen der bestehenden Verbindungen per Drain beendet werden. Danach wird für alle offenen oder lang andauernden Transaktionen ein Rollback durchgeführt. Die Datenbank akzeptiert keine neuen Verbindungen und bestehende Verbindungen werden getrennt. Die Instanz ist nicht mehr verfügbar und die Ausfallzeit für die Wartung beginnt.

Grafik: Diagramm einer Instanz nach einem Failover

Schritt 3

Zur aktualisierten VM wechseln

Das Laufwerk wird von der ursprünglichen VM getrennt und an die aktualisierte VM angehängt. Die statische IP-Adresse wird so neu konfiguriert, dass sie auf die aktualisierte VM verweist. Dadurch wird sichergestellt, dass die Anwendung nach der Wartung dieselbe IP-Adresse verwendet wie zuvor. Der Datenbank-Cache wird mit der ursprünglichen VM entfernt, d. h., der Datenbank-Cache wird während der Wartung praktisch geleert.

Grafik: Diagramm der Umstellung auf die aktualisierte VM

Schritt 4

Starten Sie die Datenbank auf der aktualisierten VM.

Das aktualisierte Datenbankmodul wird auf dem Datenlaufwerk gestartet. Durch die Verwendung eines gemeinsamen Datenlaufwerks wird sichergestellt, dass alle Transaktionen, die vor der Wartung in die ursprüngliche Instanz geschrieben wurden, nach der Wartung in der aktualisierten Datenbank vorhanden sind. Wenn der Rollback von unvollständigen Transaktionen während des Herunterfahrens der Datenbank nicht abgeschlossen wurde, durchläuft die Datenbank automatisch die Absturzwiederherstellung, um sicherzustellen, dass die Datenbank in einem verwendbaren Zustand wiederhergestellt wird.

Grafik: Diagramm zum Starten der aktualisierten VM

Nach der Wartung

Nach Schritt 4 kann die Cloud SQL-Instanz Verbindungen annehmen und zur Bereitstellung von Traffic an die Anwendung zurückkehren.

Abgesehen von der aktualisierten Software sieht die Cloud SQL-Instanz für die Anwendung gleich aus. Die Anwendung stellt weiterhin eine Verbindung zur Cloud SQL-Instanz über dieselbe statische IP-Adresse her und die aktualisierte VM wird in derselben Zone wie die ursprüngliche VM ausgeführt. Alle in die ursprüngliche Datenbank geschriebenen Daten bleiben erhalten.

Grafik: Diagramm nach der Wartung

Auswirkungen der Wartung minimieren

Im Allgemeinen empfiehlt Google Cloud, dass Nutzer, die Anwendungen in der Cloud ausführen, ihre Systeme widerstandsfähig gegenüber vorübergehenden Fehlern machen. Dies sind vorübergehende Kommunikationsprobleme zwischen Diensten, die durch eine vorübergehende Nichtverfügbarkeit verursacht werden. Gelegentliche vorübergehende Fehler sind in der Cloud unvermeidbar.

Zu einigen der vorübergehenden Fehler, die während der Wartung auftreten, gehören unterbrochene Verbindungen und fehlgeschlagene Transaktionen im laufenden Betrieb. Wenn Sie Ihre Systeme so konzipieren und Ihre Anwendungen so optimieren, dass sie vorübergehenden Fehlern gegenüber resistent sind, sind Sie auch optimal aufgestellt, um die Auswirkungen von Datenbankwartungen zu minimieren.

Sie können die Auswirkungen unterbrochener Verbindungen minimieren, indem Sie Verbindungspools verwenden. Die Verbindungen zwischen dem Pooler und der Datenbank werden während der Wartung unterbrochen. Die Verbindungen zwischen der Anwendung und dem Pooler bleiben erhalten. Auf diese Weise ist die Wiederherstellung der Verbindungen für die Anwendung transparent und wird stattdessen in den Verbindungs-Pooler übertragen.

Um die Transaktionsfehler zu reduzieren, können Sie die Anzahl von Transaktionen mit langer Ausführungszeit begrenzen. Das Umschreiben von Abfragen, sodass sie kleiner und effizienter sind, reduziert nicht nur die Wartungsausfallzeiten, sondern verbessert auch die Leistung und Zuverlässigkeit der Datenbank.

Für eine effiziente Wiederherstellung nach Verbindungsabbrüchen und Transaktionsfehlern können Sie Ihre Datenbankverbindungen effizient verwalten. Sie können die Verbindungs- und Abfragewiederholungslogik mit exponentiellem Backoff in Ihre Anwendungen und Verbindungs-Pooler einbinden. Für den Fall, dass eine Abfrage fehlschlägt oder eine Verbindung unterbrochen wird, richtet das System eine Wartezeit vor dem erneuten Versuch ein, die sich für jeden nachfolgenden Versuch erhöht. Beispielsweise wartet das System möglicherweise nur wenige Sekunden auf den ersten Wiederholungsversuch, aber bis zu einer Minute für den vierten Wiederholungsversuch. Dieses Muster gewährleistet, dass diese Fehler behoben werden, ohne den Dienst zu überlasten.

Andere kreative Lösungen können ebenfalls die Auswirkungen von Wartungen minimieren, z. B. durch die Verwendung von Skripts zum Aufwärmen des Datenbank-Cache nach der Wartung oder die Optimierung der Anzahl der Tabellen in Datenbanken. Wir empfehlen, die Best Practices und Betriebsrichtlinien für die Datenbankverwaltung zu befolgen, um eine reibungslose Wartung zu gewährleisten.

Zeitkritische Wartung

In sehr seltenen Fällen muss Cloud SQL möglicherweise Wartungen außerhalb der Wartungseinstellungen planen, um schwerwiegende Stabilitätsprobleme oder Sicherheitslücken zu beheben, die zeitkritisch sind. Diese Updates werden schnell bereitgestellt und Cloud SQL zählt sie im Rahmen des SLA als Ausfallzeit.

Self-Service-Wartung

Cloud SQL veröffentlicht regelmäßig Softwareverbesserungen und Patches für Sicherheitslücken über neue Wartungsversionen, die Sie auf Ihren Instanzen installieren können. Cloud SQL verwaltet für jede Hauptversion eines Datenbankmoduls ein Änderungslog für die Cloud SQL-Wartung. Weitere Informationen finden Sie unter Änderungslogs für die Cloud SQL-Wartung.

Cloud SQL führt geplante Wartungen alle paar Monate standardmäßig aus, damit Sie immer die neueste Software haben. Sie können jedoch die Self-Service-Wartung verwenden, um Ihre Instanz auf dem neuesten Stand zu halten, wenn:

  • Sie ein Update vor dem nächsten geplanten Wartungsereignis benötigen.
  • Sie nach dem Überspringen des letzten Wartungsupdates die neueste Software installieren möchten.

Wenn Sie Lesereplikate verwenden, können Sie mithilfe der Self-Service-Wartung alle Lesereplikate aktualisieren. Sie geben die primäre Instanz an und die Wartungsanfrage aktualisiert alle Lesereplikate der primären Instanz auf die angegebene Wartungsversion. Anschließend wird die primäre Instanz auf die Wartungsversion aktualisiert.

Wartungseinschränkungen

In diesem Abschnitt werden die Einschränkungen der Cloud SQL-Wartung beschrieben.

Einschränkungen neu festlegen

Es gibt einige Dinge, die Sie bei einer Neuplanung beachten sollten:

  • Sie müssen die Wartung mindestens 24 Stunden vor Beginn des ursprünglich geplanten Wartungsereignisses verschieben.

  • Sie können die Wartung für eine oder mehrere Instanzen in Ihrem Projekt verschieben. Sie können die Wartung jedoch nur für eine Instanz auf einmal neu planen, da eine Bulk-Neuplanung derzeit nicht verfügbar ist.

  • Sie können die Wartung auf einen Zeitpunkt verschieben, der innerhalb eines Zeitraums für den Wartungsausschluss oder sogar außerhalb des Wartungsfensters liegt, solange der Zeitraum für die Neuplanung innerhalb des Zeitraums liegt, der durch den für Ihre Instanz konfigurierten Wartungszeitplan festgelegt ist.

  • Wenn ein Wartungsvorgang aktuell ausgeführt wird, verzögert sich die Neuplanung so lange, bis der Vorgang abgeschlossen ist.

Beschränkungen des Zeitraums für den Wartungsausschluss

Es gibt einige Dinge, die Sie über Zeiträume für den Wartungsausschluss wissen sollten:

  • Sie können einen Zeitraum für den Wartungsausschluss auch festlegen, wenn für die Instanz kein Wartungsfenster konfiguriert ist. Zeiträume für den Wartungsausschluss können 1 bis 90 Tage lang sein.

  • Der Wartungsausschluss hat Vorrang vor einem geplanten Wartungsfenster. Wenn ein Konflikt zwischen dem Zeitpunkt eines Wartungsfensters und dem Wartungsausschluss besteht, überschreibt der Wartungsausschluss das Wartungsfenster.

  • Zeiträume für den Wartungsausschluss und der Wartungszeitpunkt sind voneinander unabhängige Features. Wenn Sie einen Zeitraum für den Wartungsausschluss für eine Instanz mit dem Wartungszeitpunkt Week 1 erstellen, hat dies keine Auswirkungen auf die Bestimmung des geplanten Updates für eine Instanz mit dem Wartungszeitpunkt Week 2. Wenn ein geplantes Wartungsupdate in einen Zeitraum für den Wartungsausschluss fällt, sendet Cloud SQL keine Benachrichtigung für die Instanzen, die Sie mit dem Wartungszeitpunkt konfiguriert haben.

  • Wenn für eine primäre Instanz ein Ausschlusszeitraum festgelegt ist, werden Wartungen für alle Replikate, die mit der primären Instanz verknüpft sind, ebenfalls abgelehnt. Beispiel: Eine primäre Instanz in Region A hat drei Lesereplikate: zwei in Region A und eine in Region B. Wenn für die primäre Instanz ein Ausschlusszeitraum festgelegt ist, werden Wartungen an den einzelnen Replikaten, einschließlich des Replikats in Region B, erst dann ausgeführt, wenn der Ausschlusszeitraum für die primäre Instanz abgelaufen ist.

  • Wenn ein Zeitraum für den Wartungsausschluss nach der Planung der Wartung festgelegt wird und sich der Zeitraum für den Wartungsausschluss mit der geplanten Wartungszeit überschneidet, wird die Aktualisierung übersprungen.

  • Sie haben die Möglichkeit, eine abgelehnte Wartungsperiode so festzulegen, dass sie sich jedes Jahr wiederholt. Dazu lassen Sie bei den Parametern für das Start- und Enddatum das Jahr weg. Wenn das Jahr angegeben ist, wird der Zeitraum für den Wartungsausschluss nur für das jeweilige Jahr festgelegt.

  • Sie können mehrere Zeiträume für den Wartungsausschluss in einem Jahr festlegen. Wir empfehlen aber, eine Kette von Ausschlusszeiträumen zu vermeiden, um aufeinanderfolgende geplante Wartungsereignisse zu überspringen. Die Wartung von Cloud SQL sollte regelmäßig erfolgen, damit die Instanz dauerhaft zuverlässig funktioniert. In der Regel wird die Cloud SQL-Wartung einmal alle paar Monate geplant.

  • Um die Zuverlässigkeit des Dienstes zu gewährleisten, kann Cloud SQL Nutzer mit Instanzen, auf denen Wartungsreleases ausgeführt werden, die älter als 12 Monate sind, darüber informieren, dass ein nächster Wartungs-Rollout erforderlich ist.

  • Nach dem Ende eines Zeitraums für den Wartungsausschluss gilt das normale Wartungsverhalten.

  • Zeiträume für Wartungsausschlüsse haben keine Auswirkungen auf vom Nutzer ausgelöste Vorgänge, z. B. Self-Service-Wartung.

FAQ zur Wartung

Werden Ausfallzeiten durch Wartung auf das SLA angerechnet?

Ausfallzeiten aufgrund normaler Wartungen werden nicht auf das SLA angerechnet. Cloud SQL rechnet jedoch Ausfallzeiten aufgrund zeitkritischer Wartungen auf das SLA an.

Wie wirkt sich die Wartung auf Lesereplikate aus?

  • Cloud SQL wartet immer Lesereplikate vor der primären Instanz. Wenn die primäre Instanz ein Wartungsfenster hat, halten sich die Lesereplikate an dasselbe Wartungsfenster.
  • Wenn Ihre primäre Instanz mehrere Lesereplikate hat, aktualisiert Cloud SQL möglicherweise einige der Replikate gleichzeitig.
  • Lesereplikate berücksichtigen den Zeitraum für den Wartungsausschluss, der für die primäre Instanz festgelegt wurde.

Kann ich geplante Wartungen abbrechen?

Sie können ein geplantes Wartungsfenster zwar nicht abbrechen, aber es verschieben. Sie können auch einen Zeitraum für den Wartungsausschluss konfigurieren, der sich mit der geplanten Wartungszeit überschneidet, um die Wartung effektiv zu überspringen.

Was passiert, wenn das Wartungsereignis abgebrochen wird?

Wenn Cloud SQL ein Wartungsereignis abbricht, erhalten Sie nach Möglichkeit im Vorfeld eine entsprechende Benachrichtigung.

Sie erhalten eine neue Benachrichtigung über die bevorstehende Wartung, wenn das Wartungsereignis neu geplant wurde.

Ist die Cloud SQL-Wartung kumulativ?

Wartungsupdates werden kumulativ ausgeführt. Sie müssen nicht jedes Wartungsupdate anwenden, das Sie vielleicht verpasst haben. Die neueste Wartungsversion wird mit dem nächsten geplanten Wartungsupdate angewendet. Sie können auch das neueste Wartungsupdate mit Self-Service-Wartung anwenden.

Was passiert, wenn die Instanz während des geplanten Wartungsupdates beendet wird?

Wenn eine Instanz während des geplanten Wartungsupdates beendet wird, überspringt Cloud SQL das Wartungsupdate. Beim nächsten Neustart der Instanz wird sie jedoch von Cloud SQL automatisch mit dem neuesten Wartungsupdate aktualisiert.

Wie lange dauert die Self-Service-Wartung für alle Lesereplikate einer primären Instanz?

Wie lange eine Self-Service-Wartungsaktualisierung dauert, hängt von der Gesamtzahl der Lesereplikate Ihrer primären Instanz ab. Sie können die Dauer eines Self-Service-Wartungsupdates reduzieren. Dazu aktualisieren Sie einige Lesereplikate einzeln und führen dann das Update auf der primären Instanz durch, um die übrigen Lesereplikate zu aktualisieren.

Bei der zweiten Aktualisierung werden alle Replikate übersprungen, die bereits die Zielwartungsversion haben.

Kann ich eine Self-Service-Wartung für ein einzelnes Lesereplikat durchführen, wenn ich mehrere Lesereplikate meiner primären Instanz habe?

Ja, Sie können eine Self-Service-Wartung für eine einzelne Lesereplikatinstanz ausführen. Wir empfehlen jedoch, die restlichen Lesereplikate und die primäre Instanz bald danach auf dieselbe Wartungsversion zu aktualisieren. Wir empfehlen, für alle Lesereplikate und primären Instanzen dieselbe Wartungsversion zu verwenden.

Nächste Schritte