Planen von Azure-Wartungsereignissen in Azure SQL-Datenbank und Azure SQL Managed Instance
Gilt für: Azure SQL-Datenbank Azure SQL Managed Instance
Es wird beschrieben, wie Sie Ereignisse der geplanten Wartung in Ihrer Datenbank für Azure SQL-Datenbank und für verwaltete Azure SQL-Instanzen vorbereiten.
Was ist ein geplantes Wartungsereignis?
Damit die Dienste Azure SQL-Datenbank und Azure SQL Managed Instance sicher, konform, stabil und leistungsfähig bleiben, werden nahezu fortlaufend Updates über die Dienstkomponenten ausgeführt. Dank der modernen und robusten Dienstarchitektur und innovativer Technologien wie Hotpatching sind die meisten Updates in Bezug auf die Verfügbarkeit vollständig transparent und stellen keine Beeinträchtigung dar. Trotzdem verursachen einige Arten von Updates kurze Dienstunterbrechungen und erfordern eine besondere Behandlung.
Während der geplanten Wartung werden die Mitglieder des Datenbankquorums nacheinander mit der Absicht offline geschaltet, dass ein antwortendes primäres Replikat vorhanden ist. Für Datenbanken der Kategorien Unternehmenskritisch und Premium bleibt auch mindestens ein sekundäres Replikat online, um sicherzustellen, dass keine Clientausfälle auftreten.
Wenn das primäre Replikat offline geschaltet werden muss, erfolgt ein Neukonfigurationsprozess.
- Für Datenbanken der Kategorien Unternehmenskritisch und Premium wird eines der sekundären Replikate zum neuen primären Replikat.
- Für Universell-, Standard- und Basic-Datenbanken wird das primäre Replikat auf einen anderen zustandslosen Computeknoten mit ausreichend freier Kapazität verschoben.
Was Sie bei einem geplanten Wartungsereignis erwarten können
Das Wartungsereignis kann je nach der Konstellation der primären und sekundären Replikate zu Beginn des Wartungsereignisses eine einzelne oder mehrere Neukonfiguration(en) erzeugen. Durchschnittlich gibt es 1,7 Neukonfigurationen pro geplantem Wartungsereignis. Neukonfigurationen werden normalerweise innerhalb von 30 Sekunden abgeschlossen. Der Mittelwert beträgt acht Sekunden. Wenn sie bereits verbunden ist, muss Ihre Anwendung mit dem neuen primären Replikat Ihrer Datenbank erneut eine Verbindung herstellen.
Wenn das Herstellen einer neuen Verbindung versucht wird, während die Datenbank gerade neu konfiguriert wird, bevor das neue primäre Replikat online ist, wird der Fehler 40613 (Datenbank nicht verfügbar) angezeigt: Database '{databasename}' on server '{servername}' is not currently available. Please retry the connection later.
Wenn Ihre Datenbank über eine lange ausgeführte Abfrage verfügt, wird diese Abfrage während einer Neukonfiguration unterbrochen und muss neu gestartet werden.
Wartungsfenster und Vorabbenachrichtigungen
Das Feature Wartungsfenster bietet die Möglichkeit, Zeitpläne für vorhersehbare Wartungsfenster für berechtigte Azure SQL-Datenbanken und verwaltete SQL-Instanzen zu konfigurieren. Sie können vor Wartungsfenstern auch Vorabbenachrichtigungen konfigurieren. Weitere Informationen finden Sie unter:
- Wartungsfenster für die Azure SQL-Datenbank
- Konfigurieren Sie Vorabbenachrichtigungen für Wartungsfenster für die Azure SQL-Datenbank
- Wartungsfenster für Azure SQL Managed Instance
- Konfigurieren Sie Vorabbenachrichtigungen zu Wartungsfenstern für Azure SQL Managed Instance
Simulieren eines geplanten Wartungsereignisses
Stellen Sie sicher, dass Ihre Clientanwendung gegen Wartungsereignisse gewappnet ist, bevor Sie sie in der Produktion einsetzen.
Tests verringern das Risiko von Anwendungsfehlern und tragen zur Anwendungsverfügbarkeit für Ihre Endbenutzer bei. Sie können das Verhalten Ihrer Clientanwendung während geplanter Wartungsereignisse testen, indem Sie über PowerShell, CLI oder REST-API die Resilienz gegenüber Anwendungsfehlern testen.
Weitere Informationen für Azure SQL Managed Instance finden Sie auch unter Initiieren eines manuellen Failovers. Ein manuelles Failover führt zum gleichen Verhalten wie ein Wartungsereignis, das die primäre Replik offline schaltet.
Wiederholungslogik
Jede Clientproduktionsanwendung, die eine Verbindung mit einem Clouddatenbankdienst herstellt, sollte eine stabile Wiederholungslogik für Verbindungen implementieren. Eine geeignete Logik für automatische Wiederholungsversuche trägt dazu bei, dass Rekonfigurationen für die Endbenutzer so transparent wie möglich sind.
Service Health-Warnung
Wenn Sie Warnungen im Zusammenhang mit Dienstproblemen oder geplanten Wartungsaktivitäten erhalten möchten, können Sie im Azure-Portal Service Health-Warnungen mit entsprechenden Ereignistypen und Aktionsgruppen verwenden. Weitere Informationen finden Sie unter Erstellen einer Service Health-Warnung über das Azure-Portal.
Im Azure-Portal können Sie auch die Verfügbarkeitsmetrik der Azure SQL-Datenbank überwachen und Warnungen erstellen.
Ressourcenintegrität
Wenn für Ihre Datenbank Anmeldefehler auftreten, sollten Sie im Fenster Resource Health im Azure-Portal den aktuellen Status überprüfen. Der Abschnitt Integritätsverlauf enthält den Grund für die Ausfallzeit für jedes Ereignis (wenn verfügbar).
Zugehöriger Inhalt
- Informieren Sie sich über Resource Health für Azure SQL-Datenbank und Resource Health für Azure SQL Managed Instance.
- Weitere Informationen zur Wiederholungslogik finden Sie unter Wiederholungslogik für vorübergehende Fehler.
- Konfigurieren von Zeitplänen für Wartungsfenster mit der Funktion Wartungsfenster.