Azure SQL-Datenbank – Leitfaden zur Notfallwiederherstellung

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:

  

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

  

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

  

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

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

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:

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.

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:

• Kontinuitätsszenarien.
• Automatisierte Sicherungen
• Stellen Sie eine Datenbank aus den vom Dienst initiierten Sicherungen wieder her.
• Informationen zu schnelleren Wiederherstellungsoptionen finden Sie unter Aktive Georeplikation und Failovergruppen.
• Lesen Sie Leitfaden zur Notfallwiederherstellung und die Prüfliste für Hochverfügbarkeit und Notfallwiederherstellung.