Eseguire la migrazione del database SQL di Azure al supporto della zona di disponibilità

Articolo
04/07/2024

Questa guida descrive come eseguire la migrazione di database SQL di Azure dal supporto della zona non di disponibilità al supporto della disponibilità.

L'abilitazione della ridondanza della zona per il database SQL di Azure garantisce una disponibilità elevata perché il database usa zone di disponibilità di Azure per replicare i dati in più posizioni fisiche all'interno di un'area di Azure. Selezionando la ridondanza della zona, è possibile rendere resilienti i database e i pool elastici a un set più ampio di errori, ad esempio interruzioni irreversibili del data center, senza alcuna modifica della logica dell'applicazione.

Prerequisiti

Prima di eseguire la migrazione al supporto della zona di disponibilità, vedere la tabella seguente per assicurarsi che il database SQL di Azure si trovi in un livello di servizio e un modello di distribuzione supportati. Assicurarsi che il livello e il modello siano offerti in un'area che supporta le zone di disponibilità.

Livello di servizio	Modello di distribuzione	Disponibilità di ridondanza della zona
Premium	Database singolo o pool elastico	Tutte le aree che supportano le zone di disponibilità
Business Critical	Database singolo o pool elastico	Tutte le aree che supportano le zone di disponibilità
Utilizzo generico	Database singolo o pool elastico	Aree selezionate che supportano le zone di disponibilità
Hyperscale	Database singolo	Tutte le aree che supportano le zone di disponibilità

Requisiti del tempo di inattività

La migrazione per il livello di servizio Premium, Business Critical e Per utilizzo generico è un'operazione online con una breve disconnessione verso la fine per completare il processo di migrazione. Se è stata implementata la logica di retry per gli errori temporanei standard, non si noterà il failover.

Per il livello di servizio Hyperscale, il supporto della ridondanza della zona può essere specificato solo durante la creazione del database e non può essere modificato dopo il provisioning della risorsa. Se si vuole passare al supporto della zona di disponibilità, è necessario trasferire i dati con copia del database, ripristino temporizzato o replica geografica. Se il database di destinazione si trova in un'area diversa dall'origine o se la ridondanza dell'archiviazione di backup del database per la destinazione è diversa dal database di origine, il tempo di inattività è proporzionale alle dimensioni dell'operazione di dati.

Migrazione (Premium, Business critical e Utilizzo generico)

Per i livelli di servizio Premium, Business critical e Utilizzo generico, è possibile eseguire la migrazione alla ridondanza della zona.

Seguire questa procedura per eseguire la migrazione per un database singolo o un pool elastico.

Eseguire la migrazione di un database singolo

Passare al portale di Azure per trovare il database. Cercare e selezionare Database SQL.
Selezionare il database che si desidera sottoporre a migrazione.
In Impostazioni selezionare Calcolo e archiviazione.
Selezionare Sì per Rendere ridondante la zona del database?
Selezionare Applica.
Attendere di ricevere un avviso di completamento dell'operazione in Notifiche nel menu in alto del portale di Azure.
Per verificare che la ridondanza della zona sia abilitata, selezionare Panoramica e quindi selezionare Proprietà.
Nella sezione Disponibilità verificare che la ridondanza della zona sia impostata su Abilitata.

Aprire PowerShell come amministratore ed eseguire il comando seguente (sostituire i segnaposto in "<>" con i nomi delle risorse). Si noti che <server_name> non deve includere .database.windows.net.

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

$parameters = @{
    ResourceGroupName = '<Resource_Group_Name>'
    ServerName = '<Server_Name>'
    DatabaseName = '<Database_Name>'
}
Set-AzSqlDatabase @parameters -ZoneRedundant

Usare l'interfaccia della riga di comando di Azure per eseguire il comando seguente (sostituire i segnaposto in "<>" con i nomi delle risorse):

    az sql db update --resource-group “<Resource_Group_Name>” --server “<Server_Name>” --name “<Database_Name>” --zone-redundant

Eseguire la migrazione a un pool elastico

Importante

L'abilitazione del supporto della ridondanza della zona per i pool elastici rende ridondanti tutti i database all'interno della zona del pool.

Passare al portale di Azure per trovare e selezionare il pool elastico di cui si vuole eseguire la migrazione.
Selezionare Impostazioni e quindi Configura.
Selezionare Sì per Rendere ridondante la zona del pool elastico?.
Seleziona Salva.
Attendere di ricevere un avviso di completamento dell'operazione in Notifiche nel menu in alto del portale di Azure.
Per verificare che la ridondanza della zona sia abilitata, selezionare Configura e quindi selezionare Impostazioni pool.
L'opzione con ridondanza della zona deve essere impostata su Sì.

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

$parameters = @{
    ResourceGroupName = '<Resource_Group_Name>'
    ServerName = '<Server_Name>'
    ElasticPoolName = '<Elastic_Pool_Name>'
}

Set-AzSqlElasticPool  @parameters -ZoneRedundant

Usare l'interfaccia della riga di comando di Azure per eseguire il comando seguente (sostituire i segnaposto in "<>" con i nomi delle risorse):

    az sql elastic-pool update --resource-group “<Resource_Group_Name>” --server “<Server_Name>” --name “<Elastic_Pool_Name>” --zone-redundant

Ridistribuzione (Hyperscale)

Per il livello di servizio Hyperscale, il supporto della ridondanza della zona può essere specificato solo durante la creazione del database e non può essere modificato dopo il provisioning del database. Se si vuole ottenere supporto per la ridondanza della zona, è necessario eseguire un trasferimento dei dati dal database singolo del livello di servizio Hyperscale esistente. Per eseguire il trasferimento e abilitare l'opzione di ridondanza della zona, è necessario creare un clone usando la copia del database, il ripristino temporizzato o la replica geografica.

Considerazioni sulla ridistribuzione

Esistono due modalità di ridistribuzione (online e offline):
- I Metodi di ripristino temporizzato e copia del database (modalità offline) creano un database coerente in modo transazionale in un determinato momento. Di conseguenza, le modifiche ai dati eseguite dopo l'avvio dell'operazione di copia o ripristino non saranno disponibili nel database copiato o ripristinato.
- Il Metodo di replica geografica (modalità online) è una ridistribuzione in cui le modifiche ai dati dall'origine vengono sincronizzate con la destinazione.
La stringa di connessione per l'applicazione deve essere aggiornata in modo che punti al database con ridondanza della zona.

Ridistribuire un database singolo

Copia del database

Per creare una copia del database e abilitare la ridondanza della zona con il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure, seguire le istruzioni riportate in Copiare una copia coerente in modo transazionale di un database nel database SQL di Azure.

Ripristino temporizzato

Per creare un ripristino temporizzato del database e abilitare la ridondanza della zona con il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure, seguire le istruzioni riportate in Ripristino temporizzato.

Replica geografica

Per creare una replica geografica del database:

Seguire le istruzioni relative a portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure in Configurare la replica geografica e il failover attivi (database SQL di Azure) e abilitare la ridondanza della zona in Calcolo e archiviazione
Il seeding della replica viene eseguito e il tempo impiegato per il seeding dei dati dipende dalle dimensioni del database di origine. È possibile monitorare lo stato del seeding nel portale di Azure o eseguendo le query TSQL seguenti nel database di replica:
```
    SELECT * FROM sys.dm_geo_replication_link_status;
    SELECT * FROM sys.dm_operation_status;
```
Al termine del seeding del database, eseguire un failover pianificato (senza perdita di dati) per rendere il database di destinazione con ridondanza della zona come primario. Usare sys.dm_geo_replication_link_status per visualizzare lo stato della replica geografica. replication_state_desc è CATCH_UP quando il database secondario si trova in uno stato coerente a livello di transazione. Nella DMV sys.dm_operation_status cercare state_desc come COMPLETED al termine dell'operazione di seeding.
Aggiornare il nome del server nelle stringhe di connessione affinché l'applicazione rifletta il nuovo database con ridondanza della zona.
Per eseguire la pulizia, è consigliabile rimuovere il database non con ridondanza della zona originale dalla relazione di replica geografica. È possibile scegliere di eliminarlo.

Disabilitare la ridondanza della zona

Per disabilitare la ridondanza della zona per un database singolo o un pool elastico, è possibile usare il portale o l'API ARM.

Per disabilitare la ridondanza della zona per il livello di servizio Hyperscale, è possibile invertire i passaggi descritti in Ridistribuzione (Hyperscale).To disable zone-redundancy for Hyperscale service tier, you can reverse the steps document in Redeployment (Hyperscale).

Pool elastico
Database singolo

Per disabilitare la ridondanza della zona con portale di Azure:

Passare al portale di Azure per trovare e selezionare il pool elastico che non si vuole più ridondare della zona.
Selezionare Impostazioni e quindi Configura.
Selezionare No per Rendere ridondante la zona del pool elastico?
Seleziona Salva.

Per disabilitare la ridondanza della zona con ARM, vedere Database - Creare o aggiornare in ARM e usare la properties.zoneRedundant proprietà .