Freigeben über

Zuverlässigkeit in Azure SQL Managed Instance

Azure SQL Managed Instance ist eine vollständig verwaltete Plattform als Dienstdatenbankmodul (PaaS). Es bietet fast 100% Featurekompatibilität mit SQL Server. Azure SQL Managed Instance behandelt die meisten Datenbankverwaltungsfunktionen wie Upgrades, Patching, Sicherungen und Überwachung ohne Benutzerbeteiligung. Sie wird auf der neuesten stabilen Version des SQL Server-Datenbankmoduls und einem gepatchten Betriebssystem mit integrierter hoher Verfügbarkeit ausgeführt.

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 Managed Instance für eine Vielzahl potenzieller Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Ausfall von Verfügbarkeitszonen und Regionsausfällen. Außerdem wird beschrieben, wie Sie Sicherungen verwenden können, um aus anderen Arten von Problemen wiederherzustellen, wie Sie die Dienstwartung behandeln, und einige wichtige Informationen zum Azure SQL Managed Instance Service Level Agreement (SLA) erläutert.

Empfehlungen für die Produktionsimplementierung für Zuverlässigkeit

Beachten Sie für die meisten Produktionsbereitstellungen der verwalteten SQL-Instanz die folgenden Empfehlungen:

Übersicht über die Zuverlässigkeitsarchitektur

Verwaltete SQL-Instanzen mit allgemeinem Zweck werden auf einem einzelnen Knoten ausgeführt, den Azure Service Fabric verwaltet. Immer wenn das Datenbankmodul oder das Betriebssystem aktualisiert wird oder ein Fehler erkannt wird, arbeitet sql Managed Instance mit Service Fabric zusammen, um den zustandslosen Datenbankmodulprozess auf einen anderen zustandslosen Computeknoten zu verschieben, der über ausreichende freie Kapazität verfügt. Datenbankdateien werden in Azure Blob Storage gespeichert, das über integrierte Redundanzfunktionen verfügt. Daten- und Protokolldateien werden vom ursprünglichen Computeknoten getrennt und an den neu initialisierten Datenbankmodulprozess angefügt.

Verwaltete Business Critical SQL-Instanzen verwenden mehrere Replikate in einem Cluster. Der Cluster enthält zwei Arten von Replikaten:

  • Ein einzelnes primäres Replikat, auf das für Kundenworkloads mit Lese-/Schreibzugriff zugegriffen werden kann

  • Bis zu fünf sekundäre Replikate (Compute und Speicher), die Kopien von Daten enthalten

Das primäre Replikat pusht kontinuierlich und sequenziell Änderungen an die sekundären Replikate, wodurch sichergestellt wird, dass die Daten vor dem Ausführen eines Commits für jede Transaktion auf einer ausreichenden Anzahl von sekundären Replikaten gespeichert werden. 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 nicht verfügbar ist.

Sql Managed Instance and Service Fabric initiieren Failover zwischen Replikaten. Nachdem ein sekundäres Replikat zum neuen primären Replikat wird, wird ein weiteres sekundäres Replikat erstellt, um sicherzustellen, dass der Cluster über eine ausreichende Anzahl von Replikaten verfügt, um das Quorum beizubehalten. Nach Abschluss des Failovers werden Azure SQL-Verbindungen automatisch an das neue primäre Replikat oder das lesbare sekundäre Replikat basierend auf der Verbindungszeichenfolge umgeleitet.

Redundanz

Standardmäßig erreicht SQL Managed Instance Redundanz, indem Computeknoten und Daten in einem einzigen Rechenzentrum in der primären Region verteilt werden. Dieser Ansatz schützt Ihre Daten während der folgenden erwarteten und unerwarteten Ausfallzeiten:

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

  • Service-Wartungsvorgänge

  • Kleine Netzwerk- oder Stromausfälle

  • Probleme und Rechenzentrumsausfälle, die die folgenden Komponenten umfassen:

    • Das Rack, auf dem die Maschinen laufen, die Ihren Dienst unterstützen

    • Der physische Computer , auf dem der virtuelle Computer (VM) gehostet wird, auf dem das SQL-Datenbankmodul ausgeführt wird.

    • Der virtuelle Computer , der das SQL-Datenbankmodul ausführt

  • Probleme mit dem SQL-Datenbankmodul

  • Potenzielle ungeplante lokalisierte Ausfälle

Weitere Informationen dazu, wie SQL Managed Instance Redundanz bereitstellt, finden Sie unter Verfügbarkeit über lokale und Zonenredundanz.

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 Managed Instance verarbeitet automatisch wichtige Wartungsaufgaben, z. B. Patching, Sicherungen und Windows- und SQL-Datenbankmodulupgrades. Außerdem werden ungeplante Ereignisse wie zugrunde liegende Hardware-, Software- oder Netzwerkfehler behandelt. Sql Managed Instance kann auch unter den kritischsten Umständen schnell wiederhergestellt werden, wodurch sichergestellt wird, dass Ihre Daten immer verfügbar sind. Die meisten Benutzer bemerken nicht, dass kontinuierlich Upgrades durchgeführt werden.

Wenn eine Instanz gepatcht wird oder ausfällt, hat die Ausfallzeit nur minimale Auswirkungen, wenn Sie in Ihrer Anwendung eine Wiederholungslogik verwenden. Sie können die Resilienz Ihrer Anwendung auf vorübergehende Fehler testen.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Hinweis

Die Zonenredundanz ist derzeit nicht für die universelle Dienstebene der nächsten Generation verfügbar.

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.

Wenn Sie eine zonenredundante Konfiguration aktivieren, können Sie sicherstellen, dass Ihre verwaltete SQL-Instanz für eine große Anzahl von Fehlern widerstandsfähig ist, einschließlich katastrophaler Datenverluste, ohne Änderungen an der Anwendungslogik.

Die verwaltete SQL-Instanz erreicht Zonenredundanz, indem zustandslose Computeknoten in verschiedenen Verfügbarkeitszonen platziert werden. Sie basiert auf zustandsbehaftetem ZRS, das an den Knoten angehängt ist, der derzeit den aktiven SQL-Datenbankmodulprozess ausführt. Wenn ein Ausfall auftritt, wird der SQL-Datenbankmodulprozess auf einem der zustandslosen Computeknoten aktiv, der dann auf die Daten im zustandsbehafteten Speicher zugreift.

Die verwaltete SQL-Instanz erreicht Zonenredundanz, indem Replikate Ihrer verwalteten SQL-Instanz über mehrere Verfügbarkeitszonen hinweg platziert werden. Um einen Single Point of Failure auszuschließen, wird der Steuerring zudem in mehreren Zonen dupliziert. Der Steuerungsebenenverkehr wird an einen Lastenausgleich geleitet, der auch über Verfügbarkeitszonen hinweg bereitgestellt wird. Azure Traffic Manager steuert das Datenverkehrsrouting von der Steuerebene bis zum Lastenausgleich.

Anforderungen

  • Regionsunterstützung: Zonenredundanz für verwaltete SQL-Instanz wird in ausgewählten Regionen unterstützt. Weitere Informationen finden Sie unter Unterstützte Regionen.

  • Redundanz des Sicherungsspeichers: Um Zonenredundanz für Ihre verwaltete SQL-Instanz zu aktivieren, legen Sie die Sicherungsspeicherredundanz auf ZRS oder geozonenredundanten Speicher (GZRS) fest.

Kosten

Wenn Sie Zonenredundanz aktivieren, gibt es zusätzliche Kosten für Ihre verwaltete SQL-Instanz und für zonenredundante Sicherungen. Weitere Informationen finden Sie unter Preise.

Sie können Geld sparen, indem Sie sich verpflichten, Computeressourcen für einen bestimmten Zeitraum zu einem ermäßigten Satz zu verwenden, einschließlich zonenredundanter Instanzen auf der Business Critical-Dienstebene. Weitere Informationen finden Sie unter Reservations for SQL Managed Instance.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

In diesem Abschnitt wird erläutert, wie Sie die Verfügbarkeitszonenunterstützung für Ihre verwalteten SQL-Instanzen konfigurieren:

  • Zonenredundanz aktivieren: Informationen zum Konfigurieren der Zonenredundanz für neue und vorhandene Instanzen finden Sie unter Konfigurieren der Zonenredundanz.

    Alle Skalierungsvorgänge für die verwaltete SQL-Instanz, einschließlich der Aktivierung von Zonenredundanz, sind Onlinevorgänge und erfordern nur minimale Ausfallzeiten. Weitere Informationen finden Sie unter "Dauer der Verwaltungsvorgänge".

  • Zonenredundanz deaktivieren: Sie können Zonenredundanz so deaktivieren wie Sie sie aktivieren. Dieser Prozess ist ein Onlinevorgang und ähnelt dem regulären Upgrade des Dienstebenenziels. Am Ende des Prozesses wird die Instanz von zonenredundanter Infrastruktur zu einer Infrastruktur mit einer Zone migriert.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Ihre verwaltete SQL-Instanz so konfiguriert ist, dass sie zonenredundant ist und alle Verfügbarkeitszonen betriebsbereit sind:

  • Datenverkehrsrouting zwischen Zonen: Während normaler Vorgänge werden Anforderungen an den Knoten weitergeleitet, der die Computeebene der SQL Managed Instance ausführt.

  • Datenreplikation zwischen Zonen: Datenbankdateien werden in Azure Storage mithilfe von ZRS gespeichert, das an den Knoten angefügt ist, auf dem sich der derzeit aktive SQL-Datenbankmodulprozess befindet.

    Schreibvorgänge sind synchron und werden erst dann 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 geringfügig höheren Schreiblatenz im Vergleich zu lokal redundanten Speicher führen.

  • Datenverkehrsrouting zwischen Zonen: Während normaler Vorgänge werden Anforderungen an das primäre Replikat Ihrer verwalteten SQL-Instanz weitergeleitet.

  • Datenreplikation zwischen Zonen: Das primäre Replikat pusht kontinuierlich und sequenziell Änderungen an die sekundären Replikate in verschiedenen Verfügbarkeitszonen. Durch diesen Vorgang wird sichergestellt, dass Daten auf einer ausreichenden Anzahl von sekundären Replikaten beibehalten werden, bevor die einzelnen Transaktionen ausgeführt werden. Diese Replikate befinden sich in verschiedenen Verfügbarkeitszonen. 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.

    Da zonenredundante Instanzen Replikate in verschiedenen Rechenzentren mit einem abstand zwischen ihnen haben, kann die erhöhte Netzwerklatenz die Transaktions-Commit-Zeit erhöhen. Diese Erhöhung kann sich auf die Leistung einiger OLTP-Workloads (Online Transaction Processing) auswirken. Die meisten Anwendungen reagieren nicht empfindlich auf diese zusätzliche Latenz.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Ihre verwaltete SQL-Instanz so konfiguriert ist, dass sie zonenredundant ist und mindestens eine Verfügbarkeitszone nicht verfügbar ist:

  • Erkennung und Reaktion: Die verwaltete SQL-Instanz 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 Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Ressourcenintegritätswarnungen einrichten, um Sie über Probleme zu informieren. Sie können auch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich jeglicher Zonenfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.
  • Aktive Anforderungen: Wenn eine Verfügbarkeitszone nicht verfügbar ist, werden alle Anforderungen, die in der fehlerhaften Verfügbarkeitszone verarbeitet werden, beendet und müssen erneut überprüft werden. Um Ihre Anwendungen widerstandsfähig gegen diese Arten von Problemen zu gestalten, lesen Sie die Anleitung zu Resilienz für vorübergehende Fehler.

  • Datenverkehrsumleitung: Sql Managed Instance arbeitet mit Service Fabric zusammen, um das Datenbankmodul auf einen geeigneten zustandslosen Computeknoten zu verschieben, der sich in einer anderen Verfügbarkeitszone befindet und über ausreichende freie Kapazität verfügt. Nach Abschluss des Failovers werden neue Verbindungen automatisch an den neuen primären Computeknoten umgeleitet.

    Eine hohe Workload kann während des Übergangs von einem Computeknoten zum anderen Computeknoten eine Leistungsbeeinträchtigung erleben, da der neue Datenbankmodulprozess mit einem Cache für kalte Daten beginnt.

  • Datenverkehrsumleitung: Sql Managed Instance arbeitet mit Service Fabric zusammen, um ein geeignetes Replikat in einer anderen Verfügbarkeitszone auszuwählen, um das primäre Replikat zu werden. Nachdem ein sekundäres Replikat zum neuen primären Replikat wird, wird ein weiteres sekundäres Replikat erstellt, um sicherzustellen, dass der Cluster über eine ausreichende Anzahl von Replikaten verfügt, um das Quorum beizubehalten. Nach Abschluss des Failovers werden neue Verbindungen automatisch an das neue primäre Replikat oder das lesbare sekundäre Replikat basierend auf der Verbindungszeichenfolge umgeleitet.

  • 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 die Richtlinien zur Ausfallsicherheit für vorübergehende Fehler befolgt.

  • Erwarteter Datenverlust: Es wird kein Datenverlust für committete Transaktionen während eines Verfügbarkeitszonenfailovers erwartet. Noch nicht abgeschlossene Transaktionen müssen erneut versucht werden.

Zonenwiederherstellung

Wenn die Verfügbarkeitszone wiederhergestellt wird, funktioniert die verwaltete SQL-Instanz mit Service Fabric, um Vorgänge in der wiederhergestellten Zone wiederherzustellen. Es ist kein Eingreifen des Kunden erforderlich.

Test auf Zonenfehler

Die SQL Managed Instance-Plattform verwaltet Datenverkehrsrouting, Failover und Failback für zonenredundante Instanzen. 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 ihrer Anwendung überprüfen.

Widerstandsfähigkeit bei regionalen Ausfällen

Eine einzelne verwaltete SQL-Instanz wird in einer einzelnen Region bereitgestellt. Sie können jedoch eine sekundäre verwaltete SQL-Instanz in einer separaten Azure-Region bereitstellen und eine Failovergruppe konfigurieren.

Failovergruppen

Failovergruppen georeplizieren Ihre Daten automatisch und können basierend auf den Failoverrichtlinien automatisch oder manuell auf einen anderen Standort umschalten, wenn ein regionaler Ausfall auftritt.

In diesem Abschnitt werden wichtige Informationen zu Failovergruppen zusammengefasst, aber es ist wichtig, die Übersicht über Failovergruppen und bewährte Methoden zu überprüfen, um mehr darüber zu erfahren, wie sie funktionieren und wie sie konfiguriert werden.

Failoverrichtlinien

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 zwei Arten von Failoverrichtlinien konfigurieren:

  • Vom Kunden verwaltetes Failover (empfohlen): Wenn Sie eine vom Kunden verwaltete Failoverrichtlinie verwenden, können Sie entscheiden, ob ein Failover ausgeführt werden soll, das keinen Datenverlust verursacht, oder ein erzwungenes Failover, was zu Datenverlust führen kann. Erzwungenes Failover wird während eines Ausfalls als Methode zur Wiederherstellung verwendet, wenn auf die primäre Instanz nicht zugegriffen werden kann.

  • Von Microsoft verwaltetes Failover: Von Microsoft verwaltetes Failover wird nur in Ausnahmefällen verwendet, um ein erzwungenes Failover auszulösen.

Von Bedeutung

Verwenden Sie vom Kunden verwaltete Failoveroptionen, um Ihre DR-Pläne zu entwickeln, zu testen und zu implementieren. Verlassen Sie sich nicht auf ein von Microsoft verwaltetes Failover, das nur unter extremen Umständen verwendet werden kann. Ein von Microsoft verwaltetes Failover wird wahrscheinlich für eine gesamte Region initiiert. Es kann nicht für einzelne Failovergruppen, SQL-verwaltete Instanzen, Abonnements oder Kunden initiiert werden. Failover kann zu unterschiedlichen Zeiten für verschiedene Azure-Dienste auftreten. Es wird empfohlen, das kundenseitig verwaltete Failover zu verwenden.

Regionsunterstützung

Sie können eine beliebige Azure-Region für die verwaltete SQL-Instanzen innerhalb der Failovergruppe auswählen. Aufgrund der hohen Latenz von breiten Flächennetzwerken verwendet die Georeplikation einen asynchronen Replikationsmechanismus. Um Netzwerkverzögerungen zu reduzieren, wählen Sie Regionen mit geringer Latenz aus. Weitere Informationen zur Latenz zwischen Azure-Regionen finden Sie in azure-Netzwerk-Roundtrip-Latenzstatistiken.

Kosten

Wenn Sie mehrere verwaltete SQL-Instanzen in verschiedenen Regionen erstellen, werden Sie für jede verwaltete SQL-Instanz in Rechnung gestellt.

Wenn Ihre sekundäre Instanz jedoch keine Leseworkloads oder Anwendungen mit ihr verbunden hat, können Sie Lizenzkosten sparen, indem Sie das Replikat als Standbyinstanz entwerfen. Weitere Informationen finden Sie unter Konfigurieren Sie eine lizenzfreie Standby-Replik für SQL Managed Instance.

Weitere Informationen zu den Preisen für verwaltete SQL-Instanzen finden Sie unter Dienstpreisinformationen.

Konfigurieren der Unterstützung für mehrere Regionen

Informationen zum Konfigurieren einer Failovergruppe finden Sie unter Konfigurieren einer Failovergruppe für die verwaltete SQL-Instanz.

Kapazitätsplanung und -verwaltung

Während eines Failovers wird der Datenverkehr an eine sekundäre verwaltete SQL-Instanz umgeleitet. Es ist wichtig, dass Ihre sekundäre verwaltete SQL-Instanz bereit für den Empfang von Datenverkehr ist. Erstellen Sie eine sekundäre verwaltete SQL-Instanz mit derselben Dienstebene, Hardwaregenerierung und Computegröße wie die primäre Instanz.

Weitere Informationen zum Skalieren verwalteter SQL-Instanzen in einer Failovergruppe finden Sie unter Skalierungsinstanzen.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn von SQL verwaltete Instanzen für die Verwendung von Failovergruppen mit mehreren Regionen konfiguriert sind und alle Regionen betriebsbereit sind:

  • Datenverkehrsrouting zwischen Regionen: Während normaler Vorgänge wechseln Lese-/Schreibanforderungen zur einzelnen primären Instanz in der primären Region.

    Failovergruppen bieten auch einen separaten schreibgeschützten Listenerendpunkt. Bei normalen Vorgängen stellt dieser Endpunkt eine Verbindung mit der sekundären Instanz bereit, um schreibgeschützten Datenverkehr weiterzuleiten, der in der Verbindungszeichenfolge angegeben ist.

    Weitere Informationen dazu, wie Failovergruppen Datenverkehr an jede Instanz senden und wie Sie den Datenverkehr zu einem schreibgeschützten Listenerendpunkt leiten können, finden Sie in der Übersicht über Failovergruppen und bewährte Methoden.

  • Datenreplikation zwischen Regionen: Standardmäßig werden Daten asynchron von der primären Instanz in die sekundäre verwaltete SQL-Instanz repliziert.

    Da die Georeplikation asynchron ist, ist es möglich, dass Datenverlust auftreten kann, wenn Sie ein erzwungenes Failover ausführen. Sie können die Replikationsverzögerung überwachen, um den potenziellen Datenverlust während eines erzwungenen Failovers zu verstehen. Weitere Informationen finden Sie in der DR-Checkliste.

    Wenn Sie Datenverluste aus asynchroner Replikation während des Failovers beseitigen müssen, konfigurieren Sie Ihre Anwendung so, dass der aufrufende Thread blockiert wird, bis bestätigt wird, dass die letzte zugesicherte Transaktion im Transaktionsprotokoll der sekundären Datenbank übertragen und gehärtet wurde. Dieser Ansatz erfordert eine benutzerdefinierte Entwicklung und beeinträchtigt die Leistung Ihrer Anwendung. Weitere Informationen finden Sie unter Verhindern des Verlusts kritischer Daten.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn von SQL verwaltete Instanzen für die Verwendung von Failovergruppen mit mehreren Regionen konfiguriert sind, und es gibt einen Ausfall in der primären Region:

  • Erkennung und Reaktion: Die Verantwortung für die Erkennung und Reaktion hängt von der Failoverrichtlinie ab, die Ihre Failovergruppe verwendet.

    • Kundenseitig verwaltete Failoverrichtlinie: Sie sind dafür verantwortlich, den Fehler in einer Region zu erkennen und ein Failover auszulösen oder ein Failover auf die sekundäre Instanz in der Failovergruppe auszulösen.

      Wenn Sie ein Failover ausführen, wartet die verwaltete SQL-Instanz auf die Synchronisierung mit der sekundären Instanz, bevor Sie die Failoverprozedur ausführen.

      Wenn Sie ein erzwungenes Failover ausführen, wechselt die SQL Managed Instance sofort die sekundäre Instanz in die primäre Rolle, ohne auf die Replikation der letzten Änderungen von der primären Instanz zu warten. Dieser Failovertyp kann zu Datenverlusten führen.

    • Von Microsoft verwaltete Failoverrichtlinie: Von Microsoft verwaltete Failovers werden unter außergewöhnlichen Umständen ausgeführt. Wenn Microsoft ein Failover auslöst, führt die Failovergruppe automatisch ein erzwungenes Failover für die sekundäre Instanz in der Failovergruppe aus. Es wird jedoch empfohlen, eine vom Kunden verwaltete Failoverrichtlinie für Produktionsworkloads zu verwenden, damit Sie steuern können, wann das Failover auftritt.

  • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone deaktiviert ist. Sie können jedoch Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Ressourcenintegritätswarnungen einrichten, um Sie über Probleme zu informieren. Sie können auch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich jeglicher Zonenfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

  • Aktive Anforderungen: Wenn ein Failover auftritt, werden alle verarbeiteten Anforderungen beendet und müssen wiederholt werden. Um Ihre Anwendungen für diese Arten von Problemen robust zu machen, lesen Sie resilienz gegenüber vorübergehenden Fehlern.

  • Erwarteter Datenverlust: Die Menge des Datenverlusts hängt davon ab, wie Sie Ihre Anwendung konfigurieren. Weitere Informationen finden Sie unter Übersicht über Failovergruppen und bewährte Methoden.

  • Erwartete Ausfallzeiten: Während eines Failovers einer Failovergruppe kann es zu einer geringen Ausfallzeit kommen. Die Ausfallzeiten sind in der Regel weniger als 60 Minuten.

  • Datenverkehrsumleitung: Nachdem die Failovergruppe den Failoverprozess abgeschlossen hat, wird der Lese-/Schreibzugriffsdatenverkehr automatisch an die neue primäre Instanz weitergeleitet. Wenn Ihre Anwendungen die Endpunkte der Failovergruppe in ihren Verbindungszeichenfolgen verwenden, müssen sie ihre Verbindungszeichenfolgen nach dem Failover nicht ändern.

Regionswiederherstellung

Failovergruppen führen beim Wiederherstellen nicht automatisch ein Failback an die primäre Region durch. Daher liegt es in Ihrer Verantwortung, einen Failback zu initiieren.

Test auf Regionsfehler

Sie können das Failover einer Failovergruppe testen.

Das Testen einer Failovergruppe ist nur ein Teil der Durchführung eines DR-Drills. Weitere Informationen finden Sie unter Ausführen von DR-Drills.

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 sind nicht dasselbe wie die Georeplikation, und sie haben unterschiedliche Zwecke und mindern unterschiedliche Risiken.

Sql Managed Instance übernimmt automatisch vollständige, differenzielle und Transaktionsprotokollsicherungen Ihrer Datenbanken. Weitere Informationen zu den Arten von Sicherungen, deren Häufigkeit, Wiederherstellungsfunktionen, Speicherkosten und Sicherungsverschlüsselung finden Sie unter Automatisierte Sicherungen in SQL Managed Instance.

Sql Managed Instance bietet integrierte automatisierte Sicherungen und unterstützt auch vom Benutzer initiierte Kopierschutzsicherungen für Benutzerdatenbanken. Weitere Informationen finden Sie unter Kopiesicherungen.

Sicherungsreplikation

Wenn Sie automatisierte Sicherungen für Ihre verwaltete SQL-Instanz konfigurieren, können Sie angeben, wie Sicherungen repliziert werden sollen. Sicherungen, die für die Speicherung auf ZRS konfiguriert sind, weisen eine höhere Resilienz auf. Es wird empfohlen, Ihre Sicherungen so zu konfigurieren, dass sie einen der folgenden Speichertypen verwenden:

  • ZRS für Resilienz innerhalb der Region, wenn die Region Über Verfügbarkeitszonen verfügt

  • GZRS zur Verbesserung der Resilienz Ihrer Sicherungen über Regionen hinweg, wenn die Region über Verfügbarkeitszonen verfügt und mit einer anderen Region gekoppelt ist

  • GRS, wenn Ihre Region keine Verfügbarkeitszonen unterstützt, aber über eine gekoppelte Region verfügt

Weitere Informationen zu verschiedenen Speichertypen und deren Funktionen finden Sie unter Redundanz des Sicherungsspeichers.

Geowiederherstellung

Die Geowiederherstellungsfunktion ist eine einfache DR-Lösung, mit der Sie Sicherungskopien in einer anderen Azure-Region wiederherstellen können. Geo-Backup erfordert in der Regel eine erhebliche Menge an Ausfallzeiten und Datenverlust. Um eine höhere Wiederherstellbarkeit zu erzielen, wenn eine regionale Unterbrechung auftritt, sollten Sie Failovergruppen konfigurieren.

Wenn Sie geowiederherstellung verwenden, müssen Sie überlegen, wie Sie Ihre Sicherungen in Ihrer sekundären Region verfügbar machen:

  • Wenn Ihre primäre Region gekoppelt ist, verwenden Sie den GZRS- oder GRS-Sicherungsspeicher, um Geowiederherstellung in der gekoppelten Region zu unterstützen.

  • Wenn Ihre primäre Region nicht gekoppelt ist, können Sie eine benutzerdefinierte Lösung erstellen, um Ihre Sicherungen in eine andere Region zu replizieren. Erwägen Sie die Verwendung von benutzerseitig initiierten Kopiersicherungen und das Speichern in einem Speicherkonto, das Blobobjektreplikation verwendet, um in einem Speicherkonto in einer anderen Region zu replizieren.

Resilienz gegenüber Wartungsarbeiten an Diensten

Wenn sql Managed Instance Wartung für Ihre Instanz durchführt, bleibt die von SQL verwaltete Instanz vollständig verfügbar, kann aber kurzen Neukonfigurationen unterliegen. Clientanwendungen können kurze Verbindungsunterbrechungen beobachten, wenn ein Wartungsereignis auftritt. Ihre Clientanwendungen sollten die Richtlinien zur Ausfallsicherheit für vorübergehende Fehler befolgen, um die Auswirkungen zu minimieren.

Mit sql Managed Instance können Sie ein Wartungsfenster angeben, das in der Regel für Dienstupgrades und andere Wartungsvorgänge verwendet wird. Durch das Konfigurieren eines Wartungsfensters können Sie alle Nebenwirkungen wie automatische Failovers während der Geschäftszeiten minimieren. Sie können auch vorab Benachrichtigungen über die geplante Wartung erhalten.

Weitere Informationen finden Sie im Wartungsfenster in der verwalteten SQL-Instanz.

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.

Für die verwaltete SQL-Instanz gilt die Verfügbarkeits-SLA nur, wenn Ihr virtuelles Azure-Netzwerk ordnungsgemäß konfiguriert ist, sodass der Verwaltungsdatenverkehr nicht beeinträchtigt wird. Diese Konfiguration umfasst Subnetzgröße, Netzwerksicherheitsgruppen (NSGs), benutzerdefinierte Routen (UDRs), DNS-Konfiguration und andere Ressourcen, die sich auf die Verwaltung und Verwendung von Netzwerkressourcen auswirken. Weitere Informationen zur erforderlichen Netzwerkkonfiguration für die verwaltete SQL-Instanz finden Sie unter Netzwerkanforderungen.

Verwandte Inhalte

  • Last updated on