Replica geografica attiva

Si applica a:database SQL di Azure

La replica geografica attiva è una funzionalità che consente di creare un database secondario continuamente sincronizzato e leggibile per un database primario. 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 replica geografica attiva è configurata per ogni database e supporta solo il failover manuale. 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 usare Esegui 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.

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:

• Il portale di Azure
• PowerShell: database singolo
• PowerShell: pool elastico
• Transact-SQL: database singolo o pool elastico
• API REST: database singolo

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.

La figura seguente illustra un esempio di replica geografica attiva configurata con il database primario nell’area Stati Uniti centro-settentrionali e il database geografico secondario nell’area Stati Uniti centro-meridionali.

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 I’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 applicazioni per il ripristino di emergenza cloud con la replica geografica attiva in database SQL.

Funzionalità e terminologia della replica geografica attiva

• 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 tutti i dettagli, vedere l'articolo sulla sicurezza del database SQL di Azure dopo il ripristino di emergenza. 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 conoscere i dettagli, vedere Backup automatici del database SQL.

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 sul database primario dovuta a dimensioni di calcolo inferiori in un database secondario a livello geografico viene segnalata usando il tipo di attesa HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO, visibile nelle visualizzazioni di database sys.dm_exec_requests e sys.dm_os_wait_stats.

L’I/O del log delle transazioni nel database primario potrebbe essere limitato per motivi non correlati a dimensioni di calcolo inferiori in un database geografico secondario. Questo tipo di limitazione può verificarsi anche quando la replica geografica secondaria ha le stesse dimensioni di calcolo o superiori rispetto alla replica primaria. 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’archiavio 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

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. Per altre informazioni, consultare Configurare la replica geografica attiva.

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 informazioni dettagliate sulla configurazione, consultare Come configurare account di accesso e utenti.

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.

Nota

Se è stato creato un database secondario con replica geografica come parte della configurazione del gruppo di failover, non è consigliabile ridurne le prestazioni. Ciò garantisce che il livello dati disponga della capacità sufficiente per elaborare il carico di lavoro normale dopo un failover geografico.

Importante

Il database primario in un gruppo di failover non può essere ridimensionato a un livello di servizio superiore (edizione), a meno che il database secondario non venga prima ridimensionato al livello superiore. Ad esempio, se si vuole aumentare le prestazioni del database primario da Utilizzo generico a Business Critical, è necessario prima ridimensionare la replica geografica secondaria portandola a Business Critical. Se si tenta di ridimensionare il database primario o quello geografico secondario in modo da violare questa regola, verrà visualizzato l’errore seguente:

The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

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

Come indicato in precedenza, 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).

T-SQL: gestire il failover geografico di database singoli e in pool

Importante

Questi comandi T-SQL si applicano solo alla replica geografica attiva e non ai gruppi di failover. Di conseguenza potrebbero anche non applicarsi a Istanza gestita di SQL, perché supportano solo i 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.

PowerShell: gestire il failover geografico di database singoli e in pool

Nota

Questo articolo usa il modulo Azure Az PowerShell, che è il modulo di PowerShell consigliato per l'interazione con Azure. Per iniziare a usare il modulo Az PowerShell, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Importante

Il modulo Azure Resource Manager di PowerShell è ancora supportato da Database SQL di Azure, ma tutte le attività di sviluppo future sono incentrate sul modulo Az.Sql. Per informazioni su questi cmdlet, vedere AzureRM.Sql. Gli argomenti per i comandi nei moduli Az e AzureRm sono sostanzialmente identici.

Cmdlet	Descrizione
Get-AzSqlDatabase	Ottiene uno o più database.
New-AzSqlDatabaseSecondary	Crea un database secondario per un database esistente e avvia la replica dei dati.
Set-AzSqlDatabaseSecondary	Consente di passare un database secondario al ruolo di database primario per avviare il failover.
Remove-AzSqlDatabaseSecondary	Termina la replica dei dati tra un database SQL e il database secondario specificato.
Get-AzSqlDatabaseReplicationLink	Ottiene i collegamenti di replica geografica per un database.

Suggerimento

Per script di esempio, vedere Configurare un database singolo ed eseguirne il failover usando la replica geografica attiva e Configurare un database in pool ed eseguirne il failover usando la replica geografica attiva.

API REST: gestire il failover geografico di database singoli e in pool

API	Descrizione
Creare o aggiornare database (createMode=Restore)	Crea, aggiorna o ripristina un database primario o secondario.
Get Create or Update Database Status	Restituisce lo stato durante un’operazione di creazione.
Impostazione del database secondario come primario (failover pianificato)	Stabilisce quale database secondario deve essere primario eseguendo il failover dal database primario corrente. Questa opzione non è supportata per Istanza gestita di SQL.
Set Secondary Database as Primary (Unplanned Failover)	Stabilisce quale database secondario deve essere primario eseguendo il failover dal database primario corrente. Questa operazione potrebbe comportare la perdita di dati. Questa opzione non è supportata per Istanza gestita di SQL.
Get Replication Link	Ottiene un collegamento di replica specifico per un determinato database in una relazione di replica geografica. Recupera le informazioni visibili nella vista del catalogo sys.geo_replication_links. Questa opzione non è supportata per Istanza gestita di SQL.
Replication Links - List By Database	Ottiene tutti i collegamenti di replica per un determinato database in una relazione di replica geografica. Recupera le informazioni visibili nella vista del catalogo sys.geo_replication_links.
Delete Replication Link	Elimina un collegamento alla replica del database. Non può essere eseguito durante il failover.

Passaggi successivi

• Per script di esempio, vedere:
  • Configurare un database singolo ed eseguirne il failover usando la replica geografica attiva.
  • Configurare un database in pool ed eseguirne il failover usando la replica geografica attiva.
• Il database SQL supporta anche i gruppi di failover. Per altre informazioni, vedere l’uso dei gruppi di failover automatico.
• 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.
• Per informazioni sulla replica geografica Hyperscale del database SQL di Azure, vedere Replica geografica Hyperscale
• Per informazioni sui backup automatici del database SQL di Azure, vedere Backup automatici del database SQL.
• Per altre informazioni sull'uso dei backup automatici per il ripristino, vedere l'articolo relativo al ripristino di un database dai backup avviati dal servizio.
• Per ulteriori informazioni sui requisiti di autenticazione per un nuovo database e server primario, vedere l'articolo sulla sicurezza del database SQL di Azure dopo il ripristino di emergenza.