Esercitazione: configurare la replica geografica attiva e il failover (database SQL di Azure)

Si applica a:database SQL di Azure

Questo articolo illustra come configurare la replica geografica attiva per il database SQL di Azure nel portale di Azure o nell’interfaccia della riga di comando di Azure e come avviare il failover.

Per i gruppi di failover, vedere Gruppi di failover con database SQL di Azure e Gruppi di failover con Istanza gestita di SQL di Azure.

Prerequisiti

Questa esercitazione mostra come configurare un database per la replica geografica attiva. Per informazioni su come creare un database singolo con portale di Azure, interfaccia della riga di comando di Azure, interfaccia della riga di comando di Azure (sql up) o PowerShell, vedere Guida rapida: creare un database singolo - database SQL di Azure.

Aggiungere un database secondario

La procedura seguente crea un nuovo database secondario in una relazione di replica geografica.

Per aggiungere un database secondario, è necessario essere il proprietario o un comproprietario della sottoscrizione.

Il database secondario ha lo stesso nome del database primario e, per impostazione predefinita, ha lo stesso livello di servizio e le stesse dimensioni di calcolo. Il database secondario può essere un database singolo o un database in pool. Per altre informazioni, vedere il modello di acquisto basato su DTU o il modello di acquisto basato su vCore. Dopo aver creato ed eseguito il seeding del database secondario, inizia la replica dei dati dal database primario al nuovo database secondario.

Se la replica secondaria viene usata solo per il ripristino di emergenza e non dispone di carichi di lavoro di lettura o scrittura, è possibile risparmiare sui costi di licenza designando il database per lo standby quando si configura una nuova relazione di replica geografica attiva. Per altre informazioni, vedere replica standby senza licenza.

Nota

Se il database partner esiste già, ad esempio come risultato della terminazione di una precedente relazione di replica geografica, il comando non riesce.

Portale

1. Nel portale di Azure passare al database per cui si vuole installare la replica geografica.

2. Nella pagina database SQL selezionare il database, scorrere fino a Gestione dati, selezionare Repliche, quindi selezionare Crea replica.

   

3. Selezionare o creare il server per il database secondario e configurare le opzioni Calcolo e archiviazione, se necessario. È possibile selezionare qualsiasi area per il server secondario, ma è consigliabile usare l’area abbinata.

   

   Facoltativamente, è possibile aggiungere un database secondario a un pool elastico. Per creare il database secondario in un pool, selezionare Sì accanto a Usare il pool elastico SQL?, quindi selezionare un pool sul server di destinazione. Un pool deve esistere già nel server di destinazione. Questo flusso di lavoro non crea un pool.

4. Fare clic su Rivedi e crea, rivedere le informazioni, quindi fare clic su Crea.

5. Viene avvitato il database secondario e avviato il processo di distribuzione.

   

6. Una volta completato il processo di distribuzione, il database secondario mostra il relativo stato.

   

7. Tornare alla pagina del database primario e selezionare Repliche. Il database secondario figura nell’elenco delle Repliche geografiche.

   

Interfaccia della riga di comando di Azure

Selezionare il database da configurare per la replica geografica. Occorre specificare le informazioni seguenti:

• Nome originale del database SQL di Azure.
• Nome di SQL Server.
• Nome del gruppo di risorse
• Nome del server in cui si vuole creare la nuova replica

Nota

Il database secondario deve avere lo stesso livello di servizio del database primario.

È possibile selezionare qualsiasi area per il server secondario, ma è consigliabile usare l’area abbinata.

Eseguire il comando az sql db replica create .

az sql db replica create --resource-group ContosoHotel --server contosoeast --name guestlist --partner-server contosowest --family Gen5 --capacity 2 --secondary-type Geo

Facoltativamente, è possibile aggiungere un database secondario a un pool elastico. Per creare il database secondario in un pool, usare il parametro --elastic-pool. Un pool deve esistere già nel server di destinazione. Questo flusso di lavoro non crea un pool.

Viene avvitato il database secondario e avviato il processo di distribuzione.

Al termine della distribuzione, è possibile controllare lo stato del database secondario eseguendo il comando az sql db replica list-links:

az sql db replica list-links --name guestlist --resource-group ContosoHotel --server contosowest

PowerShell

Selezionare il database da configurare per la replica geografica. Occorre specificare le informazioni seguenti:

• Nome originale del database SQL di Azure.
• Nome di SQL Server.
• Nome del gruppo di risorse
• Nome del server in cui si vuole creare la nuova replica

Nota

Il database secondario deve avere lo stesso livello di servizio del database primario.

È possibile selezionare qualsiasi area per il server secondario, ma è consigliabile usare l’area abbinata.

Come di consueto, iniziare la sessione di PowerShell con i cmdlet seguenti per connettere l’account Azure e impostare il contesto della sottoscrizione:

Connect-AzAccount
$subscriptionid = <your subscription id here>
Set-AzContext -SubscriptionId $subscriptionid

$parameters = @{
    ResourceGroupName = 'PrimaryRG'
    ServerName = 'PrimaryServer' 
    DatabaseName = 'TestDB' 
    PartnerResourceGroupName = 'SecondaryRG'
    PartnerServerName = 'SecondaryServer'
    PartnerDatabaseName = 'TestDB'
}

New-AzSqlDatabaseSecondary @parameters

Al termine della distribuzione, è possibile controllare lo stato del database secondario eseguendo il comando Get-AzSqlDatabaseReplicationLink:

$parameters = @{
    ResourceGroupName = 'PrimaryRG'
    ServerName = 'PrimaryServer'
    DatabaseName = 'TestDB'
    PartnerResourceGroupName = 'SecondaryRG'
}

Get-AzSqlDatabaseReplicationLink @parameters

Avviare un failover

Il database secondario può diventare il database primario.

Portale

1. Nel portale di Azure passare al database primario nella relazione di replica geografica.

2. Scorrere fino a Gestione dei dati, quindi selezionare Repliche.

3. Nell’elenco Repliche geografiche selezionare il database che dovrà diventare il nuovo database primario, selezionare i puntini di sospensione, quindi scegliere Failover forzato.

   

4. Selezionare Sì per avviare il failover.

Interfaccia della riga di comando di Azure

Eseguire il comando az sql db replica set-primary.

az sql db replica set-primary --name guestlist --resource-group ContosoHotel --server contosowest

PowerShell

Esegui questo comando:

$parameters = @{
    ResourceGroupName = 'SecondaryRG'
    ServerName = 'SecondaryServer'
    DatabaseName = 'TestDB'
    PartnerResourceGroupName = 'PrimaryServer'
}

Set-AzSqlDatabaseSecondary @parameters -Failover

---

Il comando passa immediatamente il database secondario al ruolo di database primario. Questo processo normalmente viene completato entro 30 secondi o meno.

Per un breve periodo, da 0 a 25 secondi, entrambi i database non sono disponibili mentre vengono scambiati i ruoli. Se il database primario ha più database secondari, il comando riconfigura automaticamente gli altri database secondari per la connessione al nuovo database primario. In circostanze normali il completamento dell’intera operazione dovrebbe richiedere meno di un minuto.

Rimuovere il database secondario

Questa operazione arresta in modo permanente la replica al database secondario e modifica il ruolo del database secondario in un database di lettura/scrittura normale. Se la connettività al database secondario viene interrotta il comando ha esito positivo ma il database secondario non diventa un database di lettura-scrittura fino a quando la connettività non verrà ripristinata.

Portale

1. Nel portale di Azure passare al database primario nella relazione di replica geografica.
2. Selezionare Repliche.
3. Nell’elenco Repliche geografiche selezionare il database da rimuovere dalla relazione di replica geografica, selezionare i puntini di sospensione e quindi selezionare Arresta replica.
4. Verrà visualizzata una finestra di conferma. Fare clic su Sì per rimuovere il database dalla relazione di replica geografica. Impostarla su un database di lettura/scrittura che non fa parte del processo di replica.

Interfaccia della riga di comando di Azure

Eseguire il comando az sql db replica delete-link.

az sql db replica delete-link --name guestlist --resource-group ContosoHotel --server contosoeast --partner-server contosowest

Verificare di voler eseguire l’operazione.

PowerShell

Esegui questo comando:

$parameters = @{
    ResourceGroupName = 'SecondaryRG'
    ServerName = 'SecondaryServer'
    DatabaseName = 'TestDB'
    PartnerResourceGroupName = 'PrimaryRG'
    PartnerServerName = 'PrimaryServer'
}
Remove-AzSqlDatabaseSecondary @parameters

Replica geografica tra sottoscrizioni

Usare Transact-SQL (T-SQL) per creare un database geografico secondario in una sottoscrizione diversa dalla sottoscrizione del database primario, indipendentemente dal fatto che si tratti dello stesso tenant di Microsoft Entra ID (in precedenza Azure Active Directory) o meno, seguire la procedura descritta in questa sezione.

1. Aggiungere l’indirizzo IP del computer client che esegue i comandi T-SQL in questo esempio, ai firewall del server di entrambi i server primario e secondario. È possibile confermare l’indirizzo IP eseguendo la query seguente durante la connessione al server primario dallo stesso computer client.

   select client_net_address from sys.dm_exec_connections where session_id = @@SPID;
   

   Per altre informazioni, vedere Configurare il firewall.

2. Nel database master nel server primario creare un account di accesso per l’autenticazione SQL dedicato alla configurazione attiva della replica geografica. Modificare il nome e la password di accesso come necessario.

   create login geodrsetup with password = 'ComplexPassword01';
   

3. Nello stesso database creare un utente per l’account di accesso e aggiungerlo al ruolo dbmanager:

   create user geodrsetup for login geodrsetup;
   alter role dbmanager add member geodrsetup;
   

4. Prendere nota del valore SID indicato in nell’accesso. Ottenere il valore SID con la query seguente.

   select sid from sys.sql_logins where name = 'geodrsetup';
   

5. Connessione al database primario (non al database master) e creare un utente per lo stesso account di accesso.

   create user geodrsetup for login geodrsetup;
   

6. Nello stesso database aggiungere l’utente al ruolo db_owner.

   alter role db_owner add member geodrsetup;
   

7. Nel database master nel server secondario creare lo stesso account di accesso del server primario, usando lo stesso nome, password e SID. Sostituire il valore SID esadecimale nel comando di esempio seguente con il valore ottenuto nel passaggio 4.

   create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
   

8. Nello stesso database creare un utente per l’account di accesso e aggiungerlo al ruolo dbmanager.

   create user geodrsetup for login geodrsetup;
   alter role dbmanager add member geodrsetup;
   

9. Connettersi al database master nel server primario usando il nuovo accesso geodrsetup e avviare la creazione della replica geografica secondaria nel server secondario. Modificare il nome del database e il nome del server secondario come necessario. Dopo aver eseguito il comando, è possibile monitorare la creazione geografica secondaria eseguendo una query sulla vista sys.dm_geo_replication_link_status nel database primario e sulla vista sys.dm_operation_status nel database master nel server primario. Il tempo necessario per creare un database geografico secondario dipende dalle dimensioni del database primario.

   alter database [dbrep] add secondary on server [servername];
   

10. Dopo la creazione della replica geografica secondaria, è possibile rimuovere gli utenti, gli account di accesso e le regole del firewall creati dalla procedura.

Nota

Le operazioni di replica geografica tra sottoscrizioni, inclusa la configurazione e il failover geografico, sono supportate solo tramite i comandi T-SQL e l’API REST.

L’aggiunta di un database geografico secondario tramite T-SQL non è supportata durante la connessione al server primario tramite un endpoint privato. Se è configurato un endpoint privato, ma è consentito l’accesso alla rete pubblica, l’aggiunta di un database secondario con replica geografica è supportata quando si è connessi al server primario da un indirizzo IP pubblico. Dopo l’aggiunta di un database geografico secondario, è possibile negare l’accesso pubblico.

La creazione di una replica geografica secondaria in un server logico di un tenant di Microsoft Entra diverso non è supportata quando, nel server logico primario o secondario, è abilitata l’autenticazione basata soltanto su Microsoft Entra.

Passaggi successivi

• Per altre informazioni sulla replica geografica attiva, vedere Replica geografica attiva.
• Per informazioni sui gruppi di failover, vedere Gruppi di failover
• Per la panoramica e gli scenari della continuità aziendale, vedere Continuità aziendale del database SQL di Azure.
• Risparmiare sui costi di licenza designando la replica di ripristino di emergenza secondaria per lo standby. 1