Configurare una replica standby senza licenza (anteprima) per database SQL di Azure

  • Articolo

Si applica a:Database SQL di Azure

Questo articolo descrive come risparmiare sui costi di licenza designando il database di ripristino di emergenza secondario per standby quando si usa database SQL di Azure.

Nota

Le repliche database SQL di Azure standby sono attualmente in anteprima.

Panoramica

Quando una replica di database secondaria viene usata solo per il ripristino di emergenza e non ha carichi di lavoro in esecuzione su di essa o le applicazioni che vi si connettono, è possibile risparmiare sui costi di licenza designando il database come replica di standby. Quando un database secondario viene designato per lo standby, Microsoft fornisce un numero di vCore corrispondente al numero di vCore concessi in licenza al database primario, senza alcun costo aggiuntivo, in base ai diritti di failover offerti dalle condizioni di licenza del prodotto. Viene comunque addebitato il calcolo e l'archiviazione usati dal database secondario.

È possibile indicare una replica per standby quando si configura una nuova replica geografica attiva, oppure è possibile convertire una replica esistente in standby.

Mentre la replica geografica attiva supporta l'aggiunta di quattro repliche secondarie, è possibile designare una sola replica di database secondaria per standby. I gruppi di failover supportano una replica di database secondaria per ogni database primario e possono essere leggibili o in standby.

Durante il failover pianificato o non pianificato, la replica di standby diventa la nuova replica primaria e inizia a comportare costi regolari di licenza vCore mentre il database primario originale diventa il nuovo database secondario di standby e smette di incorrere in costi di licenza vCore.

Per altre informazioni, guardare questo video Data Exposed:

Vantaggi economici

Quando si designa una replica del database come standby, Microsoft non prevede l'addebito dei costi di licenza di SQL Server relativi ai vCore usati dalla replica di standby. Tuttavia, poiché il database viene fatturato per l'intera ora, è comunque possibile che vengano addebitati costi di licenza per l'intera ora se la modifica dello stato viene apportata al centro dell'ora.

Il vantaggio si traduce in modo diverso tra i clienti che usano il modello con pagamento in base al consumo e quelli che usano il modello Vantaggio Azure Hybrid. I clienti con pagamento in base al consumo vedono i vCore scontati dalla fattura. Per un cliente che usa il Vantaggio Azure Hybrid per la replica di standby, il numero di vCore usati dalla replica secondaria viene restituito al pool di licenze.

Ad esempio, come cliente con pagamento in base al consumo, se sono stati assegnati 16 vCore al database secondario, viene visualizzato uno sconto per 16 vCore nella fattura se si designa il database secondario come solo standby.

In un altro esempio, se si dispone di 16 licenze Vantaggio Azure Hybrid e si distribuisce un database con 16 vCore, dopo aver designato il database secondario per standby, vengono restituiti 16 vCore al pool di licenze da usare con altre distribuzioni SQL di Azure.

Capacità funzionali

Nella tabella seguente vengono descritte le funzionalità funzionali di una replica di database secondaria di standby:

Funzionalità Descrizione
Carichi di lavoro di lettura limitati Dopo aver designato il database come standby, è possibile eseguire solo un numero limitato di carichi di lavoro di lettura sul database secondario, come ad esempio DMV, backup e query DBCC.
Failover pianificato La replica di standby supporta tutti gli scenari di failover pianificati, inclusi i drill di ripristino, la rilocazione dei database in aree diverse e la restituzione dei database al database primario. Quando il database secondario passa al database primario, può quindi gestire query di lettura e scrittura. Il nuovo secondario (il vecchio primario) diventano la replica di standby e non devono essere usati per i carichi di lavoro di lettura.
Failover non pianificato Durante un failover non pianificato, quando il database secondario passa al ruolo primario è in grado di servire query sia di lettura che di scrittura. Dopo la mitigazione dell'interruzione e la riconnessione del database primario originale, questo diventa la nuova replica di standby secondaria e non deve essere usato per i carichi di lavoro di lettura.
Backup e ripristino Il comportamento di backup e ripristino in una replica di standby e una replica di database secondaria leggibile sono gli stessi.
Monitoraggio Tutte le operazioni di monitoraggio supportate da una replica secondaria leggibile sono supportate dalla replica di standby.

La replica di database standby deve essere usata solo per il ripristino di emergenza. Nessuna applicazione di produzione può essere connessa alla replica. Di seguito sono riportate le uniche attività consentite sul database di standby:

  • Esecuzione di operazioni di manutenzione, ad esempio checkDB
  • Connessione di applicazioni di monitoraggio
  • Eseguire esercitazioni sul ripristino di emergenza

Limiti

Nella tabella seguente sono elencati i metodi di distribuzione supportati e non supportati:

Modello di distribuzione Livello di calcolo Livello di servizio Replica standby supportata Hardware
Database singolo Provisioning eseguito Utilizzo generico Sì Serie Standard (Gen5), serie FSv2, serie DC
Database singolo Provisioning eseguito Business Critical Sì Serie Standard (Gen5), serie DC
Database singolo Provisioning eseguito Hyperscale N/D N/D
Database singolo Senza server Tutti No N/D
Pool elastico Tutte le date Tutti No N/D

L'uso di un database standby presenta le limitazioni seguenti:

  • Per standby è possibile designare una sola replica di database secondaria.
  • Il livello di elaborazione serverless non è supportato. La replica standby non può essere abilitata se il database primario o secondario si trova nel livello di elaborazione serverless.
  • Il modello di acquisto DTU non è supportato. È possibile abilitare una replica standby per i database usando solo il modello di acquisto vCore.
  • Il livello di servizio Hyperscale non è supportato. Solo i database nei livelli di servizio Utilizzo generico e Business Critical possono essere designati per lo standby.
  • Quando si usa un gruppo di failover, i diritti di standby vengono assegnati a livello di database, non a livello di gruppo di failover e devono essere assegnati separatamente per ogni database all'interno del gruppo di failover.
  • La progettazione di una replica secondaria per standby non è supportata quando la replica è una replica secondaria di una replica secondaria (un processo noto è il concatenamento).

Prerequisiti

  • Una sottoscrizione di Azure. Se non si ha una sottoscrizione di Azure, creare un account Azure gratuito prima di iniziare.
  • Un database SQL di Azure vCore con provisioning primario nel livello di servizio Utilizzo generico o Business Critical in esecuzione nell'hardware supportato. Per iniziare, vedere questi argomenti di avvio rapido.

Configurare una nuova replica per standby

È possibile designare una replica per standby quando si configura una nuova relazione di replica geografica attiva usando il portale di Azure, PowerShell, l'interfaccia della riga di comando di Azure o API REST.

Per creare una nuova relazione di replica geografica attiva e designare il database secondario per lo standby nel portale di Azure, seguire questa procedura:

  1. Passare alla risorsa del database SQL nel portale di Azure.

  2. Scegliere Repliche in Gestione dei dati dal menu delle risorse e quindi selezionare + Crea replica per aprire la pagina Crea database SQL - Replica geografica.

    Screenshot della pagina di replica per il database SQL nel portale di Azure.

  3. Nella pagina Crea database SQL - Replica geografica selezionare Replica di standby per Tipo di replica in Configurazione replica. Selezionare la casella per confermare che si userà la replica per standby.

    Screenshot della pagina Crea replica geografica con la replica standby evidenziata nella portale di Azure.

  4. Specificare un server nuovo o esistente per il nuovo database di standby e quindi usare Rivedi e crea per eseguire una convalida finale dei dettagli del database e del server.

  5. Usare Crea per confermare le impostazioni e creare la nuova replica di database standby.

Convertire una replica esistente

È possibile usare il portale di Azure o il comando API REST Collegamento di replica - Aggiorna per convertire una replica esistente da una normale replica geografica a una replica standby o una replica standby in una normale replica geografica.

Per convertire una replica esistente nel portale di Azure, seguire questi passaggi:

  1. Passare alla risorsa del database SQL nel portale di Azure.
  2. Selezionare Repliche in Gestione dati.
  3. Selezionare i puntini di sospensione (...) per la replica e quindi:
    1. Per convertire una replica normale in una replica standby, scegliere Converti in standby. Selezionare la casella accanto a Confermo... nella finestra popup Converti in replica standby e quindi selezionare Sì per salvare le modifiche e convertire la replica.
    2. Per convertire una replica standby in una replica geografica normale, scegliere Converti in area geografica. Selezionare la casella accanto a Confermo... nella finestra popup Converti in replica geografica e quindi selezionare Sì per salvare le modifiche e convertire la replica.

Per convertire una replica esistente usando il comando API REST Collegamenti di replica - Aggiorna, indicare linkType come STANDBY per una replica standby o GEO per convertire una replica standby esistente in una normale replica geografica.

Visualizzare i diritti di licenza

È possibile visualizzare i diritti di licenza per un database esistente usando il portale di Azure, PowerShell, l'interfaccia della riga di comando di Azure o API REST.

Per controllare i diritti di licenza per un database esistente usando il portale di Azure, seguire questa procedura:

  1. Passare al database SQL nel portale di Azure.

  2. Nella pagina Panoramica selezionare Tipo di replica in Essentials. Un valore Standby indica che il database è una replica standby e non vengono addebitati i costi di licenza SQL per questo database:

    Screenshot della pagina di panoramica per il database SQL nel portale di Azure con il tipo di replica evidenziato.

Rimuovere la replica di standby

Dopo che un database è designato come standby, non è possibile semplicemente rimuovere la proprietà standby. Per rimuovere una replica standby, è necessario arrestare la replica per terminare la relazione di replica geografica attiva. Dopo l'arresto della replica, il database diventa autonomo e si inizierà a sostenere i costi di licenza.

È possibile arrestare la replica geografica usando le portale di Azure, PowerShell, l'interfaccia della riga di comando di Azure o API REST.

Per rimuovere una replica di standby terminando la replica geografica nel portale di Azure, seguire questa procedura:

  1. Passare al database SQL nel portale di Azure.
  2. Selezionare Repliche in Gestione dati.
  3. Selezionare i puntini di sospensione (...) per la replica standby e quindi selezionare Interrompi replica dal menu a comparsa. Questa operazione arresta la replica in modo che il database secondario sia ora autonomo anziché designato per standby e incorra in costi di licenza.

Domande frequenti

  • Quali sono le implicazioni a livello di prezzi?

    Le repliche di database secondarie vengono addebitate per le licenze SQL, il calcolo e l'archiviazione per i dati e i backup. Quando si designa una replica di database per standby, non vengono addebitati i costi di licenza per i vCore usati dalla replica secondaria, ma vengono comunque addebitati costi di calcolo e archiviazione.

  • Quali sono i risparmi approssimativi con una replica standby?

    Senza costi di licenza, una replica standby può risparmiare tra il 35 e il 40% rispetto a una normale replica secondaria completamente leggibile, sebbene i risparmi varino in base all'area. Per ottenere prezzi accurati, usare il Calcolatore prezzi di Azure e impostare la licenza di SQL Server su Vantaggio Azure Hybrid.

  • Quanti vCore saranno gratuiti per la licenza per la replica di standby?

    Lo stesso numero di vCore usati dal database primario. La configurazione della replica secondaria con lo stesso numero di vCore del database primario è consigliata per prestazioni ottimali di replica geografica.

  • È necessario avere una licenza di SQL Server con Software Assurance attivo per usare una replica standby?

    No. Poiché la replica standby non comporta costi di licenza, non è necessaria una licenza attiva di SQL Server con Software Assurance attivo.

  • Come è possibile usare la replica standby?

    Le repliche di standby sono destinate solo a scopi di ripristino di emergenza e non possono avere carichi di lavoro di lettura attivi. Gli unici carichi di lavoro accettabili sono per il monitoraggio, la manutenzione, ad esempio l'esecuzione di DMV (Dynamic Management Views) e CheckDB.

  • È possibile aggiornare la replica secondaria leggibile esistente a una replica standby per risparmiare sui costi?

    Sì, nel portale di Azure, nel riquadro Repliche. Selezionare i puntini di sospensione (...) e quindi selezionare l'opzione Converti la replica.

  • È possibile abilitare il Vantaggio Azure Hybrid per la replica di standby?

    La progettazione di una replica per standby sostituisce lo sconto del Vantaggio Azure Hybrid, quindi non è possibile modificare il modello di licenza per la replica usando il portale di Azure. Tuttavia, se si vuole che la replica standby usi il Vantaggio Azure Hybrid al failover, è possibile usare il comando PowerShell Set-AzSqlDatabase o az sql db update dell'interfaccia della riga di comando di Azure per aggiornare il tipo di licenza a BasePrice (Vantaggio Azure Hybrid) affinché la replica standby venga usata quando la replica di standby diventa primaria dopo il failover.

  • Cosa accade allo stato della replica di standby durante il failover?

    Durante il failover pianificato o non pianificato, la replica di standby diventa la nuova replica primaria che comporta costi di licenza regolari, mentre il database primario originale diventa il nuovo database secondario di standby e smette di sostenere i costi delle licenze vCore. Tuttavia, poiché l'istanza viene fatturata per l'intera ora, è comunque possibile che vengano addebitati costi di licenza per il nuovo database secondario per l'intera ora se la modifica dello stato avviene nella metà dell'ora. Se il database primario originale (che diventa standby dopo il failover) usava il Vantaggio Azure Hybrid, lo sconto sulle licenze standby sostituisce il Vantaggio Azure Hybrid usato dal database.

  • Cosa accade se si aumenta la dimensione primaria o secondaria a una dimensione vCore superiore?

    Quando si aumentano le prestazioni, è consigliabile aumentare prima le prestazioni del database secondario e quindi il database primario. Anche se la replica secondaria avrà un numero di vCore maggiore rispetto a quello primario durante il periodo di transizione, i vantaggi della replica di standby sono ancora validi. Provare a ridurre il periodo di transizione il più possibile.

  • Cosa accade se si riduce la dimensione primaria o secondaria a una dimensione vCore inferiore?

    Quando si aumenta il numero di istanze, è consigliabile ridurre prima il livello primario e quindi il database secondario. Anche se la replica secondaria avrà un numero di vCore maggiore rispetto a quello primario durante il periodo di transizione, i vantaggi della replica di standby sono ancora validi. Provare a ridurre il periodo di transizione il più possibile.

  • Cosa accade se si rimuove la relazione di replica geografica tra la replica primaria e quella di standby?

    Dopo la rimozione della replica geografica, il database di standby diventa un database autonomo normale e inizia a sostenere i costi di licenza.

  • È possibile ottenere vantaggi per la capacità riservata per la replica di standby?

    Sì. I prezzi della capacità riservata sono completamente compatibili con la replica di standby.

Contenuto correlato