Teilen über

Azure SQL-Datenbank – Leitfaden zur Notfallwiederherstellung

  • Artikel

Gilt für:: Azure SQL-Datenbank

Azure SQL Database bietet eine branchenführende Hochverfügbarkeitsgarantie von mindestens 99,99 % zur Unterstützung einer Vielzahl von Anwendungen, einschließlich unternehmenskritischer Anwendungen, die immer verfügbar sein müssen. Azure SQL Database verfügt außerdem über schlüsselfertige Business-Continuity-Funktionen, mit denen Sie im Falle eines regionalen Ausfalls eine schnelle Notfallwiederherstellung durchführen können. Dieser Artikel enthält wertvolle Informationen, mit denen Sie sich im Vorfeld der Anwendungsbereitstellung vertraut machen sollten.

Obwohl wir kontinuierlich bestrebt sind, eine hohe Verfügbarkeit zu gewährleisten, kann es vorkommen, dass der Azure SQL-Datenbank-Dienst ausfällt, sodass die Datenbank nicht verfügbar ist und Ihre Anwendung beeinträchtigt wird. Wenn unsere Dienstüberwachung Probleme erkennt, die zu weit verbreiteten Konnektivitätsfehlern, Ausfällen oder Leistungsproblemen führen, deklariert der Dienst automatisch einen Ausfall, um Sie auf dem Laufenden zu halten.

Dienstunterbrechung

Bei einem Ausfall des Azure SQL-Datenbank-Diensts können Sie an den folgenden Orten zusätzliche Details zum Ausfall anzeigen:

  • Banner des Azure-Portals

    Wenn festgestellt wird, dass Ihre Subscription betroffen ist, wird in Ihren Benachrichtigungen im Azure-Portal ein Ausfallwarnung-Dienstproblem angezeigt:

    Screenshot einer Benachrichtigung über ein Problem mit dem Azure SQL-Datenbank-Dienst im Azure-Portal.

  • Hilfe und Support oder Support und Problembehandlung

    Wenn Sie ein Supportticket über Hilfe + Support oder Support + Problembehandlung erstellen, werden Informationen zu Problemen angezeigt, die sich auf Ihre Ressourcen auswirken. Wählen Sie Details zum Ausfall anzeigen aus, um weitere Informationen und eine Zusammenfassung der Auswirkungen zu erhalten. Es wird auch eine Warnung auf der Seite Neue Supportanfrage angezeigt.

    Screenshot der Seite „Hilfe und Support“ mit einer Benachrichtigung über ein aktives Dienstintegritätsproblem.

  • Dienststatus

    Die Seite Dienststatus im Azure-Portal enthält Informationen zum globalen Azure-Rechenzentrumsstatus. Suchen Sie in der Suchleiste im Azure-Portal nach „Dienststatus“, und zeigen Sie dann Dienstprobleme in der Kategorie Aktive Ereignisse an. Sie können die Integrität einzelner Ressourcen auch auf der Seite Ressourcenintegrität einer beliebigen Ressource im Menü Hilfe anzeigen. Es folgt ein Beispielscreenshot der Seite Dienststatus mit Informationen zu einem aktiven Dienstproblem in Südostasien:

    Screenshot der Dienststatus-Seite im Azure-Portal während eines Dienstproblems in Südostasien mit Anzeige des Problems und einer Karte der betroffenen Ressourcen.

  • E-Mail-Benachrichtigung

    Wenn Sie Warnungen eingerichtet haben, wird eine E-Mail-Benachrichtigung von azure-noreply@microsoft.com gesendet, wenn ein Service-Ausfall Ihre Subscription und Ihre Ressource beeinträchtigt. Der Text der E-Mail beginnt mit „Die Aktivitätsprotokollwarnung... wurde durch ein Dienstproblem für die Azure-Subscription... ausgelöst“. Weitere Informationen zu Dienststatuswarnungen finden Sie unter Erstellen von Aktivitätsprotokollwarnungen zu Dienstbenachrichtigungen über das Azure-Portal.

  • Verfügbarkeitsmetrik

    Sie können Warnungen in der Azure SQL-Datenbank-Verfügbarkeitsmetrik im Azure-Portal überwachen und konfigurieren.

Wann sollte die Notfallwiederherstellung während eines Ausfalls initiiert werden?

Bei einem Dienstausfall, der sich auf Anwendungsressourcen auswirkt, sollten Sie die folgenden Vorgehensweisen in Betracht ziehen:

  • Die Azure-Teams arbeiten intensiv daran, die Dienstverfügbarkeit so schnell wie möglich wiederherzustellen, aber je nach Grundursache kann die Wiederherstellung manchmal Stunden in Anspruch nehmen. Wenn Ihre Anwendung eine solche signifikante Downtime tolerieren kann, können Sie einfach warten, bis der Dienst wiederhergestellt ist. In diesem Fall ist keine weitere Aktion erforderlich. Zeigen Sie die Integrität einzelner Ressourcen auf der Seite Ressourcenintegrität einer beliebigen Ressource im Menü Hilfe an. Auf der Seite Ressourcenintegrität finden Sie Updates und aktuelle Informationen zu einem Ausfall. Nach der Dienstwiederherstellung in Ihrer Region wird die Verfügbarkeit Ihrer Anwendung wiederhergestellt.

  • Die Wiederherstellung in einer anderen Azure-Region erfordert möglicherweise Änderungen an Anwendungsverbindungs-Zeichenfolgen oder die Verwendung einer DNS-Umleitung, was zu einem dauerhaften Datenverlust führen kann. Daher sollte die Notfallwiederherstellung nur durchgeführt werden, wenn sich die Ausfalldauer dem Recovery Time Objective (RTO) Ihrer Anwendung nähert. Wenn die Anwendung in der Produktion bereitgestellt wird, sollten Sie regelmäßig die Integrität der Anwendung überwachen und bestätigen, dass die Wiederherstellung nur dann gerechtfertigt ist, wenn ein längerer Ausfall der Konnektivität zwischen Anwendungsebene und Datenbank auftritt. Abhängig von der Downtimetoleranz Ihrer Anwendung und der möglichen Geschäftshaftung können Sie entscheiden, ob Sie auf die Wiederherstellung des Diensts warten oder selbst die Notfallwiederherstellung initiieren möchten.

Anleitungen zur Wiederherstellung nach Ausfällen

Wenn der Ausfall von Azure SQL-Datenbank in einer Region über einen längeren Zeitraum nicht gemildert wurde und sich auf die Vereinbarung zum Servicelevel (SLA) Ihrer Anwendung auswirkt, sollten Sie die folgenden Schritte in Betracht ziehen:

Geplantes Failover (kein Datenverlust) auf georeplizierten sekundären Server

Wenn aktive Georeplikation oder Failovergruppen aktiviert sind, überprüfen Sie, ob der Status der primären und sekundären Datenbankressourcen im Azure-Portal Online ist. Wenn ja, ist die Datenebene sowohl für die primäre als auch für die sekundäre Datenbank fehlerfrei. Initiieren Sie ein geplantes Failover von aktiven Georeplikations- oder Failovergruppen in die sekundäre Region mit Azure-Portal, T-SQL, PowerShell oder Azure CLI.

Hinweis

Ein geplantes Failover erfordert eine vollständige Datensynchronisierung vor dem Rollenwechsel und führt nicht zu Datenverlust. Abhängig von der Art des Dienstausfalls gibt es keine Garantie, dass ein geplantes Failover ohne Datenverlust erfolgreich ist, aber es lohnt sich, es als erste Wiederherstellungsoption zu versuchen.

Um einen Failover zu initiieren, verwenden Sie die folgenden Links:

Technologie Methode Schritte
Aktive Georeplikation PowerShell Failover auf georeplizierten sekundären Server mit PowerShell
T-SQL Failover auf georeplizierten sekundären Server mit T-SQL
Failovergruppen Azure CLI Failover auf sekundären Server über Azure CLI
Azure-Portal Failover auf sekundären Server im Azure-Portal
PowerShell Failover auf sekundären Server über PowerShell

Ungeplantes Failover (möglicher Datenverlust) auf georeplizierten sekundären Server

Wenn das Failover nicht ordnungsgemäß abgeschlossen wird und Fehler auftreten oder wenn der Status der primären Datenbank nicht online ist, sollten Sie ein erzwungenes Failover mit möglichem Datenverlust in der sekundären Region in Betracht ziehen.

Um einen erzwungenen Failover zu initiieren, verwenden Sie die folgenden Links:

Technologie Methode Schritte
Aktive Georeplikation Azure CLI Erzwungenes Failover zur sekundären Georeplikation über Azure CLI
Azure-Portal Erzwungenes Failover zur sekundären Georeplikation über das Azure-Portal
PowerShell Erzwungenes Failover auf sekundäre Georeplikation über PowerShell
T-SQL Erzwungenes Failover auf georeplizierten sekundären Server mit T-SQL
Failovergruppen Azure-Portal Erzwungenes Failover auf den sekundären Server über Azure-Portal, aber wählen Sie Erzwungenes Failover aus.
Azure CLI Failover auf sekundären Server über Azure CLI, aber verwenden Sie --allow-data-loss
PowerShell Failover auf sekundären Server über PowerShell, aber verwenden Sie -AllowDataLoss

Geowiederherstellung

Wenn Sie die aktive Georeplikation oder Failovergruppen nicht aktiviert haben, können Sie als letztes Mittel die Geowiederherstellung zur Wiederherstellung nach einem Ausfall verwenden. Geowiederherstellung verwendet georeplizierte Sicherungen als Quelle. Sie können eine Datenbank auf einem beliebigen logischen Server in einer beliebigen Azure-Region aus den letzten georeplizierten Sicherungen wiederherstellen. Sie können eine Geowiederherstellung anfordern, auch wenn die Datenbank oder die gesamte Region aufgrund eines Ausfalls nicht zugänglich ist.

Weitere Informationen zur geografischen Wiederherstellung über Azure CLI, das Azure-Portal, PowerShell oder die REST-API finden Sie unter geografische Wiederherstellung von Azure SQL Database.

Konfigurieren der Datenbank nach der Wiederherstellung

Wenn Sie Geofailover oder Geowiederherstellung ausführen, um Ihre Anwendung nach einem Ausfall wiederherzustellen, müssen Sie sicherstellen, dass die Verbindung mit der neuen Datenbank ordnungsgemäß konfiguriert ist, sodass der normale Anwendungsbetrieb wieder aufgenommen werden kann. Dies ist eine Prüfliste mit Aufgaben, anhand derer Sie die wiederhergestellte Datenbank für die Produktion vorbereiten können.

Wichtig

Sie sollten regelmäßige Übungen zu Ihrer Notfallwiederherstellungsstrategie durchführen, um die Anwendungstoleranz sowie alle operativen Aspekte des Wiederherstellungsverfahrens zu überprüfen. Für die anderen Ebenen Ihrer Anwendungsinfrastruktur ist möglicherweise eine Neukonfiguration erforderlich. Weitere Informationen zu resilienten Architekturschritten finden Sie in der Prüfliste für Hochverfügbarkeit und Notfallwiederherstellung in Azure SQL-Datenbank.

Aktualisieren von Verbindungszeichenfolgen

  • Wenn Sie die aktive Georeplikation oder Geowiederherstellung verwenden, müssen Sie sicherstellen, dass die Verbindung mit der neuen Datenbank ordnungsgemäß konfiguriert ist, sodass der normale Anwendungsbetrieb wieder aufgenommen werden kann. Da Ihre wiederhergestellte Datenbank auf einem anderen Server vorliegt, müssen Sie die Verbindungszeichenfolge Ihrer Anwendung so anpassen, dass sie auf den neuen Server verweist. Weitere Informationen zum Ändern von Verbindungszeichenfolgen finden Sie unter der entsprechenden Entwicklungssprache für Ihre Verbindungsbibliothek.
  • Wenn Sie Failover-Gruppen zur Wiederherstellung nach einem Ausfall verwenden und Lese-/Schreib- und schreibgeschützte Listener in Ihren Anwendungs-Verbindungszeichenfolgen verwenden, ist keine weitere Aktion erforderlich, da Verbindungen automatisch an den neuen primären Server weitergeleitet werden.

Konfigurieren von Firewallregeln

Sie müssen sicherstellen, dass die für den sekundären Server und Datenbank konfigurierten Firewallregeln mit denen übereinstimmen, die für den primären Server und die primäre Datenbank konfiguriert wurden. Weitere Informationen finden Sie unter Konfigurieren der Firewalleinstellungen.

Konfigurieren von Anmeldungen und Datenbankbenutzern

Erstellen Sie die Anmeldenamen, die in der master-Datenbank auf dem neuen primären Server vorhanden sein müssen, und stellen Sie sicher, dass diese Anmeldenamen über die geeigneten Berechtigungen in der master-Datenbank verfügen. Weitere Informationen finden Sie unter Sicherheit nach der Notfallwiederherstellung.

Einrichten von Telemetrie-Warnungen

Sie müssen sicherstellen, dass Ihre vorhandenen Einstellungen zu Warnungsregeln aktualisiert werden, sodass auf die neue primäre Datenbank und den neuen Server verwiesen wird. Weitere Informationen zu Datenbankwarnungsregeln finden Sie unter Empfangen von Warnbenachrichtigungen und Nachverfolgen der Dienstintegrität.

Aktivieren der Überwachung

Wenn Sie die Überwachung auf dem primären Server konfiguriert haben, machen Sie sie auf dem sekundären Server identisch. Weitere Informationen finden Sie unter Überwachung.

Zugehöriger Inhalt

Weitere Informationen finden Sie unter: