Configurare un gruppo di failover per l'istanza gestita di SQL di Azure

Si applica a:Istanza gestita di SQL di Azure

• Database SQL di Azure
• Istanza gestita di database SQL di Azure

Questo articolo illustra come configurare un gruppo di failover per Istanza gestita di SQL di Azure usando il portale di Azure e Azure PowerShell.

Per uno script di PowerShell end-to-end per creare entrambe le istanze all'interno di un gruppo di failover, vedere Aggiungere un'istanza a un gruppo di failover.

Prerequisiti

Tenere in considerazione i seguenti prerequisiti:

• L'istanza gestita secondaria deve essere vuota, ovvero non contenere database utente.
• Le due istanze di Istanza gestita di SQL devono trovarsi nello stesso livello di servizio e avere le stesse dimensioni di archiviazione. Anche se non è necessario, è consigliabile che due istanze abbiano le stesse dimensioni di calcolo per assicurarsi che l'istanza secondaria possa elaborare in modo sostenibile le modifiche replicate dall'istanza primaria, inclusi i periodi di attività di picco.
• L’intervallo di indirizzi IP per la rete virtuale dell'istanza primaria non deve sovrapporsi all'intervallo di indirizzi della rete virtuale per l'istanza gestita secondaria o a qualsiasi altra rete virtuale con peering con la rete virtuale primaria o secondaria.
• Quando si crea l'istanza gestita secondaria, è necessario specificare l'ID zona DNS dell'istanza primaria come valore del parametro DnsZonePartner. Se non si specifica il valore per DnsZonePartner, l'ID della zona viene generato come stringa casuale quando viene creata la prima istanza in ogni rete virtuale e lo stesso ID viene assegnato a tutte le altre istanze nella stessa subnet. Dopo l'assegnazione, la zona DNS non può essere modificata.
• Le regole dei gruppi di sicurezza di rete (NSG) nella subnet che ospita l'istanza devono avere la porta 5022 (TCP) e l'intervallo di porte 11000-11999 (TCP) aperti in ingresso e in uscita per le connessioni da e verso la subnet che ospita l'altra istanza gestita. Questo vale per entrambe le subnet che ospitano le istanze primaria e secondaria.
• Le regole di confronto e il fuso orario dell'istanza gestita secondaria devono corrispondere a quella dell'istanza gestita primaria.
• Le istanze gestite dovrebbero essere implementate in aree associate per motivi di prestazioni. Le istanze gestite che risiedono in aree geografiche associate traggono vantaggio da una velocità di replica geografica significativamente superiore rispetto alle aree non abbinate.

Intervallo spazio indirizzi

Per controllare lo spazio indirizzi dell'istanza primaria, passare alla risorsa di rete virtuale per l'istanza primaria e selezionare Spazio indirizzi in Impostazioni. Controllare l'intervallo in Intervallo di indirizzi:

Specificare l'ID zona dell'istanza primaria

Quando si crea l'istanza secondaria, è necessario specificare l'ID zona dell'istanza primaria come DnsZonePartner.

Portale

Se si sta creando l'istanza secondaria nel portale di Azure, nella scheda Impostazioni aggiuntive in Replica geografica scegliere Sì da usare come database secondario di failover e quindi selezionare l'istanza primaria dall'elenco a discesa:

PowerShell

Se si sta creando l'istanza secondaria con Azure PowerShell, assicurarsi di specificare il parametro DnsZonePartner con l'ID zona dell'istanza primaria.

È possibile usare il comando Get-AzSqlInstance per parametrizzare l'ID zona DNS dell'istanza primaria e quindi passarlo al DnsZonePartner parametro del comando New-AzSqlInstance:

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

# Create the secondary managed instance
New-AzSqlInstance -Name $secondaryInstance `
                  -ResourceGroupName $resourceGroupName `
                  -Location $drLocation `
                  -SubnetId $secondaryMiSubnetConfigId `
                  -AdministratorCredential $mycreds `
                  -StorageSizeInGB $maxStorage `
                  -VCore $vCores `
                  -Edition $edition `
                  -ComputeGeneration $computeGeneration `
                  -LicenseType $license `
                  -DnsZonePartner $primaryManagedInstanceId.Id
Write-host "Secondary SQL Managed Instance created successfully."

Abilitazione della connettività tra le istanze

La connettività tra le subnet della rete virtuale che ospita le istanze primaria e secondaria deve essere stabilita per il flusso ininterrotto del traffico di replica geografica. Esistono diversi modi per stabilire la connettività tra istanze gestite in aree di Azure diverse, tra cui:

• Peering di rete virtuale globale
• Azure ExpressRoute
• Gateway VPN

Il peering di reti virtuali globale è il metodo consigliato più solido e performante per stabilire la connettività tra due istanze in un gruppo di failover. Il peering di reti virtuali globali consente di avere una connessione privata a bassa latenza e con larghezza di banda elevata tra le reti virtuali con peering usando l'infrastruttura backbone di Microsoft. Nella comunicazione tra le reti virtuali con peering non sono necessari gateway, la rete Internet pubblica o una crittografia aggiuntiva.

Importante

I modi alternativi di connessione delle istanze che coinvolgono dispositivi di rete aggiuntivi potrebbero complicare la risoluzione dei problemi di connettività o velocità di replica, eventualmente richiedendo un coinvolgimento attivo degli amministratori di rete e un tempo di risoluzione potenzialmente significativo.

Indipendentemente dal meccanismo di connettività, è necessario soddisfare i requisiti per il flusso del traffico di replica geografica:

• Le tabelle di routing e i gruppi di sicurezza di rete assegnati alle subnet dell'istanza gestita non vengono condivisi tra le due reti virtuali con peering.
• Le regole del gruppo di sicurezza di rete (NSG) nella subnet che ospita l'istanza primaria consentono:
  • Traffico in ingresso sulla porta 5022 e intervallo di porte 11000-11999 dalla subnet che ospita l'istanza secondaria.
  • Traffico in uscita sulla porta 5022 e intervallo di porte 11000-11999 verso la subnet che ospita l'istanza secondaria.
• Le regole del gruppo di sicurezza di rete nella subnet che ospita l'istanza secondaria consentono:
  • Traffico in ingresso sulla porta 5022 e intervallo di porte 11000-11999 dalla subnet che ospita l'istanza primaria.
  • Traffico in uscita sulla porta 5022 e intervallo di porte 11000-11999 verso la subnet che ospita l'istanza primaria.
• Gli intervalli di indirizzi IP delle reti virtuali che ospitano l'istanza primaria e l'istanza secondaria non devono sovrapporsi.
• Non deve esistere alcuna sovrapposizione indiretta degli intervalli di indirizzi IP tra le reti virtuali che ospitano l'istanza primaria e l'istanza secondaria e qualsiasi altra rete virtuale a cui sono associate tramite peering di reti virtuali locale o altri mezzi.

Inoltre, se si usano altri meccanismi per fornire la connettività tra le istanze rispetto al peering di reti virtuali globale consigliato, è necessario verificare che:

• I dispositivi di rete usati, ad esempio firewall o appliance virtuali di rete, non blocchino il traffico verso le porte indicate in precedenza.
• Il routing è configurato correttamente e il routing asimmetrico viene evitato.
• Se si distribuiscono gruppi di failover in una topologia di rete hub-spoke tra aree diverse, il traffico di replica deve transitare direttamente tra le due subnet dell'istanza gestita anziché essere indirizzato attraverso le reti hub. In questo modo sarà possibile evitare problemi di connettività e velocità di replica.

Portale

1. Nel portale di Azure passare alla risorsa Rete virtuale per l'istanza gestita primaria.
2. In Impostazioni selezionare Peering e quindi Aggiungi.

1. Immettere o selezionare i valori per le impostazioni seguenti:

   Impostazioni	Descrizione
   Questa rete virtuale
   Nome del collegamento di peering	il nome per il peering deve essere univoco all'interno della rete virtuale.
   Traffico verso la rete virtuale remota	Selezionare Consenti (impostazione predefinita) per abilitare la comunicazione tra le due reti virtuali tramite il flusso VirtualNetwork predefinito. L'abilitazione della comunicazione tra reti virtuali consente alle risorse connesse a una o all'altra delle reti virtuali di comunicare tra loro con la stessa larghezza di banda e latenza che userebbero se fossero connesse alla stessa rete virtuale. Tutte le comunicazioni tra le risorse nelle due reti virtuali avvengono tramite la rete privata di Azure.
   Traffico inoltrato dalla rete virtuale remota	Entrambe le opzioni Consentito (impostazione predefinita) e Blocca funzioneranno per questa esercitazione. Per altre informazioni, vedere Creare un peering
   Gateway di rete virtuale o server di route	Selezionare Nessuno. Per altre informazioni sulle altre opzioni disponibili, vedere Creare un peering.
   Rete virtuale remota
   Nome del collegamento di peering	Nome dello stesso peering da usare nella rete virtuale che ospita l'istanza secondaria.
   Modello di distribuzione della rete virtuale	Seleziona Gestione risorse.
   Conosco l'ID della risorsa	Lasciare deselezionata questa casella di controllo.
   Abbonamento	Selezionare la sottoscrizione Azure della rete virtuale che ospita l’istanza secondaria con la quale si vuole eseguire il peering.
   Rete virtuale	Selezionare la rete virtuale che ospita l'istanza secondaria con cui si vuole eseguire il peering. Se la rete virtuale è elencata, ma disattivata, la causa potrebbe essere la sovrapposizione dello spazio indirizzi per la rete virtuale con lo spazio indirizzi per questa rete virtuale. Se gli spazi indirizzi delle reti virtuali si sovrappongono, non è possibile eseguire il peering.
   Traffico verso la rete virtuale remota	Seleziona Consenti (predefinita)
   Traffico inoltrato dalla rete virtuale remota	Entrambe le opzioni Consentito (impostazione predefinita) e Blocca funzioneranno per questa esercitazione. Per altre informazioni, vedere Creare un peering.
   Gateway di rete virtuale o server di route	Selezionare Nessuno. Per altre informazioni sulle altre opzioni disponibili, vedere Creare un peering.

2. Per aggiungere il peering alla rete virtuale selezionata, selezionare Aggiungi. Dopo alcuni secondi, selezionare il pulsante Aggiorna e lo stato del peering cambierà da Aggiornamento a Connesso.

   

PowerShell

Configurare il peering di reti virtuali globali tra le reti virtuali delle istanze gestite primarie e secondarie:

# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

Questo frammento di codice usa i comandi seguenti:

Comando	Note
1. Get-AzVirtualNetwork	Ottiene una rete virtuale in un gruppo di risorse.
2. Add-AzVirtualNetworkPeering	Aggiungere un peering di rete virtuale.
3. Get-AzVirtualNetworkPeering	Ottiene il peering per una rete virtuale.

Creare il gruppo di failover

Creare il gruppo di failover per le istanze gestite usando il portale di Azure o PowerShell.

Portale

Creare il gruppo di failover per i Istanza gestita di SQL usando il portale di Azure.

1. Selezionare Azure SQL nel menu a sinistra nel portale di Azure. 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 del riquadro di spostamento sinistro.

2. Selezionare l'istanza gestita primaria da aggiungere al gruppo di failover.

3. In Impostazioni passare a Gruppi di failover dell'istanza e quindi scegliere Aggiungi gruppo per aprire la pagina di creazione del Gruppo di failover dell'istanza.

   

4. Nella pagina Gruppo di failover dell'istanza digitare il nome del gruppo di failover e quindi scegliere l'istanza gestita secondaria dall'elenco a discesa. Fare clic su Crea per creare il gruppo di failover.

   

5. Al termine della distribuzione del gruppo di failover, si tornerà alla pagina Gruppo di failover.

PowerShell

Usare New-AzSqlDatabaseInstanceFailoverGroup per creare il gruppo di failover per le istanze gestite usando PowerShell.

# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

Failover di test

Testare il gruppo di failover con il portale di Azure o con PowerShell.

Portale

Testare il failover del gruppo di failover con il portale di Azure.

1. Passare all'istanza gestita secondaria con il portale di Azure e selezionare Gruppi di failover dell'istanza nelle impostazioni.

2. Prendere nota delle istanze gestite nel ruolo primario e secondario.

3. Selezionare Failover e quindi selezionare Sì nell'avviso relativo alla disconnessione delle sessioni TDS.

   

4. Prendere nota delle istanze gestite nel ruolo primario e secondario. Se il failover è riuscito, le due istanze dovrebbero essersi scambiate i ruoli.

   

Importante

Se i ruoli non sono passati, controllare la connettività tra le istanze e i gruppi di sicurezza di rete e le regole del firewall correlate. Procedere con il passaggio successivo solo dopo il cambio di ruolo.

1. Passare alla nuova istanza gestita secondaria e selezionare Failover ancora una volta per eseguire il failback dell'istanza primaria al ruolo primario.

PowerShell

Testare il failover pianificato eseguendo il failover alla replica secondaria e quindi eseguendo il failback.

Verificare i ruoli di ogni server

Usare il comando Get-AzSqlDatabaseInstanceFailoverGroup per confermare i ruoli di ogni server:

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Effettuare il failover nel server secondario

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

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

Ripristinare il gruppo di failover nel server primario

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

# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

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

Individuare l'endpoint del listener

Dopo aver configurato il gruppo di failover, aggiornare la stringa di connessione per l'applicazione all'endpoint del listener. Mantiene l'applicazione connessa al listener del gruppo di failover, anziché al database primario, al pool elastico o al database dell'istanza. In questo modo, non è necessario aggiornare manualmente il 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 nel portale di Azure, quando si visualizza il gruppo di failover:

Creare un gruppo tra le istanze in sottoscrizioni diverse

È possibile creare un gruppo di failover tra istanze gestite di SQL in due sottoscrizioni diverse, purché le sottoscrizioni siano associate allo stesso tenant di Microsoft Entra.

• Quando si usa l'API di PowerShell, è possibile farlo specificando il parametro PartnerSubscriptionId per l’Istanza gestita di SQL secondaria.
• Quando si usa l'API REST, ogni ID istanza incluso nel parametro properties.managedInstancePairs può avere il proprio ID sottoscrizione.
• Il portale di Azure non supporta la creazione di gruppi di failover in sottoscrizioni diverse.

Importante

Il portale di Azure non supporta la creazione di gruppi di failover in sottoscrizioni diverse. Per i gruppi di failover esistenti in sottoscrizioni e/o gruppi di risorse diversi, il failover non può essere avviato manualmente tramite il portale di Azure dall'istanza gestita di SQL primaria. È quindi necessario avviarlo dall'istanza geografica secondaria.

Evitare la perdita di dati critici

A causa della latenza elevata delle Wide Area Network, per la copia 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, uno sviluppatore di applicazioni può chiamare 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 sul primario al momento della chiamata.

Modificare l'area secondaria

Si supponga che l'istanza A sia l'istanza primaria, l'istanza B sia l'istanza secondaria esistente e l'istanza C sia la nuova istanza secondaria nella terza area. Per eseguire la transizione, seguire questa procedura:

1. Creare l'istanza C con le stesse dimensioni di A e nella stessa zona DNS.
2. Eliminare il gruppo di failover tra le istanze A e B. A questo punto, i tentativi di accesso iniziano a non riuscire perché gli alias SQL per i listener del gruppo di failover sono stati eliminati e il gateway non riconoscerà il nome del gruppo di failover. I database secondari vengono disconnessi dalle primarie e diventano database di lettura/scrittura.
3. Creare un gruppo di failover con lo stesso nome tra l'istanza A e C. Seguire le istruzioni riportate nella guida alla configurazione del gruppo di failover. Si tratta di un'operazione di dimensioni dei dati e viene completata quando tutti i database dell'istanza A vengono inizializzati e sincronizzati.
4. Eliminare l'istanza B se non è necessario per evitare addebiti non necessari.

Nota

Dopo il passaggio 2 e fino al passaggio 3 i database nell'istanza A rimarranno non protetti da un errore irreversibile dell'istanza A.

Cambiare l'area primaria

Si supponga che l'istanza A sia l'istanza primaria, l'istanza B sia l'istanza secondaria esistente e l'istanza C sia la nuova istanza primaria nella terza area. Per eseguire la transizione, seguire questa procedura:

1. Creare l'istanza C con le stesse dimensioni di B e nella stessa zona DNS.
2. Eseguire la connessione all'istanza B ed eseguire il failover manuale per passare automaticamente l'istanza primaria a B. L'istanza A diventa automaticamente la nuova istanza secondaria.
3. Eliminare il gruppo di failover tra le istanze A e B. A questo punto, i tentativi di accesso che usano gli endpoint del gruppo di failover iniziano a non riuscire. I database secondari in A vengono disconnessi dalle primarie e diventano database di lettura/scrittura.
4. Creare un gruppo di failover con lo stesso nome tra l'istanza B e C. Seguire le istruzioni nella guida al gruppo di failover. Si tratta di un'operazione di dimensioni dei dati e viene completata quando tutti i database dell'istanza A vengono inizializzati e sincronizzati. A questo punto, i tentativi di accesso si arrestano.
5. Eseguire manualmente il failover per passare l'istanza C al ruolo primario. L'istanza B diventa automaticamente la nuova istanza secondaria.
6. Eliminare l'istanza A se non è necessario per evitare addebiti non necessari.

Attenzione

Dopo il passaggio 3 e fino al completamento del passaggio 4, i database nell'istanza A rimarranno non protetti da un errore irreversibile dell'istanza A.

Importante

Quando il gruppo di failover viene eliminato, vengono eliminati anche i record DNS per gli endpoint del listener. A questo punto, esiste una probabilità diversa da zero che qualcun altro crei un gruppo di failover con lo stesso nome. Poiché i nomi dei gruppi di failover devono essere univoci a livello globale, ciò impedirà di usare di nuovo lo stesso nome. Per ridurre al minimo questo rischio, non usare nomi di gruppo di failover generici.

Abilitare scenari dipendenti da oggetti dai database di sistema

I database di sistema non vengono replicati nell'istanza secondaria in un gruppo di failover. Per abilitare scenari che dipendono dagli oggetti dei database di sistema, assicurarsi di creare gli stessi oggetti nell'istanza secondaria e di mantenerli sincronizzati con l'istanza primaria.

Ad esempio, se si prevede di usare gli stessi account di accesso nell'istanza secondaria, assicurarsi di crearli con lo stesso SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Per altre informazioni, vedere Replica di account di accesso e processi dell'agente.

Sincronizzare le proprietà dell'istanza e le istanze dei criteri di conservazione

Le istanze in un gruppo di failover rimangono risorse di Azure separate e non verranno replicate automaticamente modifiche alla configurazione dell'istanza primaria nell'istanza secondaria. Assicurarsi di eseguire tutte le modifiche rilevanti sia nell'istanza primaria che secondaria. Ad esempio, se si modificano i criteri di ridondanza dell'archivio di backup o di conservazione dei backup a lungo termine nell'istanza primaria, assicurarsi di modificarlo anche nell'istanza secondaria.

Ridimensionamento delle istanze

È possibile aumentare o ridurre le prestazioni dell'istanza primaria e secondaria passando a dimensioni di calcolo diverse all'interno dello stesso livello di servizio o di un livello di servizio diverso. Quando si aumenta all’interno dello stesso livello di servizio, è consigliabile aumentare prima quelle del database secondario geografico e quindi quelle del database primario. Quando si effettua un ridimensionamento nello stesso livello di servizio, invertire l'ordine: ridurre prima le prestazioni del database primario e quindi ridurre le prestazioni di quello secondario. Quando si dimensiona l'istanza a un livello di servizio diverso, viene applicato il consiglio seguente.

Questa sequenza è consigliata specificamente per evitare il problema in cui la replica geografica secondaria nell'SKU di una versione precedente è in rapporto di overload e richiede un nuovo processo di seeding durante la procedura di aggiornamento o downgrade.

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 controllo degli accessi in base al ruolo di Azure è necessario per creare e gestire i gruppi di failover. Il ruolo Collaboratore Istanza gestita di SQL dispone di tutte le autorizzazioni necessarie per gestire i gruppi di failover.

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

Azione	Autorizzazione	Scope
Create failover group	Accesso in scrittura per il controllo degli accessi in base al ruolo di Azure	Istanza gestita primaria Istanza gestita secondaria
Aggiornare il gruppo di failover	Accesso in scrittura per il controllo degli accessi in base al ruolo di Azure	Gruppo di failover Tutti i database all'interno dell'istanza gestita
Eseguire il failover del gruppo di failover	Accesso in scrittura per il controllo degli accessi in base al ruolo di Azure	Gruppo di failover nella nuova istanza gestita primaria

Limiti

Tenere presente le limitazioni seguenti:

• Non è possibile creare gruppi di failover tra due istanze nella stessa area di Azure.
• I gruppi di failover non possono essere rinominati. Sarà necessario eliminare il gruppo e ricrearlo con un nome diverso.
• Un gruppo di failover contiene esattamente due istanze gestite. L'aggiunta di istanze aggiuntive al gruppo di failover non è supportata.
• Un'istanza può partecipare a un solo gruppo di failover alla volta.
• Non è possibile creare un gruppo di failover tra due istanze appartenenti a tenant di Azure diversi.
• Non è possibile creare un gruppo di failover tra due istanze appartenenti a sottoscrizioni di Azure diverse usando portale di Azure o l'interfaccia della riga di comando di Azure. Usare invece Azure PowerShell o l'API REST per creare un gruppo di failover di questo tipo. Dopo la creazione, il gruppo di failover tra sottoscrizioni è regolarmente visibile nel portale di Azure e tutte le operazioni successive, inclusi i failover, possono essere avviate da portale di Azure o dall'interfaccia della riga di comando di Azure.
• La ridenominazione del database non è supportata per i database inclusi in un gruppo di failover. Per poter rinominare un database sarà necessario eliminare temporaneamente il gruppo di failover.
• I database di sistema non vengono replicati nell'istanza secondaria in un gruppo di failover. Di conseguenza, gli scenari che dipendono da oggetti dei database di sistema, ad esempio gli accessi al server e i processi degli agenti, richiedono la creazione manuale degli oggetti nelle istanze secondarie che devono essere sincronizzati manualmente quando vengono apportate eventuali modifiche nell'istanza primaria. L'unica eccezione è la chiave master del servizio per un'istanza gestita di SQL replicata automaticamente nell’istanza secondaria durante la creazione di un gruppo di failover. Tutte le modifiche successive della chiave master del servizio nell'istanza primaria, tuttavia, non verranno replicate nell'istanza secondaria. Per altre informazioni, vedere Come abilitare scenari dipendenti da oggetti dai database di sistema.
• Non è possibile creare gruppi di failover tra istanze se presenti in un pool di istanze.

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 insieme 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 il Controllo degli accessi in base al ruolo di Azure (Azure RBAC). Per altre informazioni su come implementare i ruoli di accesso, vedere Controllo degli accessi in base al ruolo di Azure (Azure RBAC).

PowerShell

Cmdlet	Descrizione
New-AzSqlDatabaseInstanceFailoverGroup	Questo comando crea un gruppo di failover e lo registra nell’istanza primaria e secondaria
Set-AzSqlDatabaseInstanceFailoverGroup	Modifica la configurazione di un gruppo di failover
Get-AzSqlDatabaseInstanceFailoverGroup	Recupera la configurazione di un gruppo di failover
Switch-AzSqlDatabaseInstanceFailoverGroup	Attiva il failover del gruppo di failover per l’istanza secondaria
Remove-AzSqlDatabaseInstanceFailoverGroup	Rimuove un gruppo di failover

Interfaccia della riga di comando di Azure

Comando	Descrizione
az sql instance-failover-group create	Questo comando crea un gruppo di failover e lo registra nei server primario e secondario
az sql instance-failover-group delete	Rimuove un gruppo di failover dal server
az sql instance-failover-group show	Recupera la configurazione di un gruppo di failover
az sql instance-failover-group update	Modifica la configurazione di un gruppo di failover e/o aggiunge uno o più database a un gruppo di failover
az sql instance-failover-group set-primary	Attiva il failover di un gruppo di failover per il server secondario

REST API

API	Descrizione
Create or Update Failover Group	Crea o aggiorna la configurazione di un gruppo di failover
Delete Failover Group	Rimuove un gruppo di failover dall'istanza
Failover (Planned)	Attiva il failover dall'istanza primaria corrente a questa istanza con sincronizzazione dei dati completa.
Force Failover Allow Data Loss	Attiva il failover dall'istanza primaria corrente all'istanza secondaria 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 - List By Location	Elenca i gruppi di failover in una posizione.

Passaggi successivi

Per la procedura di configurazione di un gruppo di failover, vedere la guida Aggiungere un'istanza gestita a un gruppo di failover.

Per una panoramica della funzionalità, vedere Gruppi di failover. Per informazioni su come risparmiare sui costi di licenza, vedere Configurare la replica standby.