Configurare un gruppo di failover per il database SQL di Azure

Articolo
05/22/2024

Questo articolo mostra come configurare un gruppo di failover per database singoli e in pool nel database SQL di Azure usando il portale di Azure, Azure PowerShell e l'interfaccia della riga di comando di Azure.

Per gli script end-to-end, vedere come aggiungere un singolo database a un gruppo di failover con Azure PowerShell o con l'interfaccia della riga di comando di Azure.

Prerequisiti

Prendere in considerazione i prerequisiti seguenti per creare il gruppo di failover per un database singolo:

Il database primario deve essere già stato creato. Creare un database singolo per iniziare.
Se il server secondario è già presente in un'area diversa rispetto al server primario, le impostazioni del firewall e dell'account di accesso del server devono corrispondere a quelle del server primario.

Create failover group

È possibile creare il gruppo di failover e aggiungerci un singolo database usando il portale di Azure, PowerShell e l'interfaccia della riga di comando di Azure.

Importante

Se è necessario eliminare un database secondario dopo che è stato aggiunto a un gruppo di failover, rimuoverlo dal gruppo di failover prima di eliminare il database. L'eliminazione di un database secondario prima della rimozione dal gruppo di failover può causare comportamenti imprevisti.

Per creare il gruppo di failover e aggiungere il singolo database utilizzando il portale Azure, seguire i seguenti passaggi:

Se si conosce il server logico che ospita il database, passare direttamente al server nel portale di Azure. Se occorre trovare il server, seguire questa procedura:
1. Selezionare Azure SQL nel menu di servizio. Se Azure SQL non è presente nell'elenco, selezionare Tutti i servizi e digitare Azure SQL nella casella di ricerca. (Facoltativo) Selezionare la stella accanto ad Azure SQL per aggiungerlo ai Preferiti e come elemento nel menu di servizio.
2. Nella pagina SQL di Azure individuare il database da aggiungere al gruppo di failover e selezionarlo per aprire il riquadro del database SQL.
3. Nel riquadro Panoramica del database SQL, selezionare il nome del server in Nome del server per aprire il riquadro SQL Server.
Nel menu delle risorse del SQL Server selezionare Gruppi di failover in Gestione dei dati. Selezionare + Aggiungi gruppo per aprire la pagina Gruppi di failover in cui è possibile creare un nuovo gruppo di failover.
Nella pagina Gruppi di failover:
1. Specificare un nome del gruppo di failover.
2. Scegliere un server secondario esistente oppure creare un nuovo server selezionando Crea nuovo in Server. Il server secondario nel gruppo di failover deve trovarsi in un'area diversa rispetto al server primario.
3. Selezionare Configura database per aprire la pagina Database per il gruppo di failover.
Nella pagina Database per il gruppo di failover:
1. Scegliere i database che si desidera aggiungere al gruppo di failover (n. 1 nello screenshot).
2. (Facoltativo) Scegliere Sì se si intende designare questi database come repliche di standby da usare solo per il ripristino di emergenza (n. 2 nello screenshot). Selezionare la casella per confermare che si userà la replica di standby.
3. Usare Seleziona per salvare la selezione del database e tornare alla pagina Gruppi di failover (non visibile nello screenshot).
Utilizzare Crea nella pagina Gruppi di failover per creare il gruppo di failover.

Creare il gruppo di failover con il comando PowerShell 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

Usare i comandi Get-AzSqlDatabase e Add-AzSqlDatabaseToFailoverGroup per aggiungere il database al gruppo di failover:


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

Nota

È possibile distribuire il gruppo di failover tra sottoscrizioni usando il parametro -PartnerSubscriptionId in Azure PowerShell a partire da Az.SQL 3.11.0. Per saperne di più, vedere il seguente ‭Esempio‭‬.

Creare il gruppo di failover e aggiungerci dei database con il comando az sql failover-group create dell'interfaccia della riga di comando di Azure:

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

Testare un failover pianificato

Testare un failover del gruppo di failover senza perdita di dati usando il portale di Azure o PowerShell.

Per verificare il failover del gruppo failover tramite il portale Azure, procedere come segue:

Se si conosce il server logico che ospita il database, passare direttamente al server nel portale di Azure. Se occorre trovare il server, seguire questa procedura:
1. Selezionare Azure SQL nel menu di servizio. Se Azure SQL non è presente nell'elenco, selezionare Tutti i servizi e digitare Azure SQL nella casella di ricerca. (Facoltativo) Selezionare la stella accanto ad Azure SQL per aggiungerlo ai Preferiti e come elemento nel menu di servizio.
2. Nella pagina Azure SQL individuare il database per testare il failover e selezionarlo per aprire il riquadro del database SQL.
3. Nel riquadro Panoramica del database SQL, selezionare il nome del server in Nome del server per aprire il riquadro SQL Server.
Nel menu delle risorse di SQL Server selezionare Gruppi di failover in Gestione dei dati e quindi scegliere un gruppo di failover esistente per aprire la pagina Gruppo di failover.
Nella pagina Gruppi di failover:
1. Verificare qual è il server primario e quale quello secondario.
2. Selezionare Failover nella barra dei comandi per eseguire il failover del gruppo di failover che contiene il database.
3. Selezionare Sì nella finestra dell'avviso che informa che le sessioni TDS verranno disconnesse.
Verificare quale server è ora il server primario e quale quello secondario. Al termine del failover, i due server scambiano i ruoli, in modo che il precedente database primario diventi secondario.
(Facoltativo) Selezionare di nuovo Failover per ripristinare i ruoli originali dei server.

Testare il failover del gruppo di failover con PowerShell.

Verificare i ruoli di ogni server

Usare il comando Get-AzSqlDatabaseFailoverGroup per confermare i ruoli di ogni server.


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

Effettuare il failover nel server secondario

Usare il comando Switch-AzSqlDatabaseFailoverGroup per eseguire il failover nel server secondario.


# 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

Ripristinare il gruppo di failover nel server primario

Usare il comando Switch-AzSqlDatabaseFailoverGroup per eseguire il failback nel server primario.


# 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

Testare il failover con l'interfaccia della riga di comando di Azure.

Verificare i ruoli di ogni server

Usare il comando az sql failover-group show per confermare i ruoli di ogni server.

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

Effettuare il failover nel server secondario

Usare il comando az sql failover-group set-primary per effettuare il failover nel server secondario. Usare il comandoaz sql failover-group show per verificare un failover riuscito.

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

Ripristinare il gruppo di failover nel server primario

Usare il comando az sql failover-group set-primary per eseguire nuovamente il failover nel server primario.

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

Per gli script end-to-end, vedere come aggiungere un pool elastico a un gruppo di failover con Azure PowerShell o l'interfaccia della riga di comando di Azure.

Prerequisiti

Prendere in considerazione i seguenti prerequisiti per la creazione del gruppo di failover per un database in pool:

Il pool elastico primario dovrebbe già essere disponibile. Creare un pool elastico per cominciare.
Se il server secondario esiste già, il login del server e le impostazioni del firewall devono corrispondere a quelle del server primario.

Create failover group

Creare il gruppo di failover per il pool elastico usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.

Importante

Per creare il gruppo failover e aggiungerci il pool elastico utilizzando il portale Azure, procedere come segue:

Andare alla pagina Crea pool elastico SQL nel portale Azure. Creare un pool elastico che:
- Ha lo stesso nome del pool elastico nel server primario.
- Usa il server secondario selezionato per il gruppo di failover. Il server secondario deve trovarsi in un'area diversa dal server primario e le impostazioni di accesso e di firewall del server devono corrispondere a quelle del server primario. Creare un nuovo server se il server secondario non è già stato creato.
Se si conosce il server logico che ospita il pool elastico primario, passare direttamente al server nel portale di Azure. Se occorre trovare il server, seguire questa procedura:
1. Selezionare Azure SQL nel menu di servizio. Se Azure SQL non è presente nell'elenco, selezionare Tutti i servizi e digitare Azure SQL nella casella di ricerca. (Facoltativo) Selezionare la stella accanto ad Azure SQL per aggiungerlo ai Preferiti e come elemento nel menu di servizio.
2. Nella pagina Azure SQL, individuare il pool elastico da aggiungere al gruppo di failover e selezionarlo per aprire il riquadro Pool elastico SQL.
3. Nel riquadro Panoramica del Pool elastico SQL, selezionare il nome del server in Nome del server per aprire il riquadro SQL Server.
Nel menu delle risorse del SQL Server selezionare Gruppi di failover in Gestione dei dati. Selezionare + Aggiungi gruppo per aprire la pagina Gruppi di failover in cui è possibile creare un nuovo gruppo di failover.
Nella pagina Gruppi di failover:
1. Specificare un nome del gruppo di failover.
2. Scegliere un server secondario esistente. Il server secondario del gruppo di failover deve trovarsi in una regione diversa da quella del server primario e deve includere un pool elastico con lo stesso nome del server primario.
3. Selezionare Configura database per aprire la pagina Database per il gruppo di failover.
Nella pagina Database per il gruppo di failover scegliere i database in pool da aggiungere al gruppo di failover. Usare Seleziona per salvare la selezione del database e tornare alla pagina Gruppi di failover.
Selezionare Crea nella pagina Gruppi di failover per creare il gruppo di failover. Aggiungendo il pool elastico al gruppo di failover si avvia automaticamente il processo di replica geografica.

Creare il gruppo di failover e aggiungervi il pool elastico usando PowerShell.

Usare il comando New-AzSqlDatabaseFailoverGroup per creare il gruppo di failover:


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

Usare i comandi Get-AzSqlDatabaseFailoverGroup e Get-AzSqlElasticPoolDatabase per aggiungere il database al gruppo di failover:


# 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 questo passaggio, creare il gruppo di failover e aggiungerci il database tramite l'interfaccia della riga di comando di Azure.

Usare il comando az sql failover-group create per creare un gruppo di failover.

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 '"')

Usare il comando az sql failover-group update per aggiungere un database al gruppo di failover.

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

Testare un failover pianificato

Testare un failover senza perdita di dati del pool elastico usando il portale di Azure, PowerShell o l'interfaccia della riga di comando.

Eseguire il failover del gruppo di failover sul server secondario e quindi eseguire il failback utilizzando il portale di Azure.

Se si conosce il server logico che ospita il pool elastico primario, passare direttamente al server nel portale di Azure. Se occorre trovare il server, seguire questa procedura:
1. Selezionare Azure SQL nel menu di servizio. Se Azure SQL non è presente nell'elenco, selezionare Tutti i servizi e digitare Azure SQL nella casella di ricerca. (Facoltativo) Selezionare la stella accanto ad Azure SQL per aggiungerlo ai Preferiti e come elemento nel menu di servizio.
2. Nella pagina Azure SQL, individuare il pool elastico da aggiungere al gruppo di failover e selezionarlo per aprire il riquadro Pool elastico SQL.
3. Nel riquadro Panoramica del Pool elastico SQL, selezionare il nome del server in Nome del server per aprire il riquadro SQL Server.
Nel menu delle risorse di SQL Server selezionare Gruppi di failover in Gestione dei dati e quindi scegliere un gruppo di failover esistente per aprire la pagina Gruppo di failover.
Nella pagina Gruppi di failover:
1. Verificare qual è il server primario e quale quello secondario.
2. Selezionare Failover nella barra dei comandi per eseguire il failover del gruppo di failover che contiene il database.
3. Selezionare Sì nella finestra dell'avviso che informa che le sessioni TDS verranno disconnesse.
Verificare quale server è ora il server primario e quale quello secondario. Al termine del failover, i due server scambiano i ruoli, in modo che il precedente database primario diventi secondario.
(Facoltativo) Selezionare di nuovo Failover per ripristinare i ruoli originali dei server.

Testare il failover del gruppo di failover usando PowerShell usando i seguenti comandi di PowerShell:

Verificare i ruoli di ogni server

Usare il comando Get-AzSqlDatabaseFailoverGroup per confermare i ruoli di ogni server.


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

Effettuare il failover nel server secondario

Usare il comando Switch-AzSqlDatabaseFailoverGroup per eseguire il failover nel server secondario.

# 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

Ripristinare il gruppo di failover nel server primario

Usare il comando Switch-AzSqlDatabaseFailoverGroup per eseguire il failback nel server primario.


# 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

Testare il failover con l'interfaccia della riga di comando di Azure.

Verificare i ruoli di ogni server

Usare il comando az sql failover-group show per confermare i ruoli di ogni server nel gruppo di failover.

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

Effettuare il failover nel server secondario

Usare il comando az sql failover-group set-primary per eseguire il failover nel server secondario. Usare il comandoaz sql failover-group show per verificare un failover riuscito.

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

Ripristinare il gruppo di failover nel server primario

Usare il comando az sql failover-group set-primary per eseguire nuovamente il failover nel server primario.

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

Modificare gruppo di failover esistente

Si possono aggiungere o rimuovere database da un gruppo di failover esistente o modificare le impostazioni di configurazione del gruppo tramite il portale di Azure, PowerShell e l'interfaccia della riga di comando di Azure.

Per modificare un gruppo di failover esistente tramite il portale di Azure, seguire questi passaggi:

Se si conosce il server logico che ospita il database o il pool elastico, passare direttamente al server nel portale di Azure. Se occorre trovare il server, seguire questa procedura:
1. Selezionare Azure SQL nel menu di servizio. Se Azure SQL non è presente nell'elenco, selezionare Tutti i servizi e digitare Azure SQL nella casella di ricerca. (Facoltativo) Selezionare la stella accanto ad Azure SQL per aggiungerlo ai Preferiti e come elemento nel menu di servizio.
2. Nella pagina Azure SQL individuare il database o il pool elastico da modificare e selezionarlo per aprire il riquadro Database SQL o Pool elastico SQL.
3. Nel riquadro Panoramica, per il database SQL o il pool elastico SQL selezionare il nome del server in Nome server per aprire il riquadro SQL Server.
Nel menu delle risorse di SQL Server selezionare Gruppi di failover in Gestione dei dati e quindi scegliere un gruppo di failover esistente per aprire la pagina Gruppo di failover.
Nella pagina dei gruppi di failover, utilizzare la barra dei comandi:
1. Per aggiungere un database, selezionare Aggiungi database per aprire il riquadro Aggiungi database al gruppo di failover e quindi espandere #Database per visualizzare l'elenco dei database nel server primario. Selezionare la casella accanto ai database da aggiungere al gruppo di failover e quindi usare Seleziona per salvare le modifiche e aggiungere i database.
2. Per rimuovere un database, selezionare Rimuovi database per aprire il riquadro Rimuovi database dal gruppo di failover e quindi espandere #Database per elencare i database nel gruppo di failover. Selezionare la casella accanto ai database da rimuovere dal gruppo di failover e quindi usare Seleziona per salvare le modifiche e rimuovere i database.
3. Per modificare i criteri di failover o configurare un periodo di tolleranza, selezionare Modifica configurazione per aprire il riquadro Modifica configurazioni dei gruppi di failover e modificare le impostazioni. Premere Seleziona per salvare le modifiche.

Usare Collegamento privato

L'uso di un collegamento privato consente di associare un server logico a un indirizzo IP privato specifico all'interno della rete virtuale e della subnet.

Per usare un collegamento privato con il gruppo di failover, attenersi alla procedura seguente:

Assicurarsi che i server primario e secondario si trovino in un'area associata.
Creare la rete virtuale e la subnet in ogni area per ospitare gli endpoint privati per i server primari e secondari, in modo che gli spazi degli indirizzi IP non siano sovrapposti. Ad esempio, l'intervallo di indirizzi della rete virtuale primaria di 10.0.0.0/16 e l'intervallo di indirizzi della rete virtuale secondario di 10.0.0.1/16 si sovrappongono. Per altre informazioni sugli intervalli di indirizzi di rete virtuale, vedere il blog sulla progettazione di reti virtuali di Azure.
Creare un endpoint privato e una zona di DNS privato di Azure per il server primario.
Creare un endpoint privato anche per il server secondario, ma questa volta scegliere di riutilizzare la stessa zona di DNS privato creata per il server primario.
Dopo aver stabilito il collegamento privato, è possibile creare il gruppo di failover seguendo i passaggi descritti in precedenza in questo articolo.

Individuare l'endpoint del listener

Dopo aver configurato il gruppo di failover, aggiornare la stringa di connessione per l'applicazione all'endpoint del listener. In questo modo l'applicazione viene connessa al listener del gruppo di failover, anziché al database primario o al pool elastico. In questo modo, non è necessario aggiornare manualmente la stringa di connessione ogni volta che l'entità del database esegue il failover, e il traffico viene instradato a qualsiasi entità attualmente primaria.

L'endpoint del listener è sotto forma di fog-name.database.windows.net ed è visibile nella portale di Azure quando si visualizza il gruppo di failover:

Dimensionare un database in un gruppo di failover

È possibile aumentare o ridurre un database primario a una dimensione di calcolo diversa (nello stesso livello di servizio) senza disconnettere i database secondari con replica geografica. Quando si aumentano le prestazioni, è consigliabile aumentare prima quelle del database secondario geografico e quindi quelle del database primario. In caso di riduzione delle prestazioni, invertire l’ordine: prima ridurre le prestazioni del database primario e poi le prestazioni di quello secondario. Quando si aumenta/riduce un database passando a un livello di servizio diverso, viene imposta questa raccomandazione.

Questa sequenza è consigliata specificamente per evitare il problema in cui il geo-secondario con uno SKU inferiore viene sovraccaricato e deve essere eseguito un nuovo processo di seeding durante la procedura di aggiornamento o downgrade. È possibile evitare il problema anche rendendo la replica primaria di sola lettura, a scapito di tutti i carichi di lavoro di lettura/scrittura sul componente primario.

Nota

Se è stato creato un database secondario con replica geografica come parte della configurazione di un gruppo di failover, non è consigliabile ridurne le prestazioni. Ciò garantisce che il livello dati disponga della capacità sufficiente per elaborare il carico di lavoro normale dopo un failover geografico. Potrebbe non essere possibile dimensionare un database geografico secondario dopo un failover imprevisto quando il database geografico primario precedente non è disponibile a causa di un'interruzione. Si tratta di una limitazione nota.

Evitare la perdita di dati critici

A causa della latenza elevata delle reti Wide Area Network, per la replica geografica viene usato un meccanismo di replica asincrona. La replica asincrona può comportare la perdita di dati nel caso in cui il database primario abbia esito negativo. Per proteggere questi aggiornamenti critici dalla perdita di dati, uno sviluppatore di applicazioni può richiamare la stored procedure sp_wait_for_database_copy_sync subito dopo il commit della transazione. La chiamata sp_wait_for_database_copy_sync blocca il thread chiamante fino a quando l'ultima transazione sottoposta a commit non viene trasmessa e sottoposta a protezione avanzata nel log delle transazioni del database secondario. Tuttavia, non attende che le transazioni trasmesse vengano riprodotta (eseguite nuovamente) nel database secondario. sp_wait_for_database_copy_sync è limitato a un collegamento di replica geografica specifico. La procedura può essere chiamata da qualsiasi utente che abbia diritti di connessione al database primario.

Nota

sp_wait_for_database_copy_sync impedisce la perdita di dati dopo il failover geografico per transazioni specifiche, ma non garantisce la sincronizzazione completa per l'accesso in lettura. Il ritardo causato da una chiamata di procedura sp_wait_for_database_copy_sync può essere significativo e dipende dalle dimensioni del log delle transazioni non ancora trasmesso al database primario al momento della chiamata.

Modificare l'area secondaria

Per illustrare la sequenza di modifiche, si presuppone che il server A sia il server primario, il server B sia il server secondario esistente e il server C sia il nuovo secondario nella terza area. Per eseguire la transizione, seguire questi passaggi:

Creare repliche secondarie aggiuntive di ogni database nel server A al server C usando la replica geografica attiva. Ogni database nel server A avrà due database secondari, uno nel server B e uno nel server C. Ciò garantisce che i database primari rimangano protetti durante la transizione.
Eliminare il gruppo di failover. A questo punto, i tentativi di accesso che usano gli endpoint del gruppo di failover iniziano a fallire.
Ricreare il gruppo di failover con lo stesso nome tra i server A e C.
Aggiungere tutti i database primari nel server A al nuovo gruppo di failover. A questo punto, i tentativi di accesso smettono di fallire.
Eliminare il server B. Tutti i database in B verranno eliminati automaticamente.

Modificare l'area primaria

Per illustrare la sequenza di modifiche, si presuppone che il server A sia il server primario, il server B sia il server secondario esistente e il server C sia il nuovo server primario nella terza area. Per eseguire la transizione, seguire questi passaggi:

Eseguire un failover geografico pianificato per passare il server primario a B. Il server A diventa il nuovo server secondario. Il failover potrebbe comportare diversi minuti di inattività. Il tempo effettivo dipende dalle dimensioni del gruppo di failover.
Creare repliche secondarie aggiuntive di ogni database nel server B al server C usando la replica geografica attiva. Ogni database nel server B avrà due database secondari, uno nel server A e uno nel server C. Ciò garantisce che i database primari rimangano protetti durante la transizione.
Eliminare il gruppo di failover. A questo punto, i tentativi di accesso che usano gli endpoint del gruppo di failover iniziano a fallire.
Ricreare il gruppo di failover con lo stesso nome tra i server B e C.
Aggiungere tutti i database primari in B al nuovo gruppo di failover. A questo punto, i tentativi di accesso smettono di fallire.
Eseguire un failover geografico pianificato del gruppo di failover per passare da B a C. Il server C diventa ora primario e B il database secondario. Tutti i database secondari nel server A verranno collegati automaticamente a quelli primari in C. Come nel passaggio 1, il failover potrebbe comportare diversi minuti di inattività.
Eliminare il server A. Tutti i database in A verranno eliminati automaticamente.

Importante

Quando il gruppo di failover viene eliminato, vengono eliminati anche i record DNS per gli endpoint del listener. A questo punto, esiste la probabilità che qualcun altro possa aver creato un gruppo di failover o un alias DNS del server con lo stesso nome. Poiché i nomi dei gruppi di failover e gli alias DNS devono essere univoci a livello globale, questo impedirà di usare di nuovo lo stesso nome. Per ridurre al minimo questo rischio, non usare nomi di gruppo di failover generici.

Gruppi di failover e sicurezza di rete

Per alcune applicazioni, le regole di sicurezza richiedono che l'accesso di rete al livello dati sia limitato a uno o più componenti specifici, ad esempio una macchina virtuale, un servizio Web e così via. Questo prerequisito presenta alcune difficoltà intrinseche per la progettazione della continuità aziendale e l’uso di gruppi di failover. Quando si implementa questo tipo di accesso con restrizioni, è necessario considerare le opzioni seguenti.

Usare i gruppi di failover e gli endpoint servizio di rete virtuale

Se si usano endpoint e regole servizio di rete virtuale per limitare l'accesso al database, tenere presente che ogni endpoint servizio di rete virtuale si applica a una sola area geografica di Azure. L'endpoint non consente ad altre aree di accettare le comunicazioni dalla subnet. Pertanto, solo le applicazioni client distribuite nella stessa area possono connettersi al database primario. Poiché un failover geografico comporta il reindirizzamento delle sessioni client del database SQL a un server in un'area diversa (secondaria), queste sessioni potrebbero avere esito negativo se originate da un client esterno a tale area. Per questo motivo, i criteri di failover gestito da Microsoft non possono essere abilitati se i server partecipanti sono inclusi nelle regole di rete virtuale. Per supportare il failover manuale, seguire questi passaggi:

Effettuare il provisioning delle copie ridondanti dei componenti front-end dell'applicazione (servizio web, macchine virtuali e così via) nell'area secondaria.
Configurare le regole di rete virtuale singolarmente per il server primario e per quello secondario.
Abilitare il failover front-end usando una configurazione di Gestione traffico.
Avviare il failover geografico manuale quando viene rilevata l'interruzione. Questa opzione è ottimizzata per le applicazioni che richiedono la latenza coerente tra il front-end e il livello dati e supporta il ripristino quando il front-end, il livello dati o entrambi sono interessati dall'interruzione del servizio.

Nota

Se si usa il listener di sola lettura per il bilanciamento di un carico di lavoro di sola lettura, assicurarsi che il carico di lavoro venga eseguito in una VM o in un'altra risorsa nell'area secondaria in modo da consentire la connessione al database secondario.

Usare gruppi di failover e regole del firewall

Se il piano di continuità aziendale richiede il failover tramite gruppi di failover, è possibile limitare l'accesso al database SQL utilizzando le regole del firewall IP pubblico. Questa configurazione garantisce che un failover geografico non blocchi le connessioni dai componenti front-end e presuppone che l'applicazione possa tollerare una latenza più lunga tra il front-end e il livello dati.

Per supportare il failover del gruppo, seguire questi passaggi:

Creare un IP pubblico.
Creare un servizio di bilanciamento del carico pubblico e assegnare l'indirizzo IP pubblico a tale servizio.
Creare una rete virtuale e le macchine virtuali per i componenti front-end.
Creare un gruppo di sicurezza di rete e configurare le connessioni in ingresso.
Assicurarsi che le connessioni in uscita siano aperte al database SQL di Azure usando un tag del servizioSql.<Region>.
Creare una regola del firewall del database SQL per consentire il traffico in ingresso dall'indirizzo IP pubblico creato nel passaggio 1.

Per maggiori informazioni su come configurare l'accesso in uscita e su quale indirizzo IP usare nelle regole del firewall, vedere Connessioni in uscita del servizio di bilanciamento del carico.

Importante

Per garantire la continuità aziendale durante le interruzioni regionali, è necessario garantire la ridondanza geografica sia per i componenti front-end che per i database.

Autorizzazioni

Le autorizzazioni per un gruppo di failover vengono gestite tramite il controllo degli accessi in base al ruolo di Azure (Azure RBAC).

L'accesso in scrittura del controllo degli accessi in base al ruolo di Azure è necessario per creare e gestire i gruppi di failover. Il ruolo Collaboratore SQL Server dispone di tutte le autorizzazioni necessarie a gestire i gruppi di failover.

Nella tabella seguente sono elencati gli ambiti di autorizzazione specifici per database SQL di Azure:

Azione	Autorizzazione	Scope
Create failover group	Accesso in scrittura del controllo degli accessi in base al ruolo di Azure	Server primario Server secondario Tutti i database in un gruppo di failover
Aggiorna gruppo di failover	Accesso in scrittura del controllo degli accessi in base al ruolo di Azure	Gruppo di failover Tutti i database nel server primario corrente
Eseguire il failover del gruppo di failover	Accesso in scrittura del controllo degli accessi in base al ruolo di Azure	Gruppo di failover nel nuovo server

Limiti

Tenere presente le limitazioni seguenti:

Non è possibile creare gruppi di failover tra due server nella stessa area di Azure.
I gruppi di failover supportano la replica geografica di tutti i database nel gruppo in un solo server logico secondario in un'area diversa.
I gruppi di failover non possono essere rinominati. Sarà necessario eliminare il gruppo e ricrearlo con un nome diverso.
La ridenominazione del database non è supportata per i database inclusi in un gruppo di failover. Per rinominare un database sarà necessario eliminare temporaneamente il gruppo di failover o rimuovere il database dal gruppo di failover.
La rimozione di un gruppo di failover per un database singolo o in pool non interrompe la replica e non elimina il database replicato. Sarà necessario arrestare manualmente la replica geografica ed eliminare il database dal server secondario se si vuole aggiungere di nuovo un database singolo o in pool a un gruppo di failover dopo averlo rimosso. In caso contrario, potrebbe verificarsi un errore simile a The operation cannot be performed due to multiple errors quando si tenta di aggiungere il database al gruppo di failover.
Il nome del gruppo di failover è soggetto a restrizioni di denominazione.
Quando si crea un nuovo gruppo di failover o quando si aggiungono database a un gruppo di failover esistente, si può solo designare i database come repliche di standbyse si usa il portale di Azure. Azure PowerShell e l'interfaccia della riga di comando di Azure non sono attualmente disponibili.

Gestione programmatica di gruppi di failover

I gruppi di failover possono anche essere gestiti a livello di codice usando Azure PowerShell, l'interfaccia della riga di comando di Azure e l'API REST. Le tabelle seguenti descrivono il set di comandi disponibili. I gruppi di failover includono un set di API di Azure Resource Manager per la gestione, compresa l'API REST del database SQL di Azure e i cmdlet di Azure PowerShell. Queste API richiedono l'uso di gruppi di risorse e supportano la sicurezza basata sui ruoli (Azure RBAC). Per ulteriori informazioni su come implementare i ruoli di accesso, vedere Controllo degli accessi in base al ruolo di Azure (Azure RBAC).

Cmdlet	Descrizione
New-AzSqlDatabaseFailoverGroup	Questo comando crea un gruppo di failover e lo registra nei server primario e secondario
Add-AzSqlDatabaseToFailoverGroup	Aggiunge uno o più database a un gruppo di failover
Remove-AzSqlDatabaseFromFailoverGroup	Rimuove uno o più database da un gruppo di failover
Remove-AzSqlDatabaseFailoverGroup	Rimuove un gruppo di failover dal server
Get-AzSqlDatabaseFailoverGroup	Recupera la configurazione di un gruppo di failover
Set-AzSqlDatabaseFailoverGroup	Modifica la configurazione di un gruppo di failover
Switch-AzSqlDatabaseFailoverGroup	Attiva il failover di un gruppo di failover per il server secondario

Nota

Comando	Descrizione
az sql failover-group create	Crea un gruppo di failover e lo registra nei server primario e secondario
az sql failover-group update	Aggiunge o rimuove i database, o modifica le impostazioni di configurazione del gruppo di failover
az sql failover-group delete	Rimuove un gruppo di failover dal server
az sql failover-group show	Recupera la configurazione di un gruppo di failover
az sql failover-group set-primary	Attiva il failover di un gruppo di failover per il server secondario

API	Descrizione
Create or Update Failover Group	Crea o aggiorna un gruppo di failover, e aggiunge o rimuove i database
Delete Failover Group	Rimuove un gruppo di failover dal server
Failover (Pianificato)	Attiva il failover dal server primario corrente al server secondario con una sincronizzazione dei dati completa.
Force Failover Allow Data Loss	Attiva il failover dal server primario corrente al server secondario senza sincronizzare i dati. Questa operazione potrebbe comportare la perdita di dati.
Get Failover Group	Recupera la configurazione di un gruppo di failover.
List Failover Groups By Server	Elenca i gruppi di failover in un server.
Update Failover Group	Aggiorna la configurazione di un gruppo di failover.

Condividi tramite

Configurare un gruppo di failover per il database SQL di Azure

Prerequisiti

Create failover group

Testare un failover pianificato

Verificare i ruoli di ogni server

Effettuare il failover nel server secondario

Ripristinare il gruppo di failover nel server primario

Verificare i ruoli di ogni server

Effettuare il failover nel server secondario

Ripristinare il gruppo di failover nel server primario

Prerequisiti

Create failover group

Testare un failover pianificato

Verificare i ruoli di ogni server

Effettuare il failover nel server secondario

Ripristinare il gruppo di failover nel server primario

Verificare i ruoli di ogni server

Effettuare il failover nel server secondario

Ripristinare il gruppo di failover nel server primario

Modificare gruppo di failover esistente

Usare Collegamento privato

Individuare l'endpoint del listener

Dimensionare un database in un gruppo di failover

Evitare la perdita di dati critici

Modificare l'area secondaria

Modificare l'area primaria

Gruppi di failover e sicurezza di rete

Usare i gruppi di failover e gli endpoint servizio di rete virtuale

Usare gruppi di failover e regole del firewall

Autorizzazioni

Limiti

Gestione programmatica di gruppi di failover

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Configurare un gruppo di failover per il database SQL di Azure

Prerequisiti

Create failover group

Testare un failover pianificato

Prerequisiti

Create failover group

Testare un failover pianificato

Modificare gruppo di failover esistente

Usare Collegamento privato

Individuare l'endpoint del listener

Dimensionare un database in un gruppo di failover

Evitare la perdita di dati critici

Modificare l'area secondaria

Modificare l'area primaria

Gruppi di failover e sicurezza di rete

Usare i gruppi di failover e gli endpoint servizio di rete virtuale

Usare gruppi di failover e regole del firewall

Autorizzazioni

Limiti

Gestione programmatica di gruppi di failover

Contenuto correlato

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive