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.

Überblick

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 werden das Betriebssystem und das Datenbankmodul 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 MySQL 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 MySQL 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.

    Sie müssen Upgrades der MySQL 8.0-Nebenversionen manuell ausführen. Siehe MySQL-Nebenversion für eine Instanz festlegen.

  • 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

Während eines Wartungsereignisses verliert eine Cloud SQL for MySQL-Instanz im Durchschnitt weniger als 60 Sekunden die Verbindung.

Für Cloud SQL Enterprise Plus bietet Cloud SQL eine geplante Wartung ohne Ausfallzeiten.

Die Ausfallzeit kann für Instanzen höher sein, die während der Wartung eine hohe Aktivität oder sehr große Datasets haben. Cloud SQL plant die Wartung normalerweise alle paar Monate.

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

  • Wenn Sie eines der folgenden Flags verwenden, müssen sie auf Standardwerte gesetzt werden:

    • sync_binlog, Wert: 1
    • innodb_flush_log_at_trx_commit, Wert 1
    • replica_skip_errors, Wert OFF
    • binlog_order_commit, Wert ON

    Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

  • Wenn Sie Cloud SQL Auth Proxy oder Cloud SQL Language Connectors verwenden, achten Sie darauf, dass diese auf die neueste Version aktualisiert werden.

  • Wenn Sie externe Replikate mit aktivierter GTID aktiviert haben, müssen Sie diese Replikate für die Verwendung der GTID-basierten automatischen Positionierung konfigurieren, da die Replikation nach der Wartung nicht funktioniert. Weitere Informationen finden Sie unter Automatische Positionierung von GTID.

  • Die MySQL-Server-UID ändert sich während der Wartung.

  • 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 Wartungsausfallzeit Ihrer primären Instanz von Cloud SQL Enterprise Plus testen möchten, ohne Ihre Datenbankinstanz zu aktualisieren, können Sie eine geplante Wartung ohne Ausfallzeiten simulieren.

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

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

Verwenden Sie den folgenden gcloud CLI-Befehl, um ein geplantes Wartungsereignis mit praktisch keinen Ausfallzeiten zu simulieren:

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

Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz, in der Sie das simulierte Wartungsereignis ausführen möchten.

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:

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

  • Aktualisierungsreihenfolge: Legt die Reihenfolge fest, in der die Cloud SQL-Instanz relativ zu anderen Instanzen in derselben Region aktualisiert wird. Die Aktualisierungsreihenfolge kann auf Any, Earlier oder Later festgelegt werden. Later-Instanzen werden eine Woche nach Earlier-Instanzen mit dem gleichen Wartungsfenster in derselben Region aktualisiert. Sie legen die Reihenfolge der Aktualisierung fest, wenn Sie ein Wartungsfenster konfigurieren.

  • Zeitraum für Wartungsausschluss. Ein Block von Tagen, in dem Cloud SQL die Wartung nicht plant. Der Zeitraum für den Wartungsausschluss kann bis zu 90 Tage lang sein. 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)
  • Aktualisierungsreihenfolge:Later
  • Zeitraum für den Wartungsausschluss: 1. November bis 15. Januar.

Die Wartungseinstellungen für Ihre Staging-Umgebung sind identisch, außer dass die Updatereihenfolge auf Earlier festgelegt wird. 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, damit 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 Instanzname, 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 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 Sie ein Wartungsfenster für Ihre Instanz haben, können Sie die Wartung jederzeit verschieben, bevor die Wartung zum ersten Mal geplant ist. Wenn Sie z. B. während der ursprünglichen Wartungszeit einen neuen Dienst starten, sollten Sie das Wartungsfenster so verschieben, dass die Wartung einige Tage nach dem Start stattfindet.

Sie können die Wartung mehrmals verschieben, wenn der Termin nicht mehr als 28 Tage nach dem ursprünglich geplanten Zeitpunkt liegt.

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 einen bestimmten Zeitpunkt innerhalb von 28 Tagen nach dem ursprünglich geplanten Wartungszeitpunkt auswählen.

Wenn Sie die Wartung verschieben möchten, finden Sie unter Geplante Wartung verschieben weitere Informationen.

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.

Auf den Tabs unten finden Sie Details zum Workflow, einschließlich zum Zustand vor und nach der Wartung.

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 diese Zeit zu der im SLA festgeschriebenen zulässigen 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 die Self-Service-Wartung verwenden, um alle Ihre Lesereplikate zu 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 haben die Möglichkeit, die Wartung auf einen Zeitpunkt zu verschieben, der in einem Zeitraum für den Wartungsausschluss oder sogar außerhalb des Wartungsfensters liegt, solange der Zeitpunkt in den auf 28 Tage beschränkten Zeitraum für die Neuplanung fällt.

  • 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 die relative Planung sind voneinander unabhängige Features. Ein Zeitraum für den Wartungsausschluss für eine Earlier-Instanz hat keinen Einfluss auf das Festlegen des Zeitplans für die Later-Instanz. Wenn der Wartungsplan in einen Zeitraum für den Wartungsausschluss für Earlier- oder Later-Instanzen fällt, werden keine Benachrichtigungen gesendet.

  • 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 den Wartungsausschluss haben keine Auswirkungen auf vom Nutzer ausgelöste Vorgänge, z. B. eine Self-Service-Wartung.

FAQ zur Wartung

Wie wirkt sich die Wartung auf Legacy-HA-Failover-Instanzen aus?

Legacy-HA-Failover-Instanzen werden bei Wartungsupdates deaktiviert. Deren Wartungsupdates werden direkt vor den Updates der primären Instanz ausgeführt. Sie können ein Wartungsfenster nicht direkt für eine Legacy-HA-Failover-Instanz festlegen, da diese das gleiche Wartungsfenster wie die primäre Instanz hat.

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 im 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. Wenn Sie die Instanz das nächste Mal neu starten, aktualisiert Cloud SQL die Instanz jedoch automatisch mit dem neuesten Wartungsupdate.

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

Die Dauer eines Self-Service-Wartungsupdates 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.

Beim zweiten Update werden alle Replikate übersprungen, die bereits die Zielwartungsversion haben.

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

Ja, Sie können Self-Service-Wartungen 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, alle Lesereplikate und die primäre Instanz mit einer identischen Wartungsversion zu betreiben.

Nächste Schritte