Planen von Azure-Wartungsereignissen in Azure SQL-Datenbank und Azure SQL Managed Instance

  • Artikel

Gilt für:Azure SQL-DatenbankAzure 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 Dienstverfü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.

Funktion „Wartungsfenster“

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. Vorabbenachrichtigungen für Wartungsfenster sind für Datenbanken verfügbar, für die ein nicht standardmäßiges Wartungsfenster konfiguriert ist.

  • Für Azure SQL-Datenbank sind Wartungsfenster und Vorabbenachrichtigungen für Wartungsfenster im allgemeinen verfügbar.
  • Für Azure SQL Managed Instance sind Wartungsfenster allgemein verfügbar, Vorabbenachrichtigungen sind jedoch eine Previewfunktion.

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.

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