Konfigurieren einer Failovergruppe für Azure SQL-Datenbank

Artikel
09/27/2024

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:

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.
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.
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.
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).
Verwenden Sie Erstellen auf der Seite Failover-Gruppe, um Ihre Failovergruppe zu erstellen.

Erstellen Sie Ihre Failovergruppe mit dem PowerShell-Befehl New-AzSqlDatabaseFailoverGroup:


# Create a failover group between the servers
$failovergroup = Write-host "Creating a failover group between the primary and secondary server..."
New-AzSqlDatabaseFailoverGroup `
   –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
$failovergroup

Verwenden Sie die Befehle Get-AzSqlDatabase und Add-AzSqlDatabaseToFailoverGroup, um die Datenbank der Failovergruppe hinzuzufügen:


# Add the database to the failover group
Write-host "Adding the database to the failover group..." 
Get-AzSqlDatabase `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -DatabaseName $databaseName | `
Add-AzSqlDatabaseToFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Successfully added the database to the failover group..."

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.

Erstellen Sie Ihre Failovergruppe, und fügen Sie ihr Datenbanken mit dem Azure CLI-Befehl az sql failover-group create hinzu:

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2 --add-db $database

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:

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.
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.
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.
Ü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.
(Optional) Wählen Sie erneut Failover aus, um die Server auf ihre ursprünglichen Rollen zurückzusetzen.

Testen Sie das Failover Ihrer Failovergruppe mithilfe von PowerShell.

Überprüfen der Rollen der einzelnen Server

Verwenden Sie den Befehl az sql failover-group show, um die Rollen der einzelnen Server zu bestätigen.


# Check role of secondary replica
Write-host "Confirming the secondary replica is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Failover auf den sekundären Server

Verwenden Sie die Switch-AzSqlDatabaseFailoverGroup, um einen Failover auf den sekundären Server zu ausführen.


# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully to" $drServerName 

Write-host "Confirming the secondary server is now primary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Wiederherstellen der Failovergruppe auf dem primären Server

Verwenden Sie den Befehl Switch-AzSqlDatabaseFailoverGroup, um auf den primären Server zurückzukehren.


# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully back to" $serverName

Testen Sie ein Failover mithilfe der Azure CLI.

Überprüfen der Rollen der einzelnen Server

Verwenden Sie den Befehl az sql failover-group show, um die Rollen der einzelnen Server zu bestätigen.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Failover auf den sekundären Server

Verwenden Sie den Befehl az sql failover-group set-primary, um ein Failover auf den sekundären Server auszuführen. Verwenden Sie den Befehl az sql failover-group show, um ein erfolgreiches Failover zu überprüfen.

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Wiederherstellen der Failovergruppe auf dem primären Server

Verwenden Sie den Befehl az sql failover-group set-primary, um ein Failback auf den primären Server auszuführen.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

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:

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

Erstellen Sie Ihre Failovergruppe, und fügen Sie ihr Ihren Pool für elastische Datenbanken mithilfe von PowerShell hinzu.

Verwenden Sie die New-AzSqlDatabaseFailoverGroup, um die Failovergruppe zu erstellen:


# Create a failover group between the servers
Write-host "Creating failover group..." 
New-AzSqlDatabaseFailoverGroup `
  –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
Write-host "Failover group created successfully."

Verwenden Sie die Befehle Get-AzSqlDatabaseFailoverGroup und Get-AzSqlElasticPoolDatabase, um die Datenbank der Failovergruppe hinzuzufügen:


# Add elastic pool to the failover group
Write-host "Enumerating databases in elastic pool...." 
$FailoverGroup = Get-AzSqlDatabaseFailoverGroup `
                 -ResourceGroupName $resourceGroupName `
                 -ServerName $serverName `
                 -FailoverGroupName $failoverGroupName
$databases = Get-AzSqlElasticPoolDatabase `
               -ResourceGroupName $resourceGroupName `
               -ServerName $serverName `
               -ElasticPoolName $poolName
Write-host "Adding databases to failover group..." 
$failoverGroup = $failoverGroup | Add-AzSqlDatabaseToFailoverGroup `
                                  -Database $databases 
$failoverGroup

In diesem Schritt erstellen Sie Ihre Failovergruppe und fügen Ihre Datenbank mithilfe der Azure CLI hinzu.

Verwenden Sie den Befehl az sql failover-group create, um eine Failovergruppe zu erstellen.

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2
databaseId=$(az sql elastic-pool list-dbs --name $pool --resource-group $resourceGroup --server $server --query [0].name -o json | tr -d '"')

Verwenden Sie den Befehl az sql failover-group update, um der Failovergruppe eine Datenbank hinzuzufügen.

echo "Adding $database to $failoverGroup..."
az sql failover-group update --name $failoverGroup --add-db $databaseId --resource-group $resourceGroup --server $server

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.

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.
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.
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.
Ü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.
(Optional) Wählen Sie erneut Failover aus, um die Server auf ihre ursprünglichen Rollen zurückzusetzen.

Testen Sie das Failover Ihrer Failovergruppe mithilfe von PowerShell mithilfe der folgenden PowerShell-Befehle:

Überprüfen der Rollen der einzelnen Server

Verwenden Sie den Befehl az sql failover-group show, um die Rollen der einzelnen Server zu bestätigen.


# Check role of secondary replica
Write-host "Confirming the secondary server is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Failover auf den sekundären Server

Verwenden Sie die Switch-AzSqlDatabaseFailoverGroup, um einen Failover auf den sekundären Server zu ausführen.

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failover group failed over to" $drServerName 

# Check role of secondary replica
Write-host "Confirming the secondary server is now primary" 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Überprüfen der Rollen der einzelnen Server

Verwenden Sie den Befehl az sql failover-group show, um die Rollen der einzelnen Server zu bestätigen.


# Check role of secondary replica
Write-host "Confirming the secondary server is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Wiederherstellen der Failovergruppe auf dem primären Server

Verwenden Sie den Befehl Switch-AzSqlDatabaseFailoverGroup, um auf den primären Server zurückzukehren.


# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failover group failed over to" $serverName

Testen Sie ein Failover mithilfe der Azure CLI.

Überprüfen der Rollen der einzelnen Server

Verwenden Sie den Befehl az sql failover-group show, um die Rollen der einzelnen Server in der Failovergruppe zu bestätigen.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Failover auf den sekundären Server

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Überprüfen der Rollen der einzelnen Server

Verwenden Sie den Befehl az sql failover-group show, um die Rollen der einzelnen Server in der Failovergruppe zu bestätigen.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Wiederherstellen der Failovergruppe auf dem primären Server

Verwenden Sie den Befehl az sql failover-group set-primary, um ein Failback auf den primären Server auszuführen.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

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:

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

Verwenden von Private Link

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:

Stellen Sie sicher, dass sich der primäre und der sekundäre Server in einem Regionspaar befinden.
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.
Erstellen Sie einen privaten Endpunkt und eine private Azure-DNS-Zone für den primären Server.
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.
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.

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:

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.
Löschen Sie die Failovergruppe. An diesem Punkt treten bei Anmeldeversuchen, die Failovergruppenendpunkte verwenden, Fehler auf.
Erstellen Sie die Failovergruppe mit dem gleichen Namen zwischen den Servern A und C neu.
Fügen Sie alle primären Datenbanken von Server A der neuen Failovergruppe hinzu. An diesem Punkt schlagen die Anmeldeversuche nicht mehr fehl.
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:

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.
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.
Löschen Sie die Failovergruppe. An diesem Punkt treten bei Anmeldeversuchen, die Failovergruppenendpunkte verwenden, Fehler auf.
Erstellen Sie die Failovergruppe mit dem gleichen Namen zwischen den Servern B und C neu.
Fügen Sie alle primären Datenbanken von Server B der neuen Failovergruppe hinzu. An diesem Punkt schlagen die Loginversuche nicht mehr fehl.
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.
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:

Stellen Sie die redundanten Kopien der Front-End-Komponenten der Anwendung (Webdienst, VMs usw.) in der sekundären Region bereit.
Konfigurieren Sie die VNET-Regeln einzeln für den primären und sekundären Server.
Aktivieren Sie das Front-End-Failover durch eine Traffic Manager-Konfiguration.
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:

Erstellen Sie eine öffentliche IP-Adresse.
Erstellen Sie einen öffentlichen Lastenausgleich, und weisen Sie ihm die öffentliche IP-Adresse zu.
Erstellen Sie ein virtuelles Netzwerk und die VMs für Ihre Front-End-Komponenten.
Erstellen Sie eine Netzwerksicherheitsgruppe, und konfigurieren Sie eingehende Verbindungen.
Stellen Sie mithilfe eines Sql.<Region>-Diensttags sicher, dass die ausgehenden Verbindungen für Azure SQL-Datenbank in einer Region geöffnet sind.
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

Befehl	BESCHREIBUNG
az sql failover-group create	Erstellt eine Failovergruppe und registriert sie auf primären und sekundären Servern
az sql failover-group update	Fügt Datenbanken hinzu oder entfernt sie oder ändert die Konfigurationseinstellungen für die Failovergruppe
az sql failover-group delete	Entfernt eine Failovergruppe vom Server.
az sql failover-group show	Ruft die Konfiguration einer Failovergruppe ab.
az sql failover-group set-primary	Löst das Failover einer Failovergruppe auf den sekundären Server aus

API	BESCHREIBUNG
Create or Update Failover Group	Erstellt oder aktualisiert eine Failovergruppe und fügt Datenbanken hinzu oder entfernt sie
Delete Failover Group	Entfernt eine Failovergruppe vom Server.
Failover (Planned)	Löst das Failover vom aktuellen primären Server auf den sekundären Server mit vollständiger Datensynchronisierung aus.
Force Failover Allow Data Loss	Löst das Failover vom aktuellen primären Server auf den sekundären Server ohne Datensynchronisierung aus. Bei diesem Vorgang können Daten verloren gehen.
Get Failover Group	Ruft die Konfiguration einer Failovergruppe ab.
List Failover Groups By Server	Listet die Failovergruppen eines Servers auf.
Update Failover Group	Aktualisiert die Konfiguration einer Failovergruppe.

Teilen über

Konfigurieren einer Failovergruppe für Azure SQL-Datenbank

Voraussetzungen

Erstellen einer Failovergruppe

Testen des geplanten Failovers

Überprüfen der Rollen der einzelnen Server

Failover auf den sekundären Server

Wiederherstellen der Failovergruppe auf dem primären Server

Überprüfen der Rollen der einzelnen Server

Failover auf den sekundären Server

Wiederherstellen der Failovergruppe auf dem primären Server

Voraussetzungen

Erstellen einer Failovergruppe

Testen des geplanten Failovers

Überprüfen der Rollen der einzelnen Server

Failover auf den sekundären Server

Überprüfen der Rollen der einzelnen Server

Wiederherstellen der Failovergruppe auf dem primären Server

Überprüfen der Rollen der einzelnen Server

Failover auf den sekundären Server

Überprüfen der Rollen der einzelnen Server

Wiederherstellen der Failovergruppe auf dem primären Server

Vorhandene Failovergruppe verändern

Verwenden von Private Link

Listenerendpunkt suchen

Skalieren einer Datenbank in einer Failovergruppe

Verhinderung des Verlusts kritischer Daten

Ändern der sekundären Region

Ändern der primären Region

Failovergruppen und Netzwerksicherheit

Verwenden von Failovergruppen und VNET-Dienstendpunkten

Verwenden von Failovergruppen und Firewallregeln

Berechtigungen

Begrenzungen

Programmgesteuertes Verwalten von Failovergruppen

Feedback

Zusätzliche Ressourcen

Teilen über

Konfigurieren einer Failovergruppe für Azure SQL-Datenbank

Voraussetzungen

Erstellen einer Failovergruppe

Testen des geplanten Failovers

Voraussetzungen

Erstellen einer Failovergruppe

Testen des geplanten Failovers

Vorhandene Failovergruppe verändern

Verwenden von Private Link

Listenerendpunkt suchen

Skalieren einer Datenbank in einer Failovergruppe

Verhinderung des Verlusts kritischer Daten

Ändern der sekundären Region

Ändern der primären Region

Failovergruppen und Netzwerksicherheit

Verwenden von Failovergruppen und VNET-Dienstendpunkten

Verwenden von Failovergruppen und Firewallregeln

Berechtigungen

Begrenzungen

Programmgesteuertes Verwalten von Failovergruppen

Zugehöriger Inhalt

Feedback

Zusätzliche Ressourcen