Condividi tramite

Replica geografica attiva

  • Articolo

Si applica a: Database SQL di Azure

Questo articolo offre informazioni generali sulla funzionalità di replica geografica attiva per database SQL di Azure, che consente di replicare continuamente i dati da un database primario a un database secondario leggibile. Il database secondario leggibile potrebbe trovarsi nella stessa area di Azure del database primario o, più comunemente, in un'area diversa. Questo tipo di database secondario leggibile è noto anche come replica geografica secondaria o geografica.

La georeplicazione attiva è configurata per ogni database. Per eseguire il failover di un gruppo di database o se l'applicazione richiede un endpoint di connessione stabile, prendere in considerazione i gruppi di failover .

È anche possibile eseguire la migrazione del database SQL con la replica geografica attiva.

Panoramica

La replica geografica attiva è progettata come soluzione di continuità aziendale. Consente di eseguire rapidamente il ripristino di emergenza dei singoli database in caso di emergenza a livello di area o di interruzione su larga scala. Dopo aver configurato la replica geografica, è possibile avviare un failover geografico in un'area geografica secondaria in un'area di Azure diversa. Il failover geografico deve essere avviato in modo programmatico dall'applicazione oppure manualmente dall'utente.

Il seguente diagramma illustra una configurazione tipica di un'applicazione cloud con ridondanza geografica tramite la replica geografica attiva.

Diagramma della replica geografica attiva.

Se per qualsiasi motivo il database primario restituisce un errore, è possibile avviare il failover in uno dei database secondari. Quando un database secondario viene promosso a primario, tutti gli altri database secondari vengono automaticamente collegati al nuovo database primario.

È possibile gestire la replica geografica e avviare un failover geografico usando uno dei seguenti metodi:

La replica geografica attiva sfrutta la tecnologia del gruppo di disponibilità Always On per replicare in modo asincrono i log delle transazioni generati nella replica primaria in tutte le repliche geografiche. Anche se a un certo punto i dati del database secondario possono essere leggermente indietro rispetto al database primario, viene comunque garantita la coerenza transazionale per i dati nel database secondario. In altre parole, le modifiche apportate dalle transazioni di cui non è stato eseguito il commit non sono visibili.

Nota

La replica geografica attiva riproduce le modifiche tramite lo streaming del log delle transazioni del database dalla replica primaria alle repliche secondarie. Non è correlato alla replica transazionale, che riproduce le modifiche eseguendo comandi DML (IN edizione Standard RT, UPDATE, DELETE) nei sottoscrittori.

La replica geografica offre ridondanza a livello di area. La ridondanza delle aree consente il ripristino rapido delle applicazioni dalla perdita definitiva di un'intera area di Azure o di parti di essa causata da calamità naturali, errori umani irreversibili o atti dolosi. La replica geografica RPO è disponibile in Panoramica della continuità aziendale con database SQL di Azure.

La figura seguente illustra un esempio di replica geografica attiva configurata con il database primario nell'area Stati Uniti occidentali 2 e il database geografico secondario nell'area Stati Uniti orientali.

Screenshot del portale Azure che mostra una relazione di georeplicazione del database SQL.

Oltre al ripristino di emergenza, la replica geografica attiva può essere usata negli scenari seguenti:

  • Migrazione di un database: è possibile usare la replica geografica attiva per eseguire la migrazione di un database da un server a un altro con un tempo di inattività minimo.
  • Aggiornamenti dell'applicazione: durante gli aggiornamenti dell'applicazione è possibile creare un database secondario aggiuntivo come copia di failback.

Per ottenere una continuità aziendale completa, l'aggiunta di ridondanza dei database a livello di area rappresenta solo una parte della soluzione. Per ripristinare un'applicazione (servizio) end-to-end dopo un problema grave, è necessario effettuare il ripristino di tutti i componenti del servizio e gli eventuali servizi dipendenti. Esempi di questi componenti includono il software client (ad esempio, un browser con JavaScript personalizzato), front-end Web, spazio di archiviazione e DNS. È di importanza cruciale che tutti i componenti siano resilienti agli stessi problemi e diventino disponibili entro l'obiettivo del tempo di ripristino (RTO) dell'applicazione. È perciò necessario identificare tutti i servizi dipendenti e comprendere quali garanzie e funzionalità vengono fornite. È quindi necessario intraprendere le azioni appropriate per assicurare il funzionamento del servizio durante il failover dei servizi da cui dipende. Per altre informazioni sulla progettazione di soluzioni per il ripristino di emergenza, vedere Progettazione di servizi disponibili a livello globale tramite database SQL di Azure.

Terminologia e capacità

  • Replica asincrona automatica

    È possibile creare un database geografico secondario solo aggiungendolo a un database esistente. Il database geografico secondario può essere creato in qualsiasi server logico diverso dal server con il database primario. Dopo averlo creata, la replica geografica secondaria viene popolata con i dati copiati dal database primario. Questo processo è noto come seeding. Dopo aver creato ed eseguito il seeding del database geografico secondario, gli aggiornamenti al database primario vengono replicati automaticamente in modo asincrono nella replica geografica secondaria. Replica asincrona significa che le transazioni vengono sottoposte a commit nel database primario prima di essere replicate.

  • Repliche geografiche secondarie leggibili

    Un'applicazione può accedere a una replica geografica secondaria per eseguire query di sola lettura usando le stesse entità di sicurezza usate per l'accesso al database primario. Per maggiori informazioni, vedere Usare le repliche di sola lettura per l'offload dei carichi di lavoro di query di sola lettura.

    Importante

    È possibile usare la replica geografica per creare repliche secondarie nella stessa area del database primario. È possibile usare questi database secondari per soddisfare scenari di scalabilità orizzontale in lettura nella stessa area. Tuttavia, una replica secondaria nella stessa area non offre resilienza aggiuntiva a errori irreversibili o interruzioni su larga scala, pertanto non è una destinazione di failover adatta per scopi di ripristino di emergenza. Non garantisce inoltre l'isolamento della zona di disponibilità. Usare la configurazione con ridondanza della zona per i livelli di servizio business critical o premium oppure la configurazione con ridondanza della zona per il livello di servizio di utilizzo generico per ottenere l'isolamento della zona di disponibilità.

  • Failover (nessuna perdita di dati)

    Il failover cambia i ruoli dei database primari e secondari geografici dopo aver completato la sincronizzazione completa dei dati affinché non si verifichi alcuna perdita di dati. La durata del failover dipende dalle dimensioni del log delle transazioni nel database primario, che deve essere sincronizzato con la replica geografica secondaria. Il failover è progettato per i seguenti scenari:

    • Eseguire esercitazioni per il ripristino di emergenza in produzione quando la perdita di dati non è accettabile
    • Rilocare i database in un'area diversa
    • Ripristinare i database nell'area primaria dopo la risoluzione dell'interruzione (failback).

  • Potenziale perdita di dati dopo il failover forzato

    Con il failover forzato il database geografico secondario passa immediatamente al ruolo primario senza alcuna sincronizzazione. Le transazioni di cui è stato eseguito il commit al database primario, ma che non sono state ancora replicate nel database secondario, vengono perse. L'operazione è progettata come metodo di ripristino durante le interruzioni quando il database primario non è accessibile, ma la disponibilità del database deve essere ripristinata rapidamente. Quando il database primario originale è di nuovo online, viene riconnesso automaticamente, inviato di nuovo usando i dati correnti dal database primario e diventa il nuovo database geografico secondario.

    Importante

    Dopo il failover o il failover forzato, l'endpoint di connessione per il nuovo database primario cambia perché il nuovo database primario si trova ora in un server logico diverso.

  • Più database geografici secondari leggibili

    È possibile creare fino a quattro repliche secondarie geografiche per un database primario. Se è presente un solo database secondario e si verifica un errore, l'applicazione rimane esposta a maggiori rischi finché non viene creato un nuovo database secondario. Se sono presenti più database secondari, l'applicazione rimane protetta, anche se uno dei database secondari smette di funzionare. I database secondari aggiuntivi possono anche essere usati per aumentare il numero di istanze per i carichi di lavoro di sola lettura.

    Suggerimento

    Se si usa la replica geografica attiva per compilare un'applicazione distribuita a livello globale ed è necessario fornire l'accesso in sola lettura ai dati in più di quattro aree, è possibile creare il database secondario di un database secondario per creare repliche geografiche aggiuntive. Questo processo è noto come concatenamento. Il ritardo di replica nelle repliche geografiche concatenate potrebbe essere superiore a quello delle repliche geografiche connesse direttamente al database primario. La configurazione di topologie con repliche geografiche concatenate sono supportate a livello di codice e non dal portale di Azure.

  • Replica geografica di database in un pool elastico

    Ciascun database geografico secondario può essere un database singolo o un database in un pool elastico. La scelta del pool per ogni database geografico secondario è separata e non dipende dalla configurazione di alcuna altra replica nella topologia (primaria e secondaria). Ogni pool elastico è contenuto all'interno di un singolo server logico. Poiché i nomi di database in un server logico devono essere univoci, più database secondari geografici dello stesso database primario non possono mai condividere un pool elastico.

  • Failover geografico e failback controllati dall'utente

    Al termine dell'inserimento iniziale, un database geografico secondario può essere impostato esplicitamente sul ruolo di database primario (failover) in qualsiasi momento dall'applicazione o dall'utente. Durante un'interruzione in cui il database primario è inaccessibile, è possibile usare solo il failover forzato, che promuove immediatamente un database geografico secondario a nuovo database primario. Quando l'interruzione è attenuata, il sistema rende automaticamente il database primario ripristinato un database geografico secondario e lo aggiorna con il nuovo database primario. A causa della natura asincrona della replica geografica, le transazioni recenti potrebbero andare perse durante i failover forzati qualora il database primario abbia esito negativo prima che queste transazioni vengano replicate in un database geografico secondario. Quando un database primario con più database geografici secondari esegue il failover, il sistema riconfigura automaticamente le relazioni di replica e collega i database geografici secondari rimanenti al nuovo database primario appena alzato di livello senza alcun intervento da parte dell'utente. Dopo aver risolto l'interruzione del servizio che ha causato il failover, è opportuno ripristinare il database nell'area originale. Per farlo, eseguire un failover manuale.

  • Replica standby

    Se la replica secondaria viene usata solo per il ripristino di emergenza e non dispone di carichi di lavoro di lettura o scrittura, è possibile designare la replica per lo standby per risparmiare sui costi di licenza.

Preparare il failover geografico

Per assicurarsi che l'applicazione possa accedere immediatamente al nuovo database primario dopo il failover geografico, verificare che l'autenticazione e l'accesso alla rete per il server secondario siano configurati correttamente. Per altre informazioni, vedere Configurare e gestire la sicurezza dei database SQL di Azure per il ripristino geografico o il failover. Verificare anche che i criteri di conservazione dei backup nel database secondario corrispondano a quello del database primario. L'impostazione non fa parte del database e non viene replicata dal database primario. Per impostazione predefinita, la replica geografica secondaria è configurata con un periodo di conservazione predefinito di sette giorni. Per altre informazioni, vedere Backup automatici nel database SQL di Azure.

Importante

Se il database è membro di un gruppo di failover, non è possibile avviarne il failover con il comando di failover di replica geografica. Usare il comando di failover per il gruppo. Se è necessario eseguire il failover di un singolo database, occorre rimuoverlo prima dal gruppo di failover. Per informazioni dettagliate, vedere Gruppi di failover.

Configurare il database geografico secondario

I database primari e geografici secondari devono avere lo stesso livello di servizio. È anche consigliabile configurare il database secondario geografico con la stessa ridondanza di archiviazione di backup, livello di calcolo (provisioning o serverless) e dimensioni di calcolo (DTU o vCore) di quello primario. Se il database primario riscontra un carico di lavoro a elevato utilizzo di scrittura, è possibile che un database secondario geografico con dimensioni di calcolo inferiori non riesca a restare al passo. Ciò causa il ritardo della replica nel database geografico secondario e potrebbe causarne l'indisponibilità. Per attenuare questi rischi, la replica geografica attiva riduce (limita) la frequenza del log delle transazioni del database primario, se necessario, per consentire ai database secondari di stare al passo con le modifiche.

Un'altra conseguenza di una configurazione geografica secondaria sbilanciata è che, dopo il failover, le prestazioni dell'applicazione possono ridursi a causa di una capacità di calcolo insufficiente del nuovo database primario. In tal caso, è necessario aumentare le prestazioni del database per avere risorse sufficienti, che potrebbero richiedere tempo significativo e un failover a disponibilità elevata alla fine del processo di aumento delle prestazioni, che può interrompere i carichi di lavoro dell'applicazione.

Se si decide di creare il database geografico secondario con una configurazione diversa, sarà necessario monitorare nel tempo la velocità di I/O dei log nel database primario. In questo modo sarà possibile stimare le dimensioni minime necessarie per supportare il carico di replica. Ad esempio, se il database primario è P6 (1000 DTU) e la percentuale IO del log è del 50%, il database geografico secondario deve essere almeno P4 (500 DTU). Per recuperare i dati di I/O dei log cronologici, usare la visualizzazione sys.resource_stats. Per recuperare i dati di I/O di log recenti con una granularità più elevata che riflette meglio i picchi a breve termine, usare la visualizzazione sys.dm_db_resource_stats.

Suggerimento

La limitazione delle operazioni di I/O del log delle transazioni può verificarsi:

  • Se l’area geografica secondaria ha una dimensione di calcolo inferiore rispetto a quella primaria. Cercare il tipo di attesa HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO nelle viste di database sys.dm_exec_requests e sys.dm_os_wait_stats.
  • Motivi non correlati alle dimensioni di calcolo. Per informazioni dettagliate, inclusi i tipi di attesa per diversi tipi di limitazione delle operazioni di I/O dei log, consultare Governance della frequenza dei log delle transazioni.

Per impostazione predefinita, la ridondanza dell'archivio di backup del database geografico secondario è la stessa del database primario. È possibile scegliere di configurare un database geografico secondario con una ridondanza dell'archiviazione di backup diversa. I backup vengono eseguiti sempre nel database primario. Se il database secondario è configurato con una ridondanza dell'archiviazione di backup diversa, dopo un failover geografico, quando il database geografico secondario viene alzato di livello al database primario, i nuovi backup vengono archiviati e fatturati in base al tipo di archiviazione (RA-GRS, ZRS, LRS) selezionato nel nuovo database primario (secondario precedente).

Risparmiare sui costi con la replica standby

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.

Replica geografica tra sottoscrizioni

  • È possibile usare il portale di Azure per configurare la replica geografica attiva tra sottoscrizioni, purché entrambe le sottoscrizioni si trovino nello stesso tenant di Microsoft Entra.

  • La creazione di una sottoscrizione geografica secondaria tra sottoscrizioni su un server logico nello stesso tenant Microsoft Entra o in un tenant diverso non è supportata quando è abilitata l'autenticazione basata soltanto su Microsoft Entra sul server logico primario o secondario e la creazione viene tentata utilizzando un utente Microsoft Entra ID.

Per i metodi e le istruzioni dettagliate, vedere Esercitazione: configurare la replica geografica attiva e il failover (database SQL di Azure).

Endpoint privati

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.

Mantenere sincronizzate le credenziali e le regole del firewall

Quando si usa l'accesso alla rete pubblica per la connessione al database, si consiglia di usare le regole del firewall IP a livello di database per i database con replica geografica. Queste regole vengono replicate con il database, il che garantisce che tutti i database secondari con replica geografica abbiano le stesse regole del firewall IP del database primario. Questo approccio consente di evitare la configurazione e la gestione di regole del firewall manualmente nei server che ospitano sia il database primario che i secondari. L'uso di utenti di database indipendenti garantisce che i database primari e secondari abbiano le stesse credenziali di autenticazione. In questo modo, dopo un failover geografico, non si verificano interruzioni dovute alla mancata corrispondenza delle credenziali di autenticazione. Se si usano account di accesso e utenti tradizionali, invece di utenti indipendenti, è necessario eseguire altri passaggi per assicurare che nel database secondario siano presenti gli stessi account di accesso. Per i dettagli di configurazione, vedere Configurare e gestire la sicurezza dei database SQL di Azure per il ripristino geografico o il failover.

Ridimensionare il database primario

È possibile ridimensionare un database primario a dimensioni di calcolo diverse (entro lo stesso livello di servizio) senza disconnettere eventuali database secondari. 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.

Per informazioni sui gruppi di failover, vedere Ridimensionare una replica in un gruppo di failover.

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 sul primario al momento della chiamata.

Monitorare il ritardo della replica geografica

Per monitorare il ritardo rispetto all’obiettivo del tempo di ripristino (RPO), usare la colonna replication_lag_sec di sys.dm_geo_replication_link_status nel database primario. Mostra il ritardo in secondi tra le transazioni di cui è stato eseguito il commit nel database primario e quelle finalizzate nel log delle transazioni nel database secondario. Ad esempio, se il ritardo è di un secondo, significa che se il database primario è interessato da un'interruzione in questo momento e viene avviato un failover geografico, le transazioni di cui è stato eseguito il commit nell'ultimo secondo andranno perse.

Per misurare il ritardo rispetto alle modifiche apportate al database primario che sono state finalizzate nella replica geografica secondaria, confrontare l'ora di last_commit nel database geografico secondario con lo stesso valore nel database primario.

Suggerimento

Se replication_lag_sec nel database primario è NULL, significa che il database primario attualmente non conosce la distanza di un database geografico secondario. Ciò si verifica in genere dopo il riavvio del processo e dovrebbe essere una condizione temporanea. Prendere in considerazione l’invio di un avviso se replication_lag_sec restituisce NULL per un periodo di tempo prolungato. Potrebbe indicare che il database geografico secondario non può comunicare con il database primario a causa di un errore di connettività.

Esistono anche condizioni che potrebbero causare la differenza tra il tempo last_commit sulla replica geografica secondaria e sul database primario per diventare di grandi dimensioni. Se ad esempio un commit viene eseguito sul database primario dopo un lungo periodo di assenza di modifiche, la differenza passerà a un valore elevato prima di tornare rapidamente a zero. Valutare la possibilità di inviare un avviso se la differenza tra questi due valori resta elevata per molto tempo.

Gestione a livello di codice della replica geografica attiva

La replica geografica attiva può essere gestita a livello di codice usando T-SQL, Azure PowerShell e l'API REST. Le tabelle seguenti descrivono il set di comandi disponibili. La replica geografica attiva include 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 supportano il controllo degli accessi in base al ruolo di Azure. Per ulteriori informazioni su come implementare i ruoli di accesso, vedere Controllo degli accessi in base al ruolo di Azure (Azure RBAC).

Importante

Questi comandi T-SQL si applicano solo alla replica geografica attiva e non ai gruppi di failover.

Comando Descrizione
ALTER DATABASE Usare l'argomento ADD SECONDARY ON SERVER per creare un database secondario per un database esistente e avviare la replica dei dati
ALTER DATABASE Usare FAILOVER o FORCE_FAILOVER_ALLOW_DATA_LOSS per passare un database secondario al ruolo di database primario per avviare il failover
ALTER DATABASE Usare REMOVE SECONDARY ON SERVER per terminare la replica dei dati tra un database SQL e il database secondario specificato.
sys.geo_replication_links Restituisce informazioni su tutti i collegamenti di replica esistenti per ogni database in un server.
sys.dm_geo_replication_link_status Ottiene l'ultima ora di replica, l'ultimo intervallo di replica e altre informazioni sul collegamento di replica per un database specificato.
sys.dm_operation_status Mostra lo stato per tutte le operazioni di database, incluso lo stato dei collegamenti di replica.
sys.sp_wait_for_database_copy_sync Fa sì che l'applicazione attenda che tutte le transazioni di cui è stato eseguito il commit vengano sottoposte a protezione avanzata nel log delle transazioni di un database geografico secondario.

Contenuto correlato

Configurare la replica geografica attiva:

Altri contenuti di continuità aziendale: