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 werden das Datenbankmodul und in einigen Fällen 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 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

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

Cloud SQL plant ein Wartungsupdate in der Regel alle paar Monate. 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 des Wartungsupdates verliert jedoch jede Cloud SQL Enterprise-Instanz im Durchschnitt weniger als 60 Sekunden lang die Verbindung. Die Ausfallzeit kann für eine Instanz höher sein, die während des Wartungsaktualisierungsereignisses eine hohe Aktivität aufweist oder einen sehr großen Datensatz 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 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

• Sie müssen das binäre Logging auf Ihrer Instanz aktivieren.

• Wenn Sie eines der folgenden Flags verwenden, müssen Sie es auf die Standardwerte setzen:

  • 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, müssen Sie dafür sorgen, dass sie auf die neueste Version aktualisiert sind.

• Wenn Sie externe Replikate mit aktivierter GTID haben, müssen Sie diese Replikate so konfigurieren, dass sie die GTID-basierte automatische Positionierung verwenden. Andernfalls funktioniert die Replikation nach der Wartung nicht mehr. Weitere Informationen finden Sie unter Automatische GTID-Positionierung.

• Die UID Ihres MySQL-Servers ä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 Ausfallzeit der geplanten Wartung Ihrer primären Instanz der Cloud SQL Enterprise Plus-Version 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, die für eine geplante Wartung ohne Ausfallzeiten infrage kommt. Die Simulationsanfrage führt zu einem Instanzaktualisierungsvorgang auf dieselbe Wartungsversion, die vor dem Vorgang aktiv war.

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

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 (früher Aktualisierungsreihenfolge). In der Woche des Roll-outs aktualisieren Sie Ihre Cloud SQL-Instanz. Dafür gibt es zwei Möglichkeiten:

  • Any: Das Wartungsupdate kann jederzeit erfolgen, in der Regel jedoch innerhalb der ersten Woche.
  • Week 1: Die Wartung findet 7 bis 14 Tage nach dem Senden der Wartungsbenachrichtigung statt.
  • Week 2: Das Wartungsupdate wird 15 bis 21 Tage nach dem Senden der Benachrichtigung durchgeführt.
  • Week 5: Das Wartungsupdate wird 35 bis 42 Tage nach dem Senden der Benachrichtigung durchgeführt.

  Sie legen den Zeitplan für das Wartungsupdate fest, wenn Sie ein Wartungsfenster 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.

• Zeitraum für Wartungsausschluss. Ein Block von Tagen, in dem Cloud SQL die Wartung nicht plant. Sie können einen Wartungsausschlusszeitraum von bis zu 90 Tagen 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, außer dass der Wartungszeitpunkt auf Week 2 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 oder einen Wartungsausschlusszeitraum einzurichten, 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. Außerdem müssen Sie ein Wartungsfenster auswählen, bevor Sie Benachrichtigungen erhalten können.

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 das Wartungsupdate bis zu 24 Stunden vor dem geplanten Zeitpunkt verschieben. Wenn Sie beispielsweise während des geplanten Wartungsfensters einen neuen Dienst starten, sollten Sie das Wartungsupdate auf einige Tage nach der Einführung verschieben.

Es gibt einige Einschränkungen bei der Neuplanung von Wartungsupdates. Nachdem die Benachrichtigungs-E-Mail gesendet wurde, führt Cloud SQL das Wartungsupdate innerhalb von sieben Wochen durch, um Überschneidungen 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 bis zu vier Wochen (28 Tage) nach dem ursprünglich geplanten Datum verschieben. Wenn Sie für Ihre Instanz einen Wartungszeitpunkt in Woche 5 festlegen, können Sie das Wartungsereignis nur bis zu einer 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 von Wartungen 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.

Auf den folgenden Tabs finden Sie Details zum Workflow, einschließlich zum Zustand vor und 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 mit der Self-Service-Wartung alle Ihre 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.

Einschränkungen bei der Wartung

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 die Wartungszeit sind voneinander unabhängige Funktionen. Wenn Sie einen Zeitraum für den Wartungsausschluss für eine Instanz mit Week 1-Wartungszeit erstellen, hat dies keinen Einfluss auf die Festlegung des geplanten Updates für eine Instanz mit Week 2-Wartungszeitpunkt. Wenn ein geplanter Wartungszeitpunkt in einen Zeitraum für den Wartungsausschluss fällt, sendet Cloud SQL keine Benachrichtigung für die Instanzen, die Sie mit einem 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

• Wie wirkt sich die Wartung auf Legacy-HA-Failover-Instanzen aus?
• Werden Ausfallzeiten durch Wartung auf das SLA angerechnet?
• Wie wirkt sich die Wartung auf Lesereplikate aus?
• Kann ich geplante Wartungen abbrechen?
• Was passiert, wenn das Wartungsereignis abgebrochen wird?
• Ist die Cloud SQL-Wartung kumulativ?
• Was passiert, wenn die Instanz während des geplanten Wartungsupdates gestoppt wird?
• Wie lange dauert die Self-Service-Wartung für alle Lesereplikate einer primären Instanz?
• Kann ich bei mehreren Lesereplikaten meiner primären Instanz eine Self-Service-Wartung für ein einzelnes Lesereplikat durchführen?

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, werden einige der Replikate möglicherweise gleichzeitig in Cloud SQL aktualisiert.
• 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 bei der nächsten geplanten Wartung angewendet. Sie können auch das neueste Wartungsupdate mit Self-Service-Wartung anwenden.

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

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

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.

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

Kann ich bei mehreren Lesereplikaten meiner primären Instanz eine Self-Service-Wartung für ein einzelnes Lesereplikat durchführen?

Ja, Sie können eine Self-Service-Wartung für eine einzelne Lesereplikatinstanz durchfü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 derselben Wartungsversion auszuführen.

Nächste Schritte

• Wartungsbenachrichtigungen aktivieren
• Wartungsfenster festlegen
• Wartungsbenachrichtigungen aufrufen