Teilen über


Konfigurieren einer Failovergruppe für Azure SQL-Datenbank

Gilt für:: Azure SQL-Datenbank

In diesem Artikel wird erläutert, wie Sie eine Failovergruppe für eine Einzel- oder Pooldatenbank in Azure SQL-Datenbank über das Azure-Portal und Azure PowerShell konfigurieren.

Informationen zu End-to-End-Skripts erfahren Sie, wie Sie einer Failovergruppe mit Azure PowerShell oder der Azure CLI eine einzelne Datenbank hinzufügen.

Voraussetzungen

Beachten Sie die folgenden Voraussetzungen für die Erstellung Ihrer Failovergruppe für eine Einzeldatenbank:

  • Ihre primäre Datenbank sollte bereits erstellt werden. Erstellen Sie ein Singleton, um zu beginnen.
  • Wenn Ihr sekundärer Server bereits in einer anderen Region als der primäre Server existiert, müssen die Serveranmeldung und die Firewall-Einstellungen mit denen des primären Servers übereinstimmen.

Erstellen einer Failovergruppe

Sie können Ihre Failover-Gruppe erstellen und ihr eine einzelne Datenbank hinzufügen, indem Sie das Azure-Portal, die PowerShell und die Azure CLI verwenden.

Wichtig

Wenn Sie eine sekundäre Datenbank löschen müssen, nachdem sie zu einer Failover-Gruppe hinzugefügt wurde, entfernen Sie sie aus der Failover-Gruppe, bevor Sie die Datenbank löschen. Wenn eine sekundäre Datenbank vor dem Entfernen aus der Failovergruppe gelöscht wird, kann dies zu unvorhersehbarem Verhalten führen.

Gehen Sie folgendermaßen vor, um Ihre Failover-Gruppe zu erstellen und Ihre einzelne Datenbank über das Azure-Portal hinzuzufügen:

  1. Wenn Sie den logischen Server kennen, auf dem Ihre Datenbank gehostet wird, wechseln Sie direkt in die Azure-Portal. Wenn Sie den Server finden müssen, gehen Sie folgendermaßen vor:

    1. Wählen Sie Azure SQL im Dienstmenü aus. Wenn Azure SQL nicht in der Liste aufgeführt wird, wählen Sie Alle Dienste aus, und geben Sie dann Azure SQL in das Suchfeld ein. (Optional:) Wählen Sie den Stern neben Azure SQL aus, um es zu favorisieren und als Element im Dienstmenü hinzuzufügen.
    2. Suchen Sie auf der Azure SQL-Seite die Datenbank, die Sie einer Failovergruppe hinzufügen möchten, und wählen Sie sie aus, um den SQL-Datenbankbereich zu öffnen.
    3. Wählen Sie im Bereich Übersicht der SQL-Datenbank unter Servername den Namen des Servers aus, um den Bereich SQL Server zu öffnen.

    Screenshot zum Öffnen des Servers für eine einzelne Datenbank im Azure-Portal.

  2. Wählen Sie im Menü SQL Server-Ressource die Option Failovergruppen unter Datenverwaltung aus. Wählen Sie +Gruppe hinzufügen, um die Failovergruppenseite zu öffnen, auf der Sie eine neue Failovergruppe erstellen können.

    Screenshot mit hervorgehobener Option Neue Failovergruppe hinzufügen auf der Seite Failovergruppen im Azure-Portal.

  3. Auf der Seite Failovergruppe:

    1. Geben Sie einen Failovergruppennamen an.
    2. Wählen Sie einen vorhandenen sekundären Server aus, oder erstellen Sie einen neuen Server, indem Sie unter Server erstellen Neu erstellen auswählen. Der sekundäre Server in der Failovergruppe muss sich in einer anderen Region befinden als der primäre Server.
    3. Wählen Sie Datenbank konfigurieren aus, um die Seite Datenbanken für Failovergruppen zu öffnen.

    Screenshot des Failover-Gruppenfensters im Azure-Portal.

  4. Auf der Seite Datenbanken für Failovergruppe:

    1. Wählen Sie die Datenbanken, die Sie der Failover-Gruppe hinzufügen möchten (Nr. 1 im Screenshot).
    2. (Optional) Wählen Sie Ja aus, wenn Sie diese Datenbanken als Standby-Replikate festlegen möchten, die nur für die Notfallwiederherstellung verwendet werden sollen (#2 im Screenshot). Aktivieren Sie das Kontrollkästchen, um zu bestätigen, dass Sie das Replikat für den Standby-Modus verwenden.
    3. Verwenden Sie Auswählen, um die Datenbankauswahl zu speichern und zur Seite Failovergruppe zurückzukehren (im Screenshot nicht sichtbar).

    Screenshot der Datenbanken des Failover-Gruppenfensters im Azure-Portal.

  5. Verwenden Sie Erstellen auf der Seite Failover-Gruppe, um Ihre Failovergruppe zu erstellen.

Testen des geplanten Failovers

Testen Sie das Failover Ihrer Failovergruppe mithilfe des Azure-Portals oder PowerShell.

Führen Sie die folgenden Schritte aus, um die Ausfallsicherung Ihrer Failover-Gruppe mithilfe des Azure-Portals zu testen:

  1. Wenn Sie den logischen Server kennen, auf dem Ihre Datenbank gehostet wird, wechseln Sie direkt in die Azure-Portal. Wenn Sie den Server finden müssen, gehen Sie folgendermaßen vor:

    1. Wählen Sie Azure SQL im Dienstmenü aus. Wenn Azure SQL nicht in der Liste aufgeführt wird, wählen Sie Alle Dienste aus, und geben Sie dann Azure SQL in das Suchfeld ein. (Optional:) Wählen Sie den Stern neben Azure SQL aus, um es zu favorisieren und als Element im Dienstmenü hinzuzufügen.
    2. Suchen Sie auf der Azure SQL-Seite die Datenbank, für die Sie Failover testen möchten, und wählen Sie sie aus, um den SQL-Datenbankbereich zu öffnen.
    3. Wählen Sie im Bereich Übersicht der SQL-Datenbank unter Servername den Namen des Servers aus, um den Bereich SQL Server zu öffnen.

    Screenshot zum Öffnen des Servers für eine einzelne Datenbank im Azure-Portal.

  2. Wählen Sie im SQL-Server-Ressourcenmenü unter Datenverwaltung die Option Failover-Gruppen und wählen Sie dann eine vorhandene Failover-Gruppe aus, um die Seite Failover-Gruppe zu öffnen.

    Der Screenshot zeigt Failovergruppen, aus denen Sie eine Failovergruppe für Ihren SQL Server auswählen können.

  3. Auf der Seite Failovergruppe:

    1. Überprüfen Sie, welcher Server der primäre und welcher der sekundäre ist.
    2. Wählen Sie in der Befehlsleiste Failover aus, um ein Failover für die Failovergruppe mit Ihrer Datenbank durchzuführen.
    3. Wählen Sie in der Meldung, dass die TDS-Sitzungen getrennt werden, Ja aus.

    Screenshot der Seite Failovergruppe im Azure-Portal mit ausgewählter Ausfallsicherung.

  4. Überprüfen Sie, welcher Server jetzt der primäre und welcher der sekundäre ist. Nach erfolgreichem Failover tauschen die beiden Server ihre Rollen, so dass der ehemalige Primärserver zum Sekundärserver wird.

  5. (Optional) Wählen Sie erneut Failover aus, um die Server auf ihre ursprünglichen Rollen zurückzusetzen.

Informationen zu End-to-End-Skripts erfahren Sie, wie Sie einer Failovergruppe mit Azure PowerShell oder der Azure CLI einen elastischen Pool hinzufügen.

Voraussetzungen

Beachten Sie die folgenden Voraussetzungen für die Erstellung Ihrer Failovergruppe für eine Pooldatenbank:

  • Ihr primärer elastischer Pool sollte bereits vorhanden sein. Elastischen Pool erstellen und loslegen.
  • Wenn Ihr sekundärer Server bereits existiert, müssen die Serveranmeldung und die Firewall-Einstellungen mit denen des primären Servers übereinstimmen.

Erstellen einer Failovergruppe

Erstellen Sie die Failovergruppe für Ihren elastischen Pool mithilfe des Azure-Portals, der PowerShell oder der Azure CLI.

Wichtig

Wenn Sie eine sekundäre Datenbank löschen müssen, nachdem sie zu einer Failovergruppe hinzugefügt wurde, entfernen Sie sie aus der Failovergruppe, bevor Sie die Datenbank löschen. Wenn eine sekundäre Datenbank vor dem Entfernen aus der Failovergruppe gelöscht wird, kann dies zu unvorhersehbarem Verhalten führen.

Gehen Sie folgendermaßen vor, um Ihre Failovergruppe zu erstellen und Ihren elastischen Pool über das Azure-Portal hinzuzufügen:

  1. Rufen Sie im Azure-Portal die Seite SQL Pool für elastische Datenbanken erstellen auf. Erstellen eines Pools für elastische Datenbanken, der:

    • denselben Namen wie der Pool für elastische Datenbanken auf dem primären Server hat.
    • einen sekundären Server verwendet, den Sie für die Failovergruppe verwenden möchten. Der sekundäre Server muss sich in einer anderen Region befinden als der primäre Server, und die Serveranmeldung und die Firewall-Einstellungen müssen mit denen des primären Servers übereinstimmen. Erstellen Sie einen neuen Server, wenn der sekundäre Server noch nicht existiert.
  2. Wenn Sie den logischen Server kennen, auf dem Ihr primärer Pool für elastische Datenbanken gehostet wird, wechseln Sie direkt in die Azure-Portal. Wenn Sie den Server finden müssen, gehen Sie folgendermaßen vor:

    1. Wählen Sie Azure SQL im Dienstmenü aus. Wenn Azure SQL nicht in der Liste aufgeführt wird, wählen Sie Alle Dienste aus, und geben Sie dann Azure SQL in das Suchfeld ein. (Optional:) Wählen Sie den Stern neben Azure SQL aus, um es zu favorisieren und als Element im Dienstmenü hinzuzufügen.
    2. Suchen Sie auf der Azure SQL-Seite den Pool für elastische Datenbanken, den Sie einer Failovergruppe hinzufügen möchten, und wählen Sie ihn aus, um den SQL-Pool für elastische Datenbankenbereich zu öffnen.
    3. Wählen Sie im Bereich Übersicht des SQL-Pools für elastische Datenbanken unter Servername den Namen des Servers aus, um den Bereich SQL Server zu öffnen.

    Screenshot zur Auswahl des Servers für den Pool für elastische Datenbanken im Azure-Portal.

  3. Wählen Sie im Menü SQL Server-Ressource die Option Failovergruppen unter Datenverwaltung aus. Wählen Sie +Gruppe hinzufügen, um die Failovergruppenseite zu öffnen, auf der Sie eine neue Failovergruppe erstellen können.

    Screenshot: Seite „Failovergruppen“ im Azure-Portal.

  4. Auf der Seite Failovergruppe:

    1. Geben Sie einen Failovergruppennamen an.
    2. Wählen Sie einen vorhandenen sekundären Server aus. Der sekundäre Server in der Failovergruppe muss sich in einer anderen Region als der primäre Server befinden und einen Pool für elastische Datenbanken mit dem gleichen Namen wie der primäre Server enthalten.
    3. Wählen Sie Datenbank konfigurieren aus, um die Seite Datenbanken für Failovergruppen zu öffnen.

    Screenshot zum Hinzufügen eines Pools für elastische Datenbanken zu einer Failovergruppe im Azure-Portal.

  5. Wählen Sie auf der Seite Datenbanken für Failovergruppen die Pooldatenbanken aus, die Sie der Failovergruppe hinzufügen möchten. Verwenden Sie Auswählen, um die Datenbankauswahl zu speichern und zur Seite Failovergruppe zurückzukehren.

    Screenshot der Datenbanken des Failover-Gruppenfensters im Azure-Portal.

  6. Wählen Sie Erstellen auf der Seite Failover-Gruppe, um Ihre Failovergruppe zu erstellen. Durch das Hinzufügen des Pool für elastische Datenbanken zur Failovergruppe wird automatisch der Georeplikationsprozess gestartet.

Testen des geplanten Failovers

Testen Sie das Failover Ihres Pools für elastische Datenbanken ohne Datenverlust, indem Sie das Azure-Portal, PowerShell oder die Azure CLI verwenden.

Führen Sie ein Failover für Ihre Failovergruppe auf den sekundären Server und anschließend ein Failback mit dem Azure-Portal aus.

  1. Wenn Sie den logischen Server kennen, auf dem Ihr primärer Pool für elastische Datenbanken gehostet wird, wechseln Sie direkt in die Azure-Portal. Wenn Sie den Server finden müssen, gehen Sie folgendermaßen vor:

    1. Wählen Sie Azure SQL im Dienstmenü aus. Wenn Azure SQL nicht in der Liste aufgeführt wird, wählen Sie Alle Dienste aus, und geben Sie dann Azure SQL in das Suchfeld ein. (Optional:) Wählen Sie den Stern neben Azure SQL aus, um es zu favorisieren und als Element im Dienstmenü hinzuzufügen.
    2. Suchen Sie auf der Azure SQL-Seite den Pool für elastische Datenbanken, den Sie einer Failovergruppe hinzufügen möchten, und wählen Sie ihn aus, um den SQL-Pool für elastische Datenbankenbereich zu öffnen.
    3. Wählen Sie im Bereich Übersicht des SQL-Pools für elastische Datenbanken unter Servername den Namen des Servers aus, um den Bereich SQL Server zu öffnen.

    Screenshot zur Auswahl des Servers für den Pool für elastische Datenbanken im Azure-Portal.

  2. Wählen Sie im SQL-Server-Ressourcenmenü unter Datenverwaltung die Option Failover-Gruppen und wählen Sie dann eine vorhandene Failover-Gruppe aus, um die Seite Failover-Gruppe zu öffnen.

    Der Screenshot zeigt Failovergruppen, aus denen Sie eine Failovergruppe für Ihren SQL Server auswählen können.

  3. Auf der Seite Failovergruppe:

    1. Überprüfen Sie, welcher Server der primäre und welcher der sekundäre ist.
    2. Wählen Sie in der Befehlsleiste Failover aus, um ein Failover für die Failovergruppe mit Ihrer Datenbank durchzuführen.
    3. Wählen Sie in der Meldung, dass die TDS-Sitzungen getrennt werden, Ja aus.

    Screenshot Auswahl von Failover auf der Seite Failovergruppen im Azure-Portal.

  4. Überprüfen Sie, welcher Server jetzt der primäre und welcher der sekundäre ist. Nach erfolgreichem Failover tauschen die beiden Server ihre Rollen, so dass der ehemalige Primärserver zum Sekundärserver wird.

  5. (Optional) Wählen Sie erneut Failover aus, um die Server auf ihre ursprünglichen Rollen zurückzusetzen.

Vorhandene Failovergruppe verändern

Sie können über das Azure-Portal, PowerShell und die Azure CLI Datenbanken zu einer bestehenden Failovergruppe hinzufügen oder aus ihr entfernen oder die Konfigurationseinstellungen der Failovergruppe bearbeiten.

Gehen Sie folgendermaßen vor, um Änderungen an einer vorhandenen Failovergruppe über das Azure-Portal vorzunehmen:

  1. Wenn Sie den logischen Server kennen, auf dem Ihre Datenbank gehostet wird, oder Pool für elastische Datenbanken, wechseln Sie direkt in die Azure-Portal. Wenn Sie den Server finden müssen, gehen Sie folgendermaßen vor:

    1. Wählen Sie Azure SQL im Dienstmenü aus. Wenn Azure SQL nicht in der Liste aufgeführt wird, wählen Sie Alle Dienste aus, und geben Sie dann Azure SQL in das Suchfeld ein. (Optional:) Wählen Sie den Stern neben Azure SQL aus, um es zu favorisieren und als Element im Dienstmenü hinzuzufügen.
    2. Suchen Sie auf der Azure SQL-Seite die Datenbank oder den Pool für elastische Datenbanken, den Sie ändern möchten, und wählen Sie ihn aus, um die SQL-Datenbank oder den Bereich SQL-Pool für elastische Datenbanken zu öffnen.
    3. Wählen Sie im Bereich Übersicht der SQL-Datenbank oder des SQL-Pools für elastische Datenbanken unter Servername den Namen des Servers aus, um den Bereich SQL Server zu öffnen.
  2. Wählen Sie im SQL-Server-Ressourcenmenü unter Datenverwaltung die Option Failover-Gruppen und wählen Sie dann eine vorhandene Failover-Gruppe aus, um die Seite Failover-Gruppe zu öffnen.

    Der Screenshot zeigt Failovergruppen, aus denen Sie eine Failovergruppe für Ihren SQL Server auswählen können.

  3. Verwenden Sie auf der Seite Failovergruppe die Befehlsleiste:

    1. Um eine Datenbank hinzuzufügen, wählen Sie Datenbanken hinzufügen, um den Bereich Datenbanken zur Failovergruppe hinzufügen zu öffnen, und erweitern Sie dann #Datenbanken, um die Liste der Datenbanken auf dem primären Server anzuzeigen. Markieren Sie das Kästchen neben der/den Datenbank(en), die Sie der Failovergruppe hinzufügen möchten, und verwenden Sie dann Auswählen, um Ihre Änderungen zu speichern und Ihre Datenbank(en) hinzuzufügen.
    2. Um eine Datenbank zu entfernen, wählen Sie Datenbanken entfernen, um den Bereich Datenbanken aus Failovergruppe entfernen zu öffnen, und erweitern Sie dann #Datenbanken, um die Datenbanken in der Failovergruppe aufzulisten. Markieren Sie das Kästchen neben der/den Datenbank(en), die Sie aus der Failovergruppe entfernen möchten, und verwenden Sie dann Auswählen, um Ihre Änderungen zu speichern und Ihre Datenbank(en) zu entfernen.
    3. Um die Failover-Richtlinie zu bearbeiten oder eine Toleranzperiode zu konfigurieren, wählen Sie Konfiguration bearbeiten, um den Bereich Konfigurationen bearbeiten Failovergruppen zu öffnen und Ihre Einstellungen zu ändern. Wählen Sie Auswählen, um Ihre Änderungen zu speichern.

    Screenshot der Seite der Failovergruppe im Azure-Portal, wobei die Befehlsleiste hervorgehoben ist.

Mithilfe einer privaten Verbindung können Sie einen logischen Server einer bestimmten privaten IP-Adresse innerhalb des virtuellen Netzwerks und Subnetzes zuordnen.

Gehen Sie folgendermaßen vor, um eine private Verbindung mit Ihrer Failovergruppe zu verwenden:

  1. Stellen Sie sicher, dass sich der primäre und der sekundäre Server in einem Regionspaar befinden.
  2. Erstellen Sie das virtuelle Netzwerk und das Subnetz in beiden Regionen, um private Endpunkte für den primären und den sekundären Server zu hosten, sodass sich die IP-Adressräume nicht überlappen. Der Adressbereich des primären virtuellen Netzwerks (10.0.0.0/16) und der des sekundären virtuellen Netzwerks (10.0.0.1/16) überschneiden sich beispielsweise. Weitere Informationen zu den Adressbereichen von virtuellen Netzwerken finden Sie im Blogartikel zum Entwerfen von virtuellen Azure-Netzwerken.
  3. Erstellen Sie einen privaten Endpunkt und eine private Azure-DNS-Zone für den primären Server.
  4. Erstellen Sie auch einen privaten Endpunkt für den sekundären Server. Verwenden Sie dafür jedoch die gleiche private DNS-Zone, die für den primären Server erstellt wurde.
  5. Nachdem die private Verbindung eingerichtet wurde, können Sie die Failovergruppe erstellen, indem Sie die zuvor in diesem Artikel beschriebenen Schritte ausführen.

Listenerendpunkt suchen

Aktualisieren Sie nach der Konfiguration der Failover-Gruppe die Verbindungszeichenfolge für Ihre Anwendung so, dass sie auf den Lese-/Schreib-Listener-Endpunkt verweist, damit ihre Anwendung weiterhin eine Verbindung mit der Datenbank herstellt, die nach dem Failover primär ist. Wenn Sie den Listener-Endpunkt verwenden, müssen Sie Ihre Verbindungszeichenfolge nicht jedes Mal, wenn Ihre Failover-Gruppe fehlschlägt, manuell aktualisieren, da der Datenverkehr immer an die aktuelle primäre Stelle weitergeleitet wird. Sie können auch auf den Schreibgeschützten Listener-Endpunkt verweisen.

Um den Listener-Endpunkt im Azure-Portal zu finden, wechseln Sie im Azure-Portal zu Ihrem logischen Server, und wählen Sie unter Datenverwaltung Failover-Gruppen aus. Wählen Sie die Failover-Gruppe aus, an der Sie interessiert sind.

Scrollen Sie nach unten, um die Listener-Endpunkte zu finden:

  • Der Lese-/Schreib-Listener-Endpunkt in Form von fog-name.database.windows.net leitet den Datenverkehr an die primäre Datenbank weiter.
  • Der Schreibgeschützte Listener-Endpunkt in Form von fog-name.secondary.database.windows.net leitet Datenverkehr an die sekundäre Datenbank weiter.

Screenshot, der die Verbindungszeichenfolge der Failovergruppe auf der Seite Failovergruppen im Azure-Portal zeigt.

Skalieren einer Datenbank in einer Failovergruppe

Sie können die primäre Datenbank auf eine andere Rechengröße vergrößern oder verkleinern (innerhalb derselben Dienstebene), ohne die Verbindung zu den sekundären Datenbanken zu unterbrechen. Bei der Skalierung wird empfohlen, zuerst die geo-sekundäre und dann die primäre Ebene zu vergrößern. Bei der Verkleinerung kehren Sie die Reihenfolge um: Verkleinern Sie zuerst die Primärseite und dann die Sekundärseite. Wenn Sie eine Datenbank auf eine andere Dienstebene skalieren, wird diese Empfehlung erzwungen.

Diese Reihenfolge ist besonders zur Vermeidung des Überladens der sekundären Datenbank auf einer niedrigeren SKU empfehlenswert, damit nicht während des Upgrade- oder Downgradevorgangs ein erneutes Seeding durchgeführt werden muss. Sie können dieses Problem auch vermeiden, indem Sie die primäre Datenbank mit Schreibschutz versehen. Das geht allerdings zu Lasten aller Lese-/Schreibworkloads für die primäre Datenbank.

Hinweis

Wenn Sie im Rahmen der Konfiguration der Failovergruppe eine sekundäre Geodatenbank erstellt haben, wird davon abgeraten, die sekundäre Geodatenbank herunterzuskalieren. Damit soll sichergestellt werden, dass Ihre Datenebene über genügend Kapazität verfügt, um die reguläre Arbeitslast nach einem Geo-Failover zu verarbeiten. Sie können ein geosekundäres Datenbankreplikat nach einem erzwungenen Failover möglicherweise nicht skalieren, wenn das vormalige geoprimäre Datenbankreplikat aufgrund eines Ausfalls nicht verfügbar ist. Dies ist eine bekannte Einschränkung.

Die primäre Datenbank in einer Failover-Gruppe kann nur dann auf eine höhere Serviceebene (Edition) skaliert werden, wenn die sekundäre Datenbank zuerst auf die höhere Ebene skaliert wird. Wenn Sie z. B. den primären Bereich von "General Purpose" auf "Business Critical" skalieren wollen, müssen Sie zuerst den geo-sekundären Bereich auf "Business Critical" skalieren. Wenn Sie versuchen, die Primär- oder Geo-Sekundärdaten in einer Weise zu skalieren, die gegen diese Regel verstößt, erhalten Sie die folgende Fehlermeldung:

The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

Verhinderung des Verlusts kritischer Daten

Aufgrund der hohen Latenzzeit von WANs verwendet die Georeplikation einen asynchronen Replikationsmechanismus. Bei der asynchronen Replikation ist die Möglichkeit eines Datenverlusts unvermeidbar, wenn die primäre Datenbank ausfällt. Zum Schutz kritischer Transaktionen vor Datenverlust, kann ein Anwendungsentwickler die gespeicherte Prozedur sp_wait_for_database_copy_sync unmittelbar nach dem Commit der Transaktion aufrufen. Der Aufruf von sp_wait_for_database_copy_sync blockiert den aufrufenden Thread, bis die letzte committete Transaktion übertragen und im Transaktionsprotokoll der sekundären Datenbank gehärtet wurde. Er wartet jedoch nicht darauf, dass die übertragenen Transaktionen in der sekundären Datenbank wiedergegeben (wiederholt) werden. sp_wait_for_database_copy_sync ist auf eine bestimmte Georeplikationslink beschränkt. Jeder Benutzer mit den Rechten zum Herstellen der Verbindung mit der primären Datenbank kann diese Prozedur aufrufen.

Hinweis

sp_wait_for_database_copy_sync verhindert Datenverluste nach einem Geofailover für bestimmte Transaktionen, garantiert aber keine vollständige Synchronisierung für Lesezugriffe. Die durch einen sp_wait_for_database_copy_sync-Prozeduraufruf verursachte Verzögerung kann beträchtlich sein und hängt von der Größe des noch nicht übertragenen Transaktionsprotokolls auf der Primärseite zum Zeitpunkt des Aufrufs ab.

Ändern der sekundären Region

Zur Verdeutlichung der Änderungssequenz treffen wir die Annahme, dass Server A der primäre Server, Server B der vorhandene sekundäre Server und Server C der neue sekundäre Server in der dritten Region ist. Führen Sie diese Schritte aus, um die Umstellung durchzuführen:

  1. Erstellen Sie für jede Datenbank zusätzliche sekundäre Replikate von Server A auf Server C, indem Sie die aktive Georeplikation verwenden. Jede Datenbank auf Server A verfügt über zwei sekundäre Replikate: eins auf Server B und eins auf Server C. So wird garantiert, dass die primären Datenbanken während der Umstellung geschützt bleiben.
  2. Löschen Sie die Failovergruppe. An diesem Punkt treten bei Anmeldeversuchen, die Failovergruppenendpunkte verwenden, Fehler auf.
  3. Erstellen Sie die Failovergruppe mit dem gleichen Namen zwischen den Servern A und C neu.
  4. Fügen Sie alle primären Datenbanken von Server A der neuen Failovergruppe hinzu. An diesem Punkt schlagen die Anmeldeversuche nicht mehr fehl.
  5. Löschen Sie Server B. Alle Datenbanken auf Server B werden automatisch gelöscht.

Ändern der primären Region

Zur Verdeutlichung der Änderungssequenz nehmen wir an, dass Server A der primäre Server, Server B der vorhandene sekundäre Server und Server C der neue primäre Server in der dritten Region ist. Führen Sie diese Schritte aus, um die Umstellung durchzuführen:

  1. Führen Sie ein geplantes Geofailover durch, um den primären Server auf B umzustellen. Server A wird zum neuen sekundären Server. Beim Failover kann es zu einem Ausfall mit einer Dauer von mehreren Minuten kommen. Die tatsächliche Dauer hängt von der Größe der Failovergruppe ab.
  2. Erstellen Sie für jede Datenbank zusätzliche sekundäre Replikate von Server B auf Server C, indem Sie die aktive Georeplikation verwenden. Jede Datenbank auf Server B verfügt über zwei sekundäre Replikate: eins auf Server A und eins auf Server C. So wird garantiert, dass die primären Datenbanken während der Umstellung geschützt bleiben.
  3. Löschen Sie die Failovergruppe. An diesem Punkt treten bei Anmeldeversuchen, die Failovergruppenendpunkte verwenden, Fehler auf.
  4. Erstellen Sie die Failovergruppe mit dem gleichen Namen zwischen den Servern B und C neu.
  5. Fügen Sie alle primären Datenbanken von Server B der neuen Failovergruppe hinzu. An diesem Punkt schlagen die Loginversuche nicht mehr fehl.
  6. Führen Sie für die Failovergruppe ein geplantes Geofailover durch, um B und C umzustellen. Server C wird zum primären und Server B zum sekundären Server. Alle sekundären Datenbanken auf Server A werden automatisch mit den primären Replikaten auf C verknüpft. Wie in Schritt 1 auch, kann es beim Failover zu einem Ausfall von mehreren Minuten kommen.
  7. Löschen Sie Server A. Alle Datenbanken auf A werden automatisch gelöscht.

Wichtig

Wenn die Failovergruppe gelöscht wird, werden auch die DNS-Einträge für die Listenerendpunkte gelöscht. An diesem Punkt ist nicht völlig ausgeschlossen, dass eine andere Person eine Failovergruppe oder einen Server-DNS-Alias mit dem gleichen Namen erstellt. Da Failovergruppennamen und DNS-Aliase global eindeutig sein müssen, wird verhindert, dass Sie denselben Namen noch mal verwenden. Verwenden Sie keine generischen Namen für Failovergruppen um dieses Risiko zu minimieren.

Failovergruppen und Netzwerksicherheit

Für einige Anwendungen erfordern die Sicherheitsregeln, dass der Netzwerkzugriff auf die Datenebene auf eine bestimmte Komponente oder Komponenten wie eine VM, einen Webdienst usw. beschränkt ist. Diese Anforderung stellt einige Herausforderungen für den Entwurf der Geschäftskontinuität und die Verwendung von Failovergruppen dar. Berücksichtigen Sie bei der Implementierung eines solchen eingeschränkten Zugriffs die folgenden Optionen.

Verwenden von Failovergruppen und VNET-Dienstendpunkten

Wenn Sie Virtual Network-Dienstendpunkte und -Regeln verwenden, um den Zugriff auf Ihre SQL-Datenbank-Instanz einzuschränken, denken Sie daran, dass jeder Virtual Network-Dienstendpunkt nur für eine einzige Azure-Region gilt. Der Endpunkt ermöglicht anderen Regionen nicht das Akzeptieren von Nachrichten aus dem Subnetz. Aus diesem Grund können nur die Clientanwendungen, die in der gleichen Region bereitgestellt werden, eine Verbindung mit der primären Datenbank herstellen. Da ein Geofailover dazu führt, dass die SQL-Datenbank-Clientsitzungen zu dem Server in der anderen (sekundären) Region umgeleitet werden, treten bei diesen Sitzungen Fehler auf, wenn sie von Clients ausgehen, die sich außerhalb dieser Region befinden. Aus diesem Grund kann die Richtlinie für automatisches Failover nicht aktiviert werden, wenn die beteiligten Server in den VNET-Regeln enthalten sind. Gehen Sie folgendermaßen vor, um die manuelle Failover-Richtlinie zu unterstützen:

  1. Stellen Sie die redundanten Kopien der Front-End-Komponenten der Anwendung (Webdienst, VMs usw.) in der sekundären Region bereit.
  2. Konfigurieren Sie die VNET-Regeln einzeln für den primären und sekundären Server.
  3. Aktivieren Sie das Front-End-Failover durch eine Traffic Manager-Konfiguration.
  4. Initiieren Sie ein manuelles Geofailover, wenn der Ausfall erkannt wird. Diese Option ist für die Anwendungen optimiert, die konsistente Latenz zwischen Front-End und Datenebene erfordern, und unterstützt die Wiederherstellung, wenn Front-End, Datenebene oder beide vom Ausfall betroffen sind.

Hinweis

Stellen Sie bei Verwendung des schreibgeschützten Listeners für den Lastenausgleich einer schreibgeschützten Workload sicher, dass diese Workload auf einem virtuellen Computer oder einer anderen Ressource in der sekundären Region ausgeführt wird, damit sie eine Verbindung mit der sekundären Datenbank herstellen kann.

Verwenden von Failovergruppen und Firewallregeln

Wenn Ihr Geschäftskontinuitätsplan das Durchführen eines Failovers mithilfe von Gruppen mit automatischem Failover erfordert, können Sie den Zugriff auf Ihre Datenbank in SQL-Datenbank mithilfe der öffentlichen IP-Firewallregeln einschränken. Die oben genannte Konfiguration sorgt dafür, dass ein automatisches Geofailover keine Verbindungen von den Front-End-Komponenten blockiert, und setzt voraus, dass die Anwendung die längeren Wartezeiten zwischen dem Front-End und der Datenebene tolerieren kann.

Gehen Sie folgendermaßen vor, um Failover-Gruppen-Failover zu unterstützen:

  1. Erstellen Sie eine öffentliche IP-Adresse.
  2. Erstellen Sie einen öffentlichen Lastenausgleich, und weisen Sie ihm die öffentliche IP-Adresse zu.
  3. Erstellen Sie ein virtuelles Netzwerk und die VMs für Ihre Front-End-Komponenten.
  4. Erstellen Sie eine Netzwerksicherheitsgruppe, und konfigurieren Sie eingehende Verbindungen.
  5. Stellen Sie mithilfe eines Sql.<Region>-Diensttags sicher, dass die ausgehenden Verbindungen für Azure SQL-Datenbank in einer Region geöffnet sind.
  6. Erstellen Sie eine SQL-Datenbank-Firewallregel, um eingehenden Datenverkehr von der öffentlichen IP-Adresse, die Sie in Schritt 1 erstellt haben, zuzulassen.

Weitere Informationen zur Konfiguration des ausgehenden Zugriffs und IP-Adresse, die in den Firewallregeln verwendet werden soll, finden Sie unter Ausgehende Verbindungen in Azure.

Wichtig

Damit die Geschäftskontinuität bei regionalen Ausfällen gewährleistet ist, müssen Sie die geografische Redundanz sowohl für die Front-End-Komponenten als auch die Datenbanken sicherstellen.

Berechtigungen

Berechtigungen für eine Failovergruppe werden über die rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC) verwaltet.

Zum Erstellen und Verwalten von Failovergruppen wird Azure RBAC-Schreibzugriff benötigt. Die Rolle Mitwirkender von SQL Server verfügt über alle erforderlichen Berechtigungen zum Verwalten von Failovergruppen.

In der folgenden Tabelle werden spezifische Berechtigungsbereiche für Azure SQL-Datenbank aufgeführt:

Aktion Berechtigung Umfang
Erstellen einer Failovergruppe Azure RBAC-Schreibzugriff Primärer Server
Sekundärer Server
Alle Datenbanken in einer Failovergruppe
Aktualisieren einer Failovergruppe Azure RBAC-Schreibzugriff Failovergruppe
Alle Datenbanken auf dem aktuellen primären Server
Failover einer Failovergruppe Azure RBAC-Schreibzugriff Failovergruppe auf dem neuen Server

Begrenzungen

Bedenken Sie dabei folgende Einschränkungen:

  • Failovergruppen können nicht zwischen zwei Servern in derselben Azure-Region erstellt werden.
  • Failovergruppen unterstützen die Georeplikation aller Datenbanken in der Gruppe auf nur einen sekundären logischen Server in einer anderen Region.
  • Failovergruppen können nicht umbenannt werden. Sie müssen die Gruppe löschen und unter einem anderen Namen neu erstellen.
  • Die Datenbankumbenennung wird für Datenbanken in der Failovergruppe nicht unterstützt. Sie müssen die Failovergruppe vorübergehend löschen, um eine Datenbank umbenennen oder die Datenbank aus der Failovergruppe entfernen zu können.
  • Wenn Sie eine Failovergruppe für eine einzelne oder eine Pooldatenbank entfernen, wird die Replikation nicht beendet und die replizierte Datenbank nicht gelöscht. Sie müssen die Georeplikation manuell beenden und die Datenbank vom sekundären Server löschen, wenn Sie eine einzelne Datenbank oder eine Pooldatenbank nach dem Löschen wieder einer Failovergruppe hinzufügen möchten. Wenn Sie keine der beiden Aktionen ausführen, kann ein Fehler ähnlich wie The operation cannot be performed due to multiple errors angezeigt werden, wenn Sie versuchen, der Failovergruppe die Datenbank hinzuzufügen.
  • Der Name der automatischen Failovergruppe unterliegt Benennungseinschränkungen.
  • Beim Erstellen einer neuen Failovergruppe oder beim Hinzufügen von Datenbanken zu einer bestehenden Failovergruppe können Sie die Datenbanken nur dann als Standby-Replikate bestimmen, wenn Sie das Azure-Portal verwenden – Azure PowerShell und Azure CLI sind derzeit nicht verfügbar.

Programmgesteuertes Verwalten von Failovergruppen

Gruppen für automatisches Failover können auch programmgesteuert mit Azure PowerShell, Azure CLI und der REST-API verwaltet werden. Die folgenden Tabellen beschreiben den verfügbaren Satz von Befehlen. Die aktive Georeplikation umfasst eine Reihe von Azure Resource Manager-APIs für die Verwaltung. Hierzu zählen unter anderem die Azure SQL-Datenbank-REST-API und Azure PowerShell-Cmdlets. Diese APIs erfordern die Verwendung von Ressourcengruppen und unterstützen die rollenbasierte Zugriffssteuerung (Azure RBAC) in Azure. Weitere Informationen zur Implementierung von Zugriffsrollen finden Sie unter Rollenbasierte Zugriffssteuerung in Azure (Azure RBAC).

Cmdlet BESCHREIBUNG
New-AzSqlDatabaseFailoverGroup Dieser Befehl erstellt eine Failovergruppe und registriert sie auf primären und sekundären Servern.
Add-AzSqlDatabaseToFailoverGroup Fügt einer Failovergruppe eine oder mehrere Datenbanken hinzu.
Remove-AzSqlDatabaseFromFailoverGroup Entfernt eine oder mehrere Datenbanken aus einer Failovergruppe
Remove-AzSqlDatabaseFailoverGroup Entfernt eine Failovergruppe vom Server.
Get-AzSqlDatabaseFailoverGroup Ruft die Konfiguration einer Failovergruppe ab.
Set-AzSqlDatabaseFailoverGroup Ändert die Konfiguration einer Failovergruppe.
Switch-AzSqlDatabaseFailoverGroup Löst das Failover einer Failovergruppe auf den sekundären Server aus.

Hinweis

Es ist möglich, Ihre Failovergruppe subscriptionübergreifend bereitzustellen, indem Sie den -PartnerSubscriptionId-Parameter in Azure PowerShell ab Az.SQL 3.11.0 verwenden. Weitere Informationen finden Sie im folgenden Beispiel.