Freigeben über

Zuverlässigkeit in der Azure SQL-Datenbank

Azure SQL Database ist eine vollständig verwaltete Platform-as-a-Service (PaaS)-Datenbankengine, die die meisten Datenbankverwaltungsfunktionen wie Upgrades, Patches, Backups und Überwachung ohne Benutzereingriff übernimmt.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Sie azure SQL-Datenbank für eine Vielzahl potenzieller Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Ausfall der Verfügbarkeitszone und Regionsausfälle. Außerdem wird beschrieben, wie Sie Sicherungen verwenden können, um sich von anderen Arten von Problemen zu erholen, wie die Dienstwartung durchzuführen ist und es werden einige wichtige Informationen zum Azure SQL Service-Level-Agreement (SLA) hervorgehoben.

Bereitstellungsempfehlungen für die Produktion

Informationen dazu, wie Sie Azure SQL-Datenbank bereitstellen, um die Zuverlässigkeitsanforderungen Ihrer Lösung zu unterstützen, und wie sich die Zuverlässigkeit auf andere Aspekte Ihrer Architektur auswirkt, finden Sie unter Architektur bewährte Methoden für Azure SQL-Datenbank im Azure Well-Architected Framework.

Übersicht über die Zuverlässigkeitsarchitektur

SQL-Datenbank wird auf dem neuesten stabilen SQL Server-Datenbankmodul des Windows-Betriebssystems ausgeführt, einschließlich aller anwendbaren Patches.

SQL-Datenbank erreicht Redundanz, indem sie standardmäßig drei Kopien Ihrer Daten in einem einzigen Rechenzentrum in der primären Region speichert. Dieser Ansatz schützt Ihre Daten, wenn ein lokalisierter Fehler auftritt, z. B. ein Netzwerkausfall oder ein Stromausfall im kleinen Maßstab, und auch während der folgenden Ereignisse:

  • Durch Kunden initiierte Verwaltungsvorgänge, die zu einer kurzen Ausfallzeit führen

  • Service-Wartungsvorgänge

  • Probleme und Rechenzentrumsausfälle, bei denen das Rechenzentrum über die folgenden Komponenten verfügt:

    • Racks, in denen die Maschinen laufen, die Ihren Dienst bereitstellen

    • Physische Computer, auf denen der virtuelle Computer (VM) gehostet wird, auf dem das SQL-Datenbankmodul ausgeführt wird

  • Andere Probleme mit dem SQL-Datenbankmodul

  • Andere potenzielle ungeplante lokalisierte Ausfälle

SQL-Datenbank verwendet Azure Service Fabric zum Verwalten der Replikation Ihrer Datenbank.

Redundanz wird auf unterschiedliche Weise für unterschiedliche Dienstebenen der SQL-Datenbank implementiert. Weitere Informationen finden Sie unter Verfügbarkeit durch Redundanz – SQL-Datenbank.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zur Behandlung vorübergehender Fehler.

SQL-Datenbank verarbeitet automatisch wichtige Wartungsaufgaben, z. B. Patching, Sicherungen, Windows und SQL-Datenbankmodulupgrades. Außerdem werden ungeplante Ereignisse wie zugrunde liegende Hardware-, Software- oder Netzwerkfehler automatisch behandelt. SQL-Datenbank ist so konzipiert, dass sie schnell aus kritischen Fehlern wiederhergestellt werden kann, wodurch sichergestellt wird, dass Ihre Daten immer verfügbar sind. Die meisten Benutzer bemerken nicht, dass kontinuierlich Upgrades durchgeführt werden.

Wenn eine Datenbank gepatcht wird oder ausfällt, ist die Ausfallzeit nicht störend, wenn Sie die Wiederholungslogik in Ihrer Anwendung verwenden.

Sie können die Resilienz Ihrer Anwendung auf vorübergehende Fehler testen, indem Sie den Anweisungen unter Testen der Resilienz bei Anwendungsfehlern folgen.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Sie können eine zonenredundante einzelne Datenbank oder einen elastischen Pool erstellen. Zonenredundanz stellt sicher, dass Ihre Datenbank für eine große Anzahl von Fehlern widerstandsfähig ist, einschließlich katastrophaler Rechenzentrumsausfälle, ohne Änderungen an der Anwendungslogik.

Für die Dienstebene für allgemeine Zwecke stellt Zonenredundanz sicher, dass sowohl die zustandslosen Computekomponenten als auch die zustandsfreien Datenspeicherkomponenten der SQL-Datenbank ausfallsicher für einen Ausfall der Verfügbarkeitszone sind.

Für die Dienstebenen Premium, Business Critical und Hyperscale platziert Zonenredundanz Replikate Ihrer SQL-Datenbank in mehreren Azure-Verfügbarkeitszonen in Ihrer primären Region. Um einen einzelnen Fehlerpunkt (SPOF) zu vermeiden, wird der Steuerring auch in mehreren Verfügbarkeitszonen dupliziert.

Um Informationen zur Unterstützung der Verfügbarkeitszone für andere Dienstebenen anzuzeigen, müssen Sie die entsprechende Dienstebene am Anfang dieser Seite auswählen.

Anforderungen

Die Dienstebenen "Basic" und "Standard" unterstützen keine Zonenredundanz.

Zonenredundanz steht Datenbanken in den Dienstebenen Business Critical, General Purpose und Hyperscale des vCore-basierten Einkaufsmodells und nur der Premium-Serviceebene des DTU-basierten Einkaufsmodells zur Verfügung.

Für die Dienstebene für allgemeine Zwecke:

Für die Dienstebenen Premium und Business Critical:

Für die Hyperscale-Dienstebene:

Um Informationen zur Unterstützung der Verfügbarkeitszone für andere Dienstebenen anzuzeigen, müssen Sie die entsprechende Dienstebene am Anfang dieser Seite auswählen.

Überlegungen

  • Latenz: Zonenredundante Datenbanken verfügen über Replikate in separaten Rechenzentren. Die hinzugefügte Netzwerklatenz kann die Transaktions-Commit-Zeit erhöhen und die Leistung bestimmter OLTP-Workloads (Online Transaction Processing) beeinträchtigen. Die meisten Anwendungen reagieren nicht empfindlich auf diese zusätzliche Latenz.

  • master Datenbank: Wenn eine Datenbank mit einer zonenredundanten Konfiguration auf einem logischen Server erstellt wird, wird auch die master dem Server zugeordnete Datenbank automatisch zonenredundiert. Weitere Informationen dazu, wie Sie überprüfen können, ob die master Datenbank zonenredundant ist, finden Sie unter "Datenbankzone-redundante Verfügbarkeit".

Um Informationen zur Unterstützung der Verfügbarkeitszone für andere Dienstebenen anzuzeigen, müssen Sie die entsprechende Dienstebene am Anfang dieser Seite auswählen.

Kosten

Für die Dienstebene "General Purpose" fällt eine zusätzliche Gebühr an, um die Zonenredundanz für die SQL-Datenbank zu ermöglichen. Weitere Informationen finden Sie unter Preise – SQL-Datenbank.

Die Dienstebenen Premium und Business Critical bieten mehrere Replikate Ihrer Datenbank. Wenn Sie Zonenredundanz aktivieren, werden die Replikate zwischen Verfügbarkeitszonen verteilt. Diese Verteilung bedeutet, dass es keine zusätzlichen Kosten für die Aktivierung von Zonenredundanz in Ihrer SQL-Datenbank gibt, wenn sie sich auf der Premium- oder Business Critical-Dienstebene befindet.

Wenn Sie mehrere Replikate Ihrer Hyperscale-Dienstebenendatenbank aktivieren, können Sie Zonenredundanz aktivieren. Wenn Sie Zonenredundanz aktivieren, werden die Replikate zwischen Verfügbarkeitszonen verteilt. Diese Verteilung bedeutet, dass es keine zusätzlichen Kosten für die Aktivierung von Zonenredundanz in Ihrer SQL-Datenbank gibt, wenn sie sich auf der Hyperscale-Dienstebene befindet, vorausgesetzt, Sie verfügen über mehrere Replikate.

Um Informationen zur Unterstützung der Verfügbarkeitszone für andere Dienstebenen anzuzeigen, müssen Sie die entsprechende Dienstebene am Anfang dieser Seite auswählen.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

Für die Dienstebenen "Allgemeiner Zweck", "Premium" und "Geschäftskritischer Dienst":

Für die Hyperscale-Dienstebene:

  • Neue Ressourcen: Bei Hyperscale-Datenbanken und elastischen Pools muss Zonenredundanz konfiguriert werden, wenn die Datenbank erstellt wird. Weitere Informationen finden Sie unter Erstellen einer zonenredundanten Hyperscale-Datenbank.

  • Migration oder Deaktivieren der Zonenredundanz: Um Zonenredundanz in einer vorhandenen Hyperscale-Datenbank oder einem flexiblen Pool zu aktivieren oder zu deaktivieren, müssen Sie sie erneut bereitstellen. Der Prozess fügt ein sekundäres Replikat für hohe Verfügbarkeit hinzu und platziert es in einer anderen Verfügbarkeitszone.

    Weitere Informationen finden Sie unter Erneutes Bereitstellen einer zonenredundanten Hyperscale-Datenbank – SQL-Datenbank

Um Informationen zur Unterstützung der Verfügbarkeitszone für andere Dienstebenen anzuzeigen, müssen Sie die entsprechende Dienstebene am Anfang dieser Seite auswählen.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Zu erwarten ist, wenn Datenbanken für Zonenredundanz konfiguriert sind und alle Verfügbarkeitszonen betriebsbereit sind.

Für die Dienstebene für allgemeine Zwecke:

  • Datenverkehrsrouting zwischen Zonen: Anforderungen werden an einen Knoten weitergeleitet, der die SQL-Datenbank-Computeebene ausführt. Wenn Zonenredundanz aktiviert ist, befindet sich dieser Knoten möglicherweise in einer beliebigen Verfügbarkeitszone.

  • Datenreplikation zwischen Zonen: Daten- und Protokolldateien werden synchron über Verfügbarkeitszonen mithilfe von ZRS repliziert. Schreibvorgänge werden erst als abgeschlossen betrachtet, wenn die Daten in allen Verfügbarkeitszonen erfolgreich repliziert wurden. Diese synchrone Replikation stellt eine starke Konsistenz und keinen Datenverlust bei Zonenfehlern sicher. Es kann jedoch zu einer etwas höheren Schreiblatenz im Vergleich zu lokal redundanten Speicher (LRS) führen.

Für die Dienstebenen Premium und Business Critical:

  • Datenverkehrsrouting zwischen Zonen: Replikate werden über Verfügbarkeitszonen verteilt, und eines dieser Replikate wird als primäres Replikat festgelegt. Anforderungen werden an das primäre Replikat Ihrer Datenbank weitergeleitet.

  • Datenreplikation zwischen Zonen: Das primäre Replikat verschiebt ständig Änderungen an die sekundären Replikate sequenziell, um sicherzustellen, dass Die Daten auf einer ausreichenden Anzahl von sekundären Replikaten beibehalten werden, bevor jede Transaktion ausgeführt wird. Dieser Prozess garantiert, dass ein vollständig synchronisiertes Replikat immer für failover verfügbar ist, wenn das primäre Replikat oder ein lesbares sekundäres Replikat aus irgendeinem Grund nicht verfügbar ist. Wenn Zonenredundanz aktiviert ist, befinden sich diese Replikate in verschiedenen Verfügbarkeitszonen. Der Prozess kann jedoch aufgrund der Netzwerklatenz in Durchquerungszonen zu einer etwas höheren Schreiblatenz führen.

Für die Hyperscale-Dienstebene:

  • Datenverkehrsrouting zwischen Zonen: Datenbankreplikate werden über Verfügbarkeitszonen verteilt, und eines dieser Replikate wird als primäres Replikat festgelegt. Anforderungen werden an das primäre Replikat Ihrer Datenbank weitergeleitet.

  • Datenreplikation zwischen Zonen: Das primäre Datenbankreplikat überträgt Änderungen über einen zonenredundanten Protokolldienst, der alle Änderungen synchron über Verfügbarkeitszonen repliziert. Seitenserver befinden sich in jeder Verfügbarkeitszone und speichern den Status der Datenbank. Dieser Prozess garantiert, dass ein vollständig synchronisiertes Replikat immer für Failover verfügbar ist, wenn das primäre Replikat oder ein lesbares sekundäres Replikat aus irgendeinem Grund nicht verfügbar ist. Der Prozess kann jedoch im Vergleich zu LRS zu einer etwas höheren Schreiblatenz führen.

Um Informationen zur Unterstützung der Verfügbarkeitszone für andere Dienstebenen anzuzeigen, müssen Sie die entsprechende Dienstebene am Anfang dieser Seite auswählen.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Datenbanken für Zonenredundanz konfiguriert sind und es einen Ausfall der Verfügbarkeitszone gibt.

  • Erkennung und Reaktion: SQL-Datenbank ist für das Erkennen und Reagieren auf einen Fehler in einer Verfügbarkeitszone verantwortlich. Sie müssen keine Maßnahmen ergreifen, um ein Zonenfailover zu initiieren.
  • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone deaktiviert ist. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.
  • Aktive Anforderungen: Wenn eine Verfügbarkeitszone offline ist, werden alle Anforderungen, die in der fehlerhaften Verfügbarkeitszone verarbeitet werden, beendet und müssen erneut überprüft werden. Weitere Informationen dazu, wie Sie Ihre Anwendungen für diese Arten von Problemen widerstandsfähig machen, finden Sie in der Anleitung zur Resilienz für vorübergehende Fehler .

  • Datenverkehrsumleitung: Bei der allgemeinen Dienstebene verschiebt die SQL-Datenbank das Datenbankmodul auf einen anderen zustandslosen Rechenknoten in einer anderen Verfügbarkeitszone, der über ausreichende freie Kapazität verfügt. Nach Abschluss des Failovers werden neue Verbindungen automatisch an den neuen primären Rechenknoten umgeleitet.

    Weitere Informationen finden Sie auf der Dienstebene für allgemeine Zwecke.

  • Datenverkehrsumleitung: Für die Dienstebenen Premium und Business Critical wählt die SQL-Datenbank ein Replikat in einer anderen Verfügbarkeitszone aus, um als primäres Replikat zu fungieren. Nachdem ein sekundäres Replikat zum neuen primären Replikat geworden ist, wird ein weiteres sekundäres Replikat erstellt, um sicherzustellen, dass der Cluster über eine ausreichende Anzahl von Replikaten verfügt, um ein Quorum beizubehalten. Nach Abschluss des Failovers werden neue Verbindungen automatisch an das neue primäre Replikat umgeleitet (oder lesbares sekundäres Replikat basierend auf der Verbindungszeichenfolge).

    Weitere Informationen finden Sie unter Premium- und Business Critical-Dienstebenen.

  • Datenverkehrsumleitung: Wenn das primäre Replikat aufgrund des Zonenausfalls verloren gegangen ist, stuft die SQL-Datenbank für die Hyperscale-Dienstebene eines der Hochverfügbarkeitsreplikate in einer anderen Zone als neue primäre Instanz hoch.

    Weitere Informationen finden Sie unter Hyperscale-Dienstebene.

  • Erwartete Ausfallzeiten: Während eines Verfügbarkeitszonenfailovers kann es zu einer geringen Ausfallzeit kommen. Die Ausfallzeiten sind in der Regel weniger als 30 Sekunden, die Ihre Anwendung tolerieren sollte, wenn sie den Richtlinien zur Resilienz auf vorübergehende Fehler folgt.

  • Erwarteter Datenverlust: Während eines Verfügbarkeitszonenfailovers wird kein Datenverlust erwartet.

Um Informationen zur Unterstützung der Verfügbarkeitszone für andere Dienstebenen anzuzeigen, müssen Sie die entsprechende Dienstebene am Anfang dieser Seite auswählen.

Zonenwiederherstellung

Wenn die Verfügbarkeitszone wiederhergestellt wird, erstellt Azure Service Fabric automatisch Datenbankreplikate in der wiederhergestellten Verfügbarkeitszone, entfernt alle temporären Replikate, die in den anderen Verfügbarkeitszonen erstellt wurden, und setzt normales Datenverkehrsrouting an Ihre Datenbank fort. Um Unterbrechungen zu vermeiden, gibt das primäre Replikat nach der Zonenwiederherstellung nicht automatisch die ursprüngliche Zone zurück.

Test auf Zonenfehler

Die SQL-Datenbankplattform verwaltet Datenverkehrsrouting-, Failover- und Zonenwiederherstellungsverfahren für zonenredundante Datenbanken. Da dieses Feature vollständig verwaltet ist, müssen Sie die Ausfallprozesse für Verfügbarkeitszonen weder einleiten noch überprüfen. Sie können jedoch die Behandlung von Fehlern und Failovern ihrer Anwendung überprüfen, indem Sie den unter "Testen der Anwendungsfehlerresilienz" beschriebenen Prozess ausführen.

Widerstandsfähigkeit bei regionalen Ausfällen

Dieser Abschnitt enthält eine Übersicht über zwei verwandte, aber separate Features, die für die Georeplikation mehrerer Regionen der SQL-Datenbank verwendet werden können:

  • Die aktive Georeplikation repliziert eine einzelne Datenbank in eine synchronisierte sekundäre Datenbank.

  • Failovergruppen bauen auf der aktiven Georeplikation auf und bieten die Möglichkeit für ein Failover einer Gruppe von Datenbanken.

Aktive Georeplikation

Die aktive Georeplikation erstellt eine fortlaufend synchronisierte lesbare sekundäre Datenbank (die manchmal als geo-sekundäre oder georeplikat bezeichnet wird) in jeder Region für eine einzelne primäre Datenbank. Die aktive Georeplikation kann sekundäre Datenbanken in derselben Region erstellen, diese Konfiguration bietet jedoch keinen Schutz vor einem Regionsausfall. Wenn Sie die aktive Georeplikation verwenden, um Georedundanz zu erzielen, suchen Sie die sekundäre Datenbank in einer anderen Region in der primären Datenbank.

Anforderungen

Berücksichtigen Sie bei verwendung der aktiven Georeplikation die folgenden Anforderungen:

  • Regionsunterstützung:Aktive Georeplikation kann in allen Azure-Regionen aktiviert werden und erfordert nicht, dass Sie Azure-Regionspaare verwenden.

    Tipp

    SQL-Datenbank folgt einer sicheren Bereitstellungspraxis, bei der Azure versucht, Updates für gekoppelte Regionen nicht gleichzeitig bereitzustellen. Wenn Sie die aktive Georeplikation für die Verwendung von nicht gepaarten Regionen konfigurieren, legen Sie unterschiedliche Wartungsfenster für die Server in jeder Region fest. Dieser Ansatz trägt dazu bei, die Wahrscheinlichkeit zu verringern, dass es zu Konnektivitätsproblemen in beiden Regionen kommt, die durch Wartung zur gleichen Zeit verursacht werden.

  • Konfiguration: Sowohl die primäre als auch die geosekundäre Station müssen dieselbe Dienstebene aufweisen und sollten über dieselbe Computeebene, Computegröße und Sicherungsspeicherredundanz verfügen.

  • Firewall: Sowohl die primäre als auch die geo-sekundäre Sollten die gleichen IP-Adressfirewallregeln aufweisen.

  • Azure-Abonnements: Die aktive Georeplikation wird für Datenbanken in verschiedenen Azure-Abonnements unterstützt.

Überlegungen

  • Die aktive Georeplikation ist dafür ausgelegt, ein Failover für eine einzelne Datenbank bereitzustellen. Wenn Sie mehrere Datenbanken ausfallen lassen müssen, sollten Sie stattdessen Failover-Gruppen verwenden.

  • Da die Georeplikation asynchron ist, ist ein Datenverlust möglich, wenn ein Failover auftritt. Wenn Sie den Datenverlust während eines Failovers durch asynchrone Replikation beseitigen müssen, konfigurieren Sie Ihre Anwendung so, dass der aufrufende Thread blockiert wird, bis die letzte zugesicherte Transaktion übertragen und im Transaktionsprotokoll der sekundären Datenbank gehärtet wird. Dieser Ansatz erfordert eine benutzerdefinierte Entwicklung und reduziert die Leistung Ihrer Anwendung. Weitere Informationen finden Sie unter Verhindern des Verlusts kritischer Daten.

  • Weitere Informationen zu Einschränkungen und Überlegungen finden Sie unter "Aktive Georeplikation".

Kosten

Sekundäre Datenbanken werden als separate Datenbanken in Rechnung gestellt.

Wenn Sie keine sekundäre Datenbank für Lese- oder Schreibworkloads verwenden, überlegen Sie, ob Sie sie als Standby-Replikat festlegen können, um Ihre Kosten zu reduzieren.

Konfigurieren der Unterstützung für mehrere Regionen

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn eine Datenbank für die Verwendung der aktiven Georeplikation konfiguriert ist und alle Regionen betriebsbereit sind.

  • Datenverkehrsrouting zwischen Regionen: Ihre Anwendung muss so konfiguriert sein, dass Lese-/Schreibanforderungen an die primäre Datenbank gesendet werden. Sie können optional schreibgeschützte Anforderungen an eine sekundäre Datenbank senden, um die Auswirkungen von schreibgeschützten Arbeitslasten auf Ihre primäre Datenbank zu reduzieren.

  • Datenreplikation zwischen Regionen: Die Replikation zwischen der primären und der sekundären Datenbank erfolgt asynchron. Dies bedeutet, dass es zwischen dem Moment, in dem eine Änderung auf die primäre Datenbank angewendet wird, eine Verzögerung geben kann und wann sie in die sekundäre Datenbank repliziert wird.

    Wenn Sie ein Failover ausführen, entscheiden Sie, wie Sie die Möglichkeit eines Datenverlusts behandeln.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn eine Datenbank für die Verwendung der aktiven Georeplikation konfiguriert ist, und es gibt einen Ausfall in Ihrer primären Region:

  • Erkennung und Reaktion: Sie sind sowohl für das Erkennen des Ausfalls einer Datenbank oder Region als auch für das Auslösen des Failovers verantwortlich.
  • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Regionsfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

  • Aktive Anforderungen: Alle aktiven Anforderungen während des Failovers werden beendet und müssen wiederholt werden.

  • Erwarteter Datenverlust: Wenn Ihre primäre Datenbank verfügbar ist, können Sie optional ein Failover ohne Datenverlust ausführen. Der Failovervorgang synchronisiert Daten zwischen der primären und der sekundären Datenbank, bevor Rollen gewechselt werden.

    Wenn Ihre primäre Datenbank nicht verfügbar ist, müssen Sie möglicherweise ein erzwungenes Failover ausführen, was zu Datenverlust führt. Sie können die Menge des Datenverlusts schätzen, indem Sie die Replikationsverzögerung überwachen. Weitere Informationen finden Sie unter Überwachen der SQL-Datenbank mit Metriken und Warnungen.

  • Erwartete Ausfallzeiten: Während eines Failovers gibt es in der Regel bis zu 60 Sekunden Ausfallzeiten. Stellen Sie sicher, dass Ihre Anwendung vorübergehende Fehler verarbeitet , damit sie aus kurzen Ausfallzeiten wiederhergestellt werden kann. Außerdem wirkt sich das schnelle Neukonfigurieren der Anwendung zum Herstellen einer Verbindung mit der neuen primären Datenbank auf die ausfallzeiten aus, die Sie erleben.

  • Datenverkehrsumleitung: Sie sind dafür verantwortlich, Ihre Anwendung neu zu konfigurieren, um Anforderungen an die neue primäre Datenbank zu senden. Wenn Sie über ein transparentes Failover verfügen müssen, sollten Sie Failovergruppen verwenden.

Regionswiederherstellung

Nachdem die primäre Region wiederhergestellt wurde, können Sie manuell einen Failback für den primären Bereich ausführen, indem Sie ein weiteres Failover ausführen.

Test auf Regionsfehler

Sie können einen Regionsausfall simulieren, indem Sie jederzeit ein manuelles Failover auslösen. Sie können ein Failover (kein Datenverlust) oder ein erzwungenes Failover auslösen.

Failovergruppen

Failover-Gruppen basieren auf der aktiven Georeplikation. Mit Failovergruppen können Sie die folgenden Vorgänge ausführen:

  • Replizieren Sie eine Reihe von Datenbanken von einem einzigen logischen Server in einer beliebigen Kombination von Azure-Regionen.

  • Führen Sie ein Failover für die Datenbanken als Gruppe aus.

  • Verwenden Sie Verbindungsendpunkte, die automatisch Verbindungen zum primären Ziel leiten.

Anforderungen

  • Regionsunterstützung: Failovergruppen können in allen Azure-Regionen erstellt werden und erfordern nicht, dass Sie Azure-Regionspaare verwenden.

    Tipp

    Wenn Sie eine Failovergruppe mit nicht gepaarten Regionen konfigurieren, sollten Sie verschiedene Wartungsfenster für die Server in jeder Region festlegen. Dieser Ansatz trägt dazu bei, die Wahrscheinlichkeit zu verringern, dass es zu Konnektivitätsproblemen in beiden Regionen kommt, die durch Wartung zur gleichen Zeit verursacht werden.

  • Konfiguration: Sekundäre Datenbanken in einer Failovergruppe sollten dieselbe Dienstebene, Computeebene, Computegröße, IP-Adressfirewallregeln und Sicherungsspeicherredundanz wie die primäre Datenbank aufweisen.

Überlegungen

  • Zonenredundanz: Wenn für die Hyperscale-Dienstebene Zonenredundanz aktiviert ist, wird diese automatisch auch für sekundäre Datenbanken aktiviert.
  • Zonenredundanz: Sekundäre Datenbanken verfügen nicht standardmäßig über Zonenredundanz, aber Sie können sie später aktivieren.

  • Möglicher Datenverlust: Da die Georeplikation asynchron ist, ist es möglich, dass Datenverlust auftritt, wenn ein Failover eintritt. Wenn Sie Datenverluste aus asynchroner Replikation während des Failovers beseitigen müssen, können Sie Ihre Anwendung so konfigurieren, dass der aufrufende Thread blockiert wird, bis die letzte zugesicherte Transaktion übertragen und im Transaktionsprotokoll der sekundären Datenbank gehärtet wird. Dieser Ansatz erfordert eine benutzerdefinierte Entwicklung und reduziert die Leistung Ihrer Anwendung. Weitere Informationen finden Sie unter Verhindern des Verlusts kritischer Daten.

  • Weitere Informationen zu Einschränkungen und wichtigen Überlegungen finden Sie unter Failovergruppen.

Kosten

Sekundäre Datenbanken werden als separate Datenbanken in Rechnung gestellt.

Wenn Sie keine sekundäre Datenbank für Lese- oder Schreibworkloads verwenden, überlegen Sie, ob Sie sie als Standby-Replikat festlegen können, um Ihre Kosten zu reduzieren.

Konfigurieren der Unterstützung für mehrere Regionen

  • Failovergruppen aktivieren: Sie konfigurieren eine Failovergruppe auf einem logischen Server. Sie können alle Datenbanken auf dem logischen Server zur Failovergruppe hinzufügen, oder Sie können eine Teilmenge der hinzuzufügenden Datenbanken auswählen.

    Wenn Sie eine Failovergruppe erstellen, wählen Sie die Failoverrichtlinien aus, die angeben, wer für das Erkennen eines Ausfalls und ausführen eines Failovers verantwortlich ist. Sie können entweder das vom Kunden verwaltete Failover, das empfohlen wird, oder das von Microsoft verwaltete Failover konfigurieren.

    Von Bedeutung

    Ein von Microsoft initiiertes Failover tritt wahrscheinlich nach einer erheblichen Verzögerung auf und erfolgt auf best-effort-Basis. Das Failover von Datenbanken kann zu einem anderen Zeitpunkt erfolgen als das Failover anderer Azure-Dienste. Weitere Informationen finden Sie unter Konfigurieren einer Failovergruppe für SQL-Datenbank.

    Nachdem Sie die Failovergruppe konfiguriert haben, kann die initiale Aussaatphase einige Zeit in Anspruch nehmen.

  • Failovergruppen deaktivieren: Sie können eine einzelne Datenbank aus einer Failovergruppe entfernen, eine gesamte Failovergruppe entfernen oder eine Datenbank in eine andere Failovergruppe verschieben.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn eine Datenbank innerhalb einer Failovergruppe konfiguriert ist und alle Regionen betriebsbereit sind.

  • Datenverkehrsrouting zwischen Regionen: Für Lese-/Schreib- und schreibgeschützte Workloads bietet eine Failovergruppe zwei Listenerendpunkte, mit denen Sie Ihre Anwendungen verbinden können. Verwenden Sie die Listenerendpunkte der Failovergruppe, um Downtime während Failovers zu minimieren. Bei normalen Vorgängen tritt das folgende Routingverhalten auf:

    • Der Lese-/Schreib-Listenerendpunkt leitet alle Anforderungen an die primären Datenbanken weiter.

    • Der schreibgeschützte Listener-Endpunkt leitet alle Anforderungen an eine lesbare sekundäre Datenbank weiter.

  • Datenreplikation zwischen Regionen: Die Georeplikation zwischen der primären und der sekundären Datenbank erfolgt asynchron. Diese Latenz bedeutet, dass es eine Verzögerung zwischen einer Änderung gibt, die auf die primäre Datenbank angewendet wird und wann sie in die sekundäre Datenbank repliziert wird.

    Wenn Sie ein Failover ausführen, entscheiden Sie, wie Sie die Möglichkeit eines Datenverlusts behandeln.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn eine Datenbank in einer Failovergruppe konfiguriert ist und es einen Ausfall in Ihrer primären Region gibt:

  • Die Erkennung und Reaktion hängt von der verwendeten Failoverrichtlinie ab.

    • Vom Kunden initiiertes Failover: Sie sind für das Erkennen des Ausfalls einer Datenbank oder Region und für das Auslösen des Failovers verantwortlich.

    • Von Microsoft initiiertes Failover: Microsoft löst Failover für alle Failovergruppen in der betroffenen Region aus. Microsoft erwartet, dass diese Art von Failover nur in Ausnahmefällen ausgeführt wird. Verlassen Sie sich nicht auf das von Microsoft verwaltete Failover für die meisten Lösungen. Weitere Informationen finden Sie unter Failoverrichtlinie – von Microsoft verwaltet.

  • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Regionsfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

  • Aktive Anforderungen: Alle aktiven Anforderungen während des Failovers werden beendet und müssen wiederholt werden.

  • Erwarteter Datenverlust: Der Datenverlust hängt von der verwendeten Failoverrichtlinie ab.

    • Vom Kunden initiiertes Failover: Wenn Ihre primäre Datenbank verfügbar ist, können Sie optional ein Failover ohne Datenverlust ausführen. Der Failovervorgang synchronisiert Daten zwischen der primären und der sekundären Datenbank, bevor Rollen gewechselt werden.

      Wenn Ihre primäre Datenbank nicht verfügbar ist, müssen Sie möglicherweise ein erzwungenes Failover ausführen, was zu Datenverlust führt. Sie können die Menge des Datenverlusts schätzen, indem Sie die Replikationsverzögerung überwachen. Weitere Informationen finden Sie unter Überwachen der SQL-Datenbank mit Metriken und Warnungen.

    • Von Microsoft initiiertes Failover: Ein von Microsoft verwaltetes Failover wird nur in Ausnahmefällen ausgelöst. Von Microsoft verwaltete Failovers sind erzwungene Failover, was bedeutet, dass einige Datenverluste erwartet werden. Sie können nicht steuern, wie viele Datenverluste auftreten können.

  • Erwartete Ausfallzeiten: Ausfallzeiten hängen von der verwendeten Failoverrichtlinie ab.

    • Vom Kunden initiiertes Failover: Während eines Failovers gibt es in der Regel bis zu 60 Sekunden Ausfallzeiten. Stellen Sie sicher, dass Ihre Anwendung vorübergehende Fehler verarbeitet , damit sie aus kurzen Ausfallzeiten wiederhergestellt werden kann.

    • Von Microsoft initiiertes Failover: Sie können einen Karenzzeitraum angeben, der bestimmt, wie lange Microsoft warten soll, bevor das Failover initiiert wird. Die mindeste Karenzzeit beträgt eine Stunde. Die Microsoft-Antwortzeit wird jedoch mindestens mehrere Stunden dauern.

  • Datenverkehrsumleitung: Während eines Failovers aktualisiert SQL-Datenbank die Lese-/Schreib- und schreibgeschützten Listenerendpunkte, um den Datenverkehr gezielt zu den neuen primären und sekundären Datenbanken zu leiten.

    Wenn die neue sekundäre Datenbank (zuvor die primäre Datenbank) nicht verfügbar ist, kann der Read-Only-Listener-Endpunkt keine Verbindung herstellen, bis die neue sekundäre Datenbank verfügbar ist.

Regionswiederherstellung

Sie sind für das Failback in die primäre Region verantwortlich, wenn dies erforderlich ist. Sie können manuell einen Failback in der primären Region ausführen, indem Sie ein vom Kunden verwaltetes Failover ausführen.

Auch wenn Microsoft das ursprüngliche Failover initiiert hat, sind Sie weiterhin dafür verantwortlich, bei Bedarf in die vorherige Region zurückzuwechseln.

Test auf Regionsfehler

Sie können einen Regionsausfall simulieren, indem Sie jederzeit ein manuelles Failover auslösen. Sie können ein Failover (kein Datenverlust) oder ein erzwungenes Failover auslösen.

Sichern und Wiederherstellen

Erstellen Sie Sicherungen Ihrer Datenbanken, um vor verschiedenen Risiken, einschließlich Datenverlust, zu schützen. Sicherungen können wiederhergestellt werden, um versehentlichen Datenverlust, Beschädigungen oder andere Probleme zu beheben. Sicherungen unterscheiden sich von Zonenredundanz, aktiver Georeplikation oder Failovergruppen und haben unterschiedliche Zwecke. Weitere Informationen finden Sie unter Redundanz, Replikation und Sicherung.

SQL-Datenbank stellt automatische Sicherungen Ihrer Datenbanken bereit. Weitere Informationen zur Sicherungshäufigkeit, die sich auf die Menge des Datenverlusts auswirken kann, wenn Sie eine Sicherung wiederherstellen müssen, finden Sie unter Automatisierte Sicherungen in der SQL-Datenbank.

Sicherungsspeicher

Sie können ihre automatisierten Sicherungen in LRS oder ZRS speichern. Wenn Sie eine Region verwenden, die gekoppelt ist, können Sie Ihre automatisierten Sicherungen mithilfe von georedundanten Speicher in die gekoppelte Region replizieren. Diese Funktion ermöglicht die geo-Wiederherstellung Ihrer Sicherungen in der gekoppelten Region. Weitere Informationen finden Sie unter Automatisierte Sicherungen in der SQL-Datenbank.

Wenn Sie eine nicht gekoppelte Region verwenden oder wenn Sie Sicherungen in eine andere als die gekoppelte Region replizieren müssen, sollten Sie die Datenbank exportieren und die exportierte Datei in einem Speicherkonto speichern, das blob-Objektreplikation verwendet, um auf ein Speicherkonto in einer anderen Region zu replizieren. Weitere Informationen finden Sie unter Exportieren einer Datenbank.

Resilienz gegenüber Wartungsarbeiten an Diensten

Wenn SQL-Datenbank Wartungen für Ihre Datenbanken und Pools für elastische Datenbanken durchführt, wird für Ihre Datenbank möglicherweise automatisch ein Failover auf ein sekundäres Replikat durchgeführt. Clientanwendungen können kurze Verbindungsunterbrechungen beobachten, wenn ein Failover auftritt. Ihre Clientanwendungen sollten die Richtlinien zur Ausfallsicherheit für vorübergehende Fehler befolgen, um die Auswirkungen zu minimieren.

Mithilfe der SQL-Datenbank können Sie ein Wartungsfenster angeben, das in der Regel für Dienstupgrades und andere Wartungsvorgänge verwendet wird. Das Konfigurieren eines Wartungsfensters kann Ihnen helfen, alle Nebeneffekte wie automatische Failovers während der Geschäftszeiten zu minimieren. Sie können auch vorab Benachrichtigungen über die geplante Wartung erhalten.

Die Plattform verwaltet automatisch die Gateways, die für die Verarbeitung von Verbindungen mit SQL-Datenbank verwendet werden. Upgrades oder Wartungsvorgänge können auch kurze Verbindungsunterbrechungen verursachen, die von Clients wiederholt werden können.

Weitere Informationen finden Sie im Wartungsfenster in der SQL-Datenbank.

Service-Level-Vereinbarung

Der Service level agreement (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit jedes Diensts und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter SLAs für Onlinedienste.

Die Vereinbarung auf Dienstebene für SQL-Datenbank beschreibt die erwartete Verfügbarkeit des Diensts und den erwarteten Wiederherstellungspunkt und die Wiederherstellungszeit für die aktive Georeplikation.

Wenn Sie eine zonenredundante Datenbank oder einen elastischen Pool bereitstellen und eine unterstützte Dienstebene verwenden, ist die Verfügbarkeits-SLA höher.

Verwandte Inhalte

  • Last updated on