Failovergruppen – Übersicht und Best Practices (Azure SQL-Datenbank)

Gilt für:: Azure SQL-Datenbank

Mit dem Feature „Failovergruppen“ können Sie die Replikation und das Failover einiger oder aller Datenbanken auf einem logischen Server auf einen logischen Server in einer anderen Region verwalten. Dieser Artikel enthält eine Übersicht über das Failovergruppenfeature mit bewährten Methoden und Empfehlungen für die Verwendung mit Azure SQL-Datenbank.

Informationen zum Einstieg finden Sie unter Konfigurieren einer Failovergruppe.

Mehr über die Azure SQL-Datenbank-Notfallwiederherstellung erfahren Sie in diesem Video:

Übersicht

Mit dem Feature „Failovergruppen“ können Sie die Replikation und das Failover von Datenbanken in eine andere Azure-Region verwalten. Sie können eine Gruppe von Datenbanken oder alle Benutzerdatenbanken in einen logischen Server einschließen, der dann auf einen anderen logischen Server repliziert wird. Hierbei handelt es sich um eine deklarative Abstraktion, die auf dem Feature Aktive Georeplikation basiert und dazu dient, die Bereitstellung und Verwaltung georeplizierter Datenbanken zu vereinfachen.

Informationen zu Geofailover-RPO und -RTO finden Sie unter Übersicht über die Geschäftskontinuität.

Endpunktumleitung

Failovergruppen bieten Listenerendpunkte mit Lese-/Schreibzugriff und schreibgeschützte Listenerendpunkte, die während Geofailovers unverändert bleiben. Sie müssen die Verbindungszeichenfolge für Ihre Anwendung nach einem Geofailover nicht ändern, da die Verbindungen automatisch an das aktuelle primäre Replikat weitergeleitet werden. Sowohl bei manueller als auch automatischer Failover-Aktivierung schaltet das Geofailover alle sekundären Datenbanken in der Gruppe zur primären Rolle um. Nach Abschluss des Geofailovers wird der DNS-Eintrag automatisch aktualisiert, um die Endpunkte in die neue Region umzuleiten.

Auslagern schreibgeschützter Workloads

Um den Datenverkehr an Ihre primären Datenbanken zu verringern, können Sie zudem mithilfe der sekundären Datenbanken in einer Failovergruppe schreibgeschützte Workloads auslagern. Verwenden Sie den schreibgeschützten Listener, um schreibgeschützten Datenverkehr an eine lesbare sekundäre Datenbank weiterzuleiten.

Wiederherstellen einer Anwendung

Wenn Sie echte Geschäftskontinuität erreichen möchten, ist das Hinzufügen einer regionalen Datenbankredundanz nur ein Teil der Lösung. Für die komplette Wiederherstellung einer Anwendung bzw. eines Diensts nach einem schwerwiegenden Fehler ist das Wiederherstellen aller Komponenten erforderlich, aus denen sich der Dienst und alle abhängigen Dienste zusammensetzen. Beispiele dieser Komponenten sind die Clientsoftware (z. B. ein Browser mit benutzerdefiniertem JavaScript), Web-Front-Ends, Speicher und DNS. Es ist wichtig, dass alle Komponenten hinsichtlich derselben Fehler gegen Ausfälle geschützt und innerhalb des RTO (Recovery Time Objective) der Anwendung wieder verfügbar sind. Daher müssen Sie alle abhängigen Dienste bestimmen und mit dem Leistungsumfang und den Funktionen vertraut sein, die sie bieten. Dann müssen Sie entsprechende Maßnahmen ergreifen, um sicherzustellen, dass Ihr Dienst während des Failovers der Dienste funktioniert, von denen er abhängig ist.

Failover-Richtlinie

Failovergruppen unterstützen zwei Failover-Richtlinien:

• Vom Kunden verwaltet (empfohlen) – Kunden können ein Failover einer Gruppe ausführen, wenn sie einen unerwarteten Ausfall bemerken, der sich auf eine oder mehrere Datenbanken in der Failover-Gruppe auswirkt. Bei Verwendung von Befehlszeilentools wie PowerShell, Azure CLI oder der Rest-API lautet der Wert der Failover-Richtlinie für den verwalteten Kunden manual.
• Microsoft verwaltet – Im Falle eines weit verbreiteten Ausfalls, der sich auf eine primäre Region auswirkt, initiiert Microsoft ein Failover aller betroffenen Failover-Gruppen, für die ihre Failover-Richtlinie so konfiguriert ist, dass sie von Microsoft verwaltet wird. Von Microsoft verwaltetes Failover wird für einzelne Failovergruppen oder eine Teilmenge von Failovergruppen in einer Region nicht initiiert. Bei Verwendung von Befehlszeilentools wie PowerShell, Azure CLI oder der Rest-API lautet der Wert der Failoverrichtlinie für Microsoft-verwaltet automatic.

Jede Failoverrichtlinie verfügt über einen eindeutigen Satz von Anwendungsfällen und entsprechenden Erwartungen an den Failoverumfang und Datenverlust, wie in der folgenden Tabelle zusammengefasst:

Vom Kunden verwaltet

In seltenen Fällen reicht die integrierte Verfügbarkeit oder hohe Verfügbarkeit nicht aus, um einen Ausfall zu minimieren, und Ihre Datenbanken in einer Failovergruppe sind möglicherweise für eine Dauer nicht verfügbar, die für die Vereinbarung auf Servicelevel (Service Level Agreement, SLA) der Anwendungen, die die Datenbanken verwenden, nicht akzeptabel ist. Datenbanken können aufgrund eines lokalisierten Problems, das sich auf nur wenige Datenbanken auswirkt, nicht verfügbar sein, oder sie kann sich auf der Ebene des Rechenzentrums, der Verfügbarkeitszone oder der Region befinden. In jedem dieser Fälle können Sie zum Wiederherstellen der Geschäftskontinuität ein erzwungenes Failover initiieren.

Das Festlegen Ihrer Failoverrichtlinie auf vom Kunden verwaltete Kunden wird dringend empfohlen, da Sie die Kontrolle darüber behalten, wann sie ein Failover initiieren und die Geschäftskontinuität wiederherstellen möchten. Sie können ein Failover initiieren, wenn sie einen unerwarteten Ausfall bemerken, der sich auf eine oder mehrere Datenbanken in der Failovergruppe auswirkt.

Von Microsoft verwaltet

Mit einer von Microsoft verwalteten Failoverrichtlinie wird die Verantwortung für die Notfallwiederherstellung an den Azure SQL-Dienst delegiert. Damit der Azure SQL-Dienst ein erzwungenes Failover initiieren kann, müssen die folgenden Bedingungen erfüllt sein:

• Das Rechenzentrum, die Verfügbarkeitszone oder der Ausfall der Region aufgrund eines Naturkatastrophenereignisses, Konfigurationsänderungen, Softwarefehler oder Hardwarekomponentenfehler und viele Datenbanken in der Region sind betroffen.
• Die Karenzzeit ist abgelaufen. Da Maßnahmen ergriffen werden müssen, um das Ausmaß des Ausfalls zu überprüfen und festzustellen, wie schnell dieser minimiert werden kann, kann die Toleranzperiode nicht auf einen Wert unter einer Stunde festgelegt werden.

Wenn diese Bedingungen erfüllt sind, initiiert der Azure SQL-Dienst erzwungene Failovers für alle Failovergruppen in der Region, für die die Failoverrichtlinie auf Microsoft verwaltet wurde.

Legen Sie die Failoverrichtlinie nur auf Microsoft fest, die verwaltet wird, wenn:

• Sie möchten die Verantwortung für die Notfallwiederherstellung an den Azure SQL-Dienst delegieren.
• Die Anwendung ist tolerant für Ihre Datenbank, die mindestens eine Stunde lang nicht verfügbar ist.
• Es ist akzeptabel, erzwungene Failover einige Zeit nach Ablauf der Nachfrist auszulösen, da die tatsächliche Zeit für das erzwungene Failover erheblich variieren kann.
• Es ist akzeptabel, dass alle Datenbanken innerhalb der Failovergruppe unabhängig vom Zonenredundanzkonfigurations- oder Verfügbarkeitsstatus fehlschlagen. Datenbanken, die für Zonenredundanz konfiguriert sind, sind zwar widerstandsfähig für Zonalfehler und sind möglicherweise nicht durch einen Ausfall betroffen, aber sie werden immer noch fehlgeschlagen, wenn sie Teil einer Failovergruppe mit einer von Microsoft verwalteten Failoverrichtlinie sind.
• Es ist akzeptabel, dass in der Failovergruppe Failovers von Datenbanken erzwungen werden, ohne die Abhängigkeit der Anwendung von anderen Azure-Diensten oder -Komponenten zu berücksichtigen, die von der Anwendung verwendet werden, was zu Leistungsbeeinträchtigungen oder Nichtverfügbarkeit der Anwendung führen kann.
• Es ist akzeptabel, eine unbekannte Menge an Datenverlust zu verursachen, da die genaue Zeit des erzwungenen Failovers nicht gesteuert werden kann, und ignoriert den Synchronisierungsstatus der sekundären Datenbanken.
• Alle primären und sekundären Datenbanken in der Failover-Gruppe und alle Geo-Replikationsbeziehungen haben dieselbe Dienstebene, Compute-Ebene (bereitgestellt oder serverlos) und Compute-Größe (DTUs oder virtuelle Kerne). Wenn das Ziel der Dienstebene (Service Level Objective, SLO) aller Datenbanken nicht übereinstimmt, wird die Failover-Richtlinie schließlich von Microsoft Managed vom Azure SQL-Dienst auf „Vom Kunden verwaltet“ aktualisiert.

Wenn ein Failover von Microsoft ausgelöst wird, wird dem Azure Monitor-Aktivitätsprotokoll ein Eintrag für den Vorgangsnamen Failover Azure SQL-Failovergruppe hinzugefügt. Der Eintrag enthält den Namen der Failovergruppe unter "Ressource", und "Ereignis", das von einem einzelnen Bindestrich (-) initiiert wird, um anzugeben, dass das Failover von Microsoft initiiert wurde. Diese Informationen finden Sie auch auf der Seite "Aktivitätsprotokoll" des neuen primären Servers oder der neuen Instanz im Azure-Portal.

Terminologie und Funktionen

• Failovergruppe

  Eine Failovergruppe ist eine benannte Gruppe von Datenbanken, die von einem einzigen logischen Server in Azure verwaltet wird und als Einheit in eine andere Azure-Region ausfallen kann, falls alle oder einige primäre Datenbanken aufgrund eines Ausfalls in der primären Region nicht mehr verfügbar sind.

  Wichtig

  Der Name der Failovergruppe muss innerhalb der .database.windows.net-Domäne global eindeutig sein.

• Server

  Einige oder alle Benutzerdatenbanken auf einem logischen Server können in einer Failovergruppe platziert werden. Außerdem unterstützt ein Server mehrere Failovergruppen auf einem einzelnen Server.

• Primärer Server/verwaltete Instanz

  Der logische Server, auf dem die primären Datenbanken in der Failovergruppe gehostet werden.

• Sekundärer Server/verwaltete Instanz

  Der logische Server, auf dem die sekundären Datenbanken in der Failovergruppe gehostet werden. Das sekundäre Replikat kann sich nicht in derselben Azure-Region befinden wie das primäre Replikat.

• Failover (kein Datenverlust)

  Beim geplanten Failover wird eine vollständige Datensynchronisierung zwischen primärer und sekundärer Datenbank ausgeführt, bevor die sekundäre Datenbank die Rolle der primären Datenbank übernimmt. Dadurch ist sichergestellt, dass keine Daten verloren gehen. Failover ist nur möglich, wenn auf die primäre Datei zugegriffen werden kann. Ein geplantes Failover wird in den folgenden Szenarien verwendet:

  • Ausführen von DR-Drills (Notfallwiederherstellung) in der Produktion, wenn ein Datenverlust nicht akzeptabel ist
  • Verschieben der Datenbanken in eine andere Region
  • Rückkehr der Datenbanken in die primäre Region, nachdem der Ausfall behoben wurde (Failback)

• Erzwungenes Failover (potenzieller Datenverlust)

  Beim ungeplanten oder erzwungenen Failover übernimmt die sekundäre Datenbank sofort die Rolle der primären Datenbank, ohne dass auf die Weitergabe kürzlicher Änderungen von der primären Datenbank gewartet wird. Dieser Vorgang kann zu Datenverlust führen. Ein ungeplantes Failover wird als Wiederherstellungsmethode bei Ausfällen verwendet, wenn auf die primäre Datenbank nicht zugegriffen werden kann. Wenn der Ausfall behoben wird, stellt die alte primäre Datenbank automatisch wieder eine Verbindung her und wird zu einer neuen sekundären Datenbank. Ein geplantes Failover kann ausgeführt werden, um ein Failback durchzuführen und die Replikate an ihre ursprünglichen primären und sekundären Rollen zurückzugeben.

• Toleranzperiode mit Datenverlust

  Da Daten mithilfe der asynchronen Replikation auf die sekundäre Replikation repliziert werden, kann das erzwungene Failover von Gruppen mit von Microsoft verwalteten Failoverrichtlinien zu Datenverlust führen. Sie können die Richtlinie für automatisches Failover entsprechend der Toleranz Ihrer Anwendung gegenüber Datenverlust anpassen. Durch Konfiguration von GracePeriodWithDataLossHours können Sie steuern, wie lange das System wartet, bevor ein erzwungenes Failover initiiert wird, das zu Datenverlust führen kann.

• Hinzufügen einzelner Datenbanken zu Failovergruppe

  Sie können mehrere einzelne Datenbanken auf demselben logischen Server in dieselbe Failovergruppe einfügen. Wenn Sie der Failovergruppe eine einzelne Datenbank hinzufügen, wird auf dem sekundären Server automatisch eine sekundäre Datenbank mit derselben Edition und Computegröße erstellt. Wenn Sie eine Datenbank hinzufügen, die bereits auf dem sekundären Server eine sekundäre Datenbank hat, erbt die Gruppe diese Verknüpfung für die Georeplikation. Wenn Sie eine Datenbank hinzufügen, die bereits eine sekundäre Datenbank auf einem Server hat, der nicht Teil der Failovergruppe ist, wird eine neue sekundäre Datenbank auf dem sekundären Server erstellt.

  Wichtig

  • Stellen Sie sicher, dass der sekundäre logische Server keine Datenbank mit demselben Namen aufweist, es sei denn, es handelt sich um eine vorhandene sekundäre Datenbank.
  • Wenn eine Datenbank In-Memory-OLTP-Objekte enthält, müssen die primäre Datenbank und die sekundäre Georeplikat-Datenbank übereinstimmende Dienstebenen aufweisen, da sich In-Memory-OLTP-Objekte im Speicher befinden. Eine niedrigere Dienstebene in der Geo-Replica-Datenbank könnte zu Problemen durch nicht genügend Arbeitsspeicher führen. Wenn dies der Fall ist, kann das Georeplikat die Datenbank nicht wiederherstellen, was dazu führt, dass die sekundäre Datenbank zusammen mit den In-Memory-OLTP-Objekten auf der sekundären Geodatenbank nicht verfügbar ist. Dies wiederum kann dazu führen, dass auch Failover nicht erfolgreich sind. Um dies zu vermeiden, stellen Sie sicher, dass die Dienstebene der sekundären Geodatenbank mit der der primären Datenbank übereinstimmt. Dienstebenenupgrades können Vorgänge zur Datengröße sein und können eine Weile dauern.

• Hinzufügen von Datenbanken im Pool für elastische Datenbanken zu Failovergruppe

  Sie können mehrere oder alle Datenbanken in einem Pool für elastische Datenbanken in dieselbe Failovergruppe einfügen. Wenn sich die primäre Datenbank in einem Pool für elastische Datenbanken befindet, wird die sekundäre Datenbank automatisch im Pool für elastische Datenbanken desselben Namens (sekundärer Pool) erstellt. Sie müssen sicherstellen, dass der sekundäre Server einen Pool für elastische Datenbanken mit genau demselben Namen und ausreichend freier Kapazität zum Hosten der sekundären Datenbanken enthält, die von der Failovergruppe erstellt werden. Wenn Sie im Pool eine Datenbank hinzufügen, die bereits im sekundären Pool eine sekundäre Datenbank hat, erbt die Gruppe diese Verknüpfung für die Georeplikation. Wenn Sie eine Datenbank hinzufügen, die bereits eine sekundäre Datenbank auf einem Server hat, der nicht Teil der Failovergruppe ist, wird eine neue sekundäre Datenbank im sekundären Pool erstellt.

• Lese-/Schreib-Failovergruppenlistener

  Ein DNS CNAME-Eintrag, der auf die aktuelle primäre Datenbank verweist. Er wird automatisch mit der Failovergruppe erstellt und ermöglicht der Lese-/Schreibworkload die transparente Verbindungswiederherstellung mit der primären verwalteten Instanz, wenn sich diese nach dem Failover ändert. Wenn die Failovergruppe auf einem Server erstellt wird, hat der DNS CNAME-Eintrag für die Listener-URL die Form <fog-name>.database.windows.net. Nach dem Failover wird der DNS-Eintrag automatisch aktualisiert, um den Hörer auf den neuen primären Server umzuleiten.

• Nur-Lese-Failovergruppenlistener

  Ein DNS CNAME-Eintrag, der auf die aktuelle sekundäre Datenbank verweist. Er wird automatisch mit der Failovergruppe erstellt und ermöglicht der schreibgeschützten SQL-Workload das transparente Verbinden mit der sekundären verwalteten Instanz, wenn sich diese nach dem Failover ändert. Wenn die Failovergruppe auf einem Server erstellt wird, hat der DNS CNAME-Eintrag für die Listener-URL die Form <fog-name>.secondary.database.windows.net. Standardmäßig ist das Failover des schreibgeschützten Listeners deaktiviert, da sichergestellt wird, dass die Leistung der primären Datei nicht beeinträchtigt wird, wenn die sekundäre Offlineversion offline ist. Es bedeutet jedoch auch, dass die schreibgeschützten Sitzungen erst dann eine Verbindung herstellen können, nachdem die sekundäre Datenbank wiederhergestellt wurde. Wenn Sie keine Ausfallzeiten für die Nur-Lese-Sitzungen tolerieren können und den primären Rechner sowohl für den Nur-Lese- als auch für den Schreib-Lese-Verkehr verwenden können, ohne dass die Leistung des primären Rechners beeinträchtigt wird, können Sie Failover für den Nur-Lese-Listener aktivieren, indem Sie die Eigenschaft AllowReadOnlyFailoverToPrimary konfigurieren. In diesem Fall wird der schreibgeschützte Datenverkehr automatisch zur primären Datenbank umgeleitet, wenn die sekundäre Datenbank nicht verfügbar ist.

  Hinweis

  Die Eigenschaft AllowReadOnlyFailoverToPrimary ist nur wirksam, wenn die Richtlinie für automatisches Failover aktiviert ist und ein automatisches Failover ausgelöst wurde. Ist die Eigenschaft in diesem Fall auf „True“ festgelegt, werden von der primären Datenbank sowohl Sitzung mit Lese-/Schreibzugriff als auch schreibgeschützte Sitzungen bedient.

• Mehrere Failovergruppen

  Sie können mehrere Failovergruppen für das gleiche Serverpaar konfigurieren, um den Umfang von Geofailovern zu steuern. Jede Gruppe führt ein unabhängiges Failover durch. Wenn Ihre Mandant-pro-Datenbank-Anwendung in mehreren Regionen bereitgestellt wird und Pools für elastische Datenbanken verwendet, können Sie diese Funktion verwenden, um primäre und sekundäre Datenbanken in jedem Pool zu kombinieren. Auf diese Weise können Sie möglicherweise die Auswirkungen eines Ausfalls auf einige Mandantendatenbanken reduzieren.

Architektur einer Failovergruppe

Eine Failovergruppe in Azure SQL-Datenbank kann eine oder mehrere Datenbanken enthalten, die in der Regel von derselben Anwendung verwendet werden. Die Failovergruppe muss auf dem primären Server konfiguriert werden und stellt eine Verbindung mit dem sekundären Server in einer anderen Azure-Region her. Die Gruppen können alle oder einige Datenbanken auf diesen Servern umfassen. Das folgende Diagramm zeigt eine typische Konfiguration einer georedundanten Cloudanwendung mit mehreren Datenbanken und einer Failovergruppe:

Wenn Sie einen Dienst entwerfen, der die Geschäftskontinuität aufrechterhalten soll, befolgen Sie die in diesem Artikel beschriebenen allgemeinen Richtlinien und Best Practices. Stellen Sie beim Konfigurieren einer Failovergruppe sicher, dass die Authentifizierung und der Netzwerkzugriff auf der sekundären Datenbank so eingerichtet sind, dass sie nach dem Geofailover ordnungsgemäß funktionieren, wenn die sekundäre Geodatenbank zur neuen primären Datenbank wird. Weitere Informationen finden Sie unter Verwalten der Sicherheit der Azure SQL-Datenbank nach der Notfallwiederherstellung. Weitere Informationen finden Sie unter Entwickeln von Cloudlösungen für die Notfallwiederherstellung.

Verwenden von Regionspaaren

Verwenden Sie beim Erstellen der Failovergruppe zwischen dem primären und dem sekundären Server gekoppelte Regionen als Failovergruppen in gekoppelten Regionen eine bessere Leistung im Vergleich zu nicht gekoppelten Regionen.

Nach sicheren Bereitstellungsmethoden aktualisiert Azure SQL-Datenbank im Allgemeinen keine gekoppelten Regionen gleichzeitig. Es ist jedoch nicht möglich vorherzusagen, für welche Region zuerst ein Upgrade ausgeführt wird, sodass die Reihenfolge der Bereitstellung nicht garantiert werden kann. Manchmal wird ihr primärer Server zuerst aktualisiert und manchmal wird es zweitens aktualisiert.

Wenn Sie georeplikations- oder Failovergruppen für Datenbanken konfiguriert haben, die nicht mit der Azure-Region-Kopplung übereinstimmen, verwenden Sie unterschiedliche Zeitpläne für Standard Tenance-Fenster für Ihre primären und sekundären Datenbanken. Sie können beispielsweise das Wartungsfenster Werktag für Ihre sekundäre Geodatenbank und das Wartungsfenster Wochenende für Ihre primäre Geodatenbank auswählen.

Anfängliches Seeding

Beim Hinzufügen von Datenbanken oder Pools für elastische Datenbanken zu einer Failovergruppe gibt es eine anfängliche Seedingphase, bevor die Datenreplikation startet. Die anfängliche Seedingphase ist der längste und aufwendigste Vorgang. Sobald das anfängliche Seeding abgeschlossen ist, werden die Daten synchronisiert, und anschließend werden nur nachfolgende Datenänderungen repliziert. Die Zeit, die für das anfängliche Seeding benötigt wird, hängt von der Größe Ihrer Daten, der Anzahl der replizierten Datenbanken, der Last für primäre Datenbanken und der Geschwindigkeit der Verbindung zwischen der primären und der sekundären Datenbank ab. Unter normalen Umständen beträgt die mögliche Seedinggeschwindigkeit für SQL-Datenbank bis zu 500 GB pro Stunde. Das Seeding wird für alle Datenbanken parallel ausgeführt.

Anzahl der Datenbanken in einer Failovergruppe

Die Anzahl der Datenbanken in einer Failovergruppe wirkt sich unmittelbar auf die Dauer von Failover- und erzwungenen Failovervorgängen aus.

• Bei einem Failover (auch als geplantes Failover bezeichnet) wird sichergestellt, dass alle primären Datenbanken vollständig mit ihrem sekundären Datenbanken synchronisiert werden und einen bereiten Status erreichen. Um eine Überforderung der Steuerungsebene zu vermeiden, werden Datenbanken in Batches vorbereitet. Daher wird dringend empfohlen, die Anzahl der Datenbanken in einer Failovergruppe zu beschränken.
• Bei einem erzwungenen Failover ist die Vorbereitungsphase kürzer, da die Datensynchronisierung nicht initiiert wird. Um schnellere und vorhersagbare Failoverzeiten zu erzielen, kann es von Vorteil sein, die Anzahl der Datenbanken in der Failovergruppe zu verkleinern.

Verwenden mehrerer Failovergruppen für das Failover mehrerer Datenbanken

Eine oder mehrere Failovergruppen können zwischen zwei Servern in verschiedenen Regionen erstellt werden (primäre und sekundäre Server). Jede Gruppe kann eine oder mehrere Datenbanken enthalten, die als Einheit wiederhergestellt werden, falls alle oder einige primäre Datenbanken aufgrund eines Ausfalls in der primären Region nicht mehr verfügbar sind. Beim Erstellen einer Failovergruppe werden sekundäre Geodatenbanken mit dem gleichen Dienstziel wie bei der primären Datenbank erstellt. Wenn Sie einer Failovergruppe eine vorhandene Georeplikationsbeziehung hinzufügen, stellen Sie sicher, dass die sekundäre Geodatenbank mit der gleichen Dienstebene und Computegröße wie die primäre Datenbank konfiguriert ist.

Verwenden des Lese-/Schreiblisteners (primär)

Verwenden Sie für Lese-/Schreibworkloads <fog-name>.database.windows.net als Servernamen in der Verbindungszeichenfolge. Verbindungen werden automatisch an die primäre Datenbank weitergeleitet. Dieser Name wird nach dem Failover nicht geändert. Beachten Sie, dass das Failover die Aktualisierung von DNS-Einträgen einschließt, damit die Clientverbindungen erst dann an die neue primäre Datenbank weitergeleitet werden, wenn der Client-DNS-Cache aktualisiert wurde. Die Gültigkeitsdauer (TTL) des DNS-Eintrags für den primären und sekundären Listener beträgt 30 Sekunden.

Verwenden des Lese-/Schreiblisteners (sekundär)

Wenn Sie über logisch isolierte schreibgeschützte Workloads verfügen, die datenlatenztolerant sind, können Sie sie auf der sekundären Geodatenbank ausführen. Verwenden Sie für schreibgeschützte Sitzungen <fog-name>.secondary.database.windows.net als Servernamen in der Verbindungszeichenfolge. Verbindungen werden automatisch an die sekundäre Geodatenbank weitergeleitet. Darüber hinaus wird empfohlen, in der Verbindungszeichenfolge die Leseabsicht anzugeben. Verwenden Sie dazu ApplicationIntent=ReadOnly.

Auf den Dienstebenen „Premium“, „Unternehmenskritisch“ und „Hyperscale“ unterstützt SQL-Datenbank die Verwendung schreibgeschützter Replikate zur Auslagerung schreibgeschützter Abfrageworkloads unter Verwendung des Parameters ApplicationIntent=ReadOnly in der Verbindungszeichenfolge. Wenn Sie eine sekundäre Geodatenbank konfiguriert haben, können Sie mit dieser Funktion eine Verbindung entweder mit einem schreibgeschützten Replikat am primären Standort oder am geografisch replizierten Standort herstellen:

Wenn Sie eine Verbindung mit einem schreibgeschützten Replikat am sekundären Standort herstellen möchten, verwenden Sie ApplicationIntent=ReadOnly und <fog-name>.secondary.database.windows.net.

Potenzielle Leistungsbeeinträchtigung nach einem Failover

Eine typische Azure-Anwendung nutzt mehrere Azure-Dienste und besteht aus mehreren Komponenten. Das Failover einer Gruppe wird basierend auf dem Status von Azure SQL-Datenbank allein ausgelöst. Andere Azure-Dienste in der primären Region sind vom Ausfall ggf. nicht betroffen, und es kann sein, dass die entsprechenden Komponenten in dieser Region weiterhin verfügbar sind. Nachdem die primären Datenbanken auf die sekundäre Region (DR-Region) umgestellt wurden, erhöht sich unter Umständen die Wartezeit zwischen den abhängigen Komponenten. Damit die Auswirkungen einer höheren Latenz auf die Leistung der Anwendung vermieden werden, stellen Sie die Redundanz aller Anwendungskomponenten in der DR-Region sicher, befolgen Sie diese Netzwerksicherheitsrichtlinien, und orchestrieren Sie das Geofailover relevanter Anwendungskomponenten zusammen mit der Datenbank.

Potenzieller Datenverlust nach einem Geofailover

Wenn ein Ausfall in der primären Region auftritt, wurden die letzten Transaktionen möglicherweise nicht in die geo-sekundäre Region repliziert, und es kann Datenverlust geben, wenn ein erzwungenes Failover ausgeführt wird.

Failback

Wenn Autofailovergruppen mit einer automatischen Failoverrichtlinie konfiguriert sind, wird ein Failover auf den sekundären Geoserver während eines Notfallszenarios gemäß der definierten Nachfrist initiiert. Das Failback auf den alten primären Server muss manuell initiiert werden.

Erforderliche Berechtigungen und Einschränkungen

Überprüfen Sie das Handbuch für die Konfiguration von Failovergruppen für eine Liste der Berechtigungen und Einschränkungen.

Programmgesteuertes Verwalten von Failovergruppen

Gruppen für automatisches Failover können auch programmgesteuert mit Azure PowerShell, Azure CLI und der REST-API verwaltet werden. Weitere Informationen finden Sie unter Konfigurieren einer Failovergruppe.

Zugehöriger Inhalt

• Beispielskripts, siehe:
  • Verwenden von PowerShell zum Konfigurieren der aktiven Georeplikation für Azure SQL-Datenbank
  • Verwenden von PowerShell zum Konfigurieren der aktiven Georeplikation für eine Pooldatenbank in Azure SQL-Datenbank
  • Hinzufügen einer Azure SQL-Datenbank-Instanz zu einer Failovergruppe mithilfe von PowerShell
• Eine Übersicht und verschiedene Szenarien zum Thema Geschäftskontinuität finden Sie unter Übersicht über die Geschäftskontinuität
• Informationen über automatisierte Sicherungen von Azure SQL-Datenbanken finden Sie unter Automatisierte SQL-Datenbanksicherungen.
• Informationen zum Verwenden automatisierter Sicherungen für die Wiederherstellung finden Sie unter Wiederherstellen einer Datenbank aus vom Dienst initiierten Sicherungen.
• Weitere Informationen zu Authentifizierungsanforderungen für einen neuen primären Server und die Datenbank finden Sie unter Verwalten der Sicherheit der Azure SQL-Datenbank nach der Notfallwiederherstellung.