Condividi tramite

Repliche secondarie Hyperscale

  • Articolo

Si applica a:database SQL di Azure

Come descritto in Architettura con funzioni distribuite, Hyperscale del database SQL di Azure ha due diversi tipi di nodi di calcolo, detti anche repliche:

Le repliche secondarie sono sempre di sola lettura e possono essere di tre tipi diversi:

  • Replica a disponibilità elevata
  • Replica geografica
  • Replica denominata

Ogni tipo ha un'architettura, un insieme di funzionalità, uno scopo e un costo diversi. In base alle caratteristiche necessarie, è possibile usarne solo una o tutte e tre insieme. Le repliche secondarie sono supportate sia dai livelli di calcolo serverless che da quello con provisioning.

Per le esercitazioni sulla configurazione e la gestione di repliche denominate Hyperscale, vedere:

Replica a disponibilità elevata

Una replica a disponibilità elevata usa gli stessi server di pagina della replica primaria, quindi non è necessaria alcuna copia dei dati per aggiungerla. Le repliche a disponibilità elevata vengono usate principalmente per aumentare la disponibilità del database e agiscono come hot standby a scopo di failover. Se la replica primaria non è più disponibile, il failover in una delle repliche di disponibilità elevata esistenti è automatico e rapido. La stringa di connessione non deve cambiare; durante le applicazioni di failover può verificarsi un tempo inattivo minimo a causa dell'eliminazione delle connessioni attive. Come di consueto per questo scenario, è consigliabile usare una logica di ripetizione dei tentativi appropriata. Diversi driver forniscono già un certo grado di logica di ripetizione automatica dei tentativi. Se usi .NET, la libreria Microsoft.Data.SqlClient più recente offre il supporto completo nativo per la logica di ripetizione automatica configurabile.

Le repliche di disponibilità elevata usano lo stesso server e lo stesso nome del database della replica primaria. L'obiettivo del livello di servizio è sempre uguale a quello della replica primaria. Le repliche di disponibilità elevata non sono visibili o gestibili come risorsa autonoma dal portale o da qualsiasi API.

Possono essere presenti da zero a quattro repliche di disponibilità elevata. Il numero può essere modificato durante la creazione di un database o dopo la creazione del database tramite gli endpoint e gli strumenti di gestione comuni (ad esempio PowerShell, CLI di Azure, portale, API REST). La creazione o la rimozione di repliche di disponibilità elevata non influisce sulle connessioni attive nella replica primaria.

Connessione a una replica a disponibilità elevata

Nei database Hyperscale, l'argomento ApplicationIntent nella stringa di connessione usata dal client indica se la connessione viene instradata alla replica primaria in lettura/scrittura o a una replica di sola lettura di disponibilità elevata. Se ApplicationIntent è impostato su ReadOnly e il database non ha una replica secondaria, la connessione viene indirizzata alla replica primaria con il comportamento predefinito ReadWrite.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Tutte le repliche di disponibilità elevata sono identiche nella capacità delle risorse. Se sono presenti più repliche di disponibilità elevata, il carico di lavoro con finalità di lettura viene distribuito in modo arbitrario in tutte le repliche di disponibilità elevata disponibili. Quando sono presenti più repliche di disponibilità elevata, tieni presente che ognuna potrebbe avere una latenza dei dati diversa rispetto alle modifiche apportate ai dati nel database primario. Ogni replica a disponibilità elevata usa gli stessi dati del database primario nello stesso insieme di server di pagine. Tuttavia, le cache dei dati locali in ogni replica a disponibilità elevata riflettono le modifiche apportate al database primario tramite il servizio di log delle transazioni, che inoltra i record di log dalla replica primaria alle repliche a disponibilità elevata. Di conseguenza, a seconda del carico di lavoro elaborato da una replica a disponibilità elevata, l'applicazione dei record di log può verificarsi a velocità diverse e pertanto diverse repliche potrebbero avere una latenza dei dati diversa rispetto alla replica primaria.

Replica denominata

Una replica denominata, proprio come una replica a disponibilità elevata, usa gli stessi server di pagina della replica primaria. Analogamente alle repliche a disponibilità elevata, non è necessaria alcuna copia dei dati per aggiungere una replica denominata.

Esistono delle differenze tra le repliche a disponibilità elevata e le repliche denominate:

  • Le repliche denominate vengono visualizzate come normali (di sola lettura) database SQL di Azure nel portale e nelle chiamate API (CLI di Azure, PowerShell, T-SQL).
  • Le repliche denominate possono avere un nome di database diverso dalla replica primaria e, facoltativamente, si trovano in un server logico diverso, purché sia nella stessa area della replica primaria.
  • Le repliche denominate hanno un proprio obiettivo del livello di servizio che può essere impostato e modificato in modo indipendente dalla replica primaria.
  • Le repliche denominate supportano fino a 30 repliche denominate (per ogni replica primaria).
  • Le repliche denominate supportano l'autenticazione diversa per ogni replica denominata creando account di accesso diversi nei server logici che ospitano repliche denominate.

Di conseguenza, le repliche denominate offrono diversi vantaggi rispetto a quelle a disponibilità elevata per quanto riguarda i carichi di lavoro di sola lettura:

  • Gli utenti connessi a una replica denominata non subiranno alcuna disconnessione se la replica primaria verrà dimensionata verso l'alto o verso il basso; allo stesso tempo, gli utenti connessi alla replica primaria non saranno interessati da repliche denominate che aumentano o si riducono.
  • I carichi di lavoro in esecuzione in qualsiasi replica, primaria o denominata, non saranno interessati da query in esecuzione prolungata su in altre repliche.

L'obiettivo principale delle repliche denominate è consentire un'ampia gamma di scenari di scalabilità in lettura e migliorare i carichi di lavoro HTAP (Hybrid Transactional and Analytical Processing). Di seguito sono riportati alcuni esempi di come creare tali soluzioni:

Oltre agli scenari principali elencati in precedenza, le repliche denominate offrono flessibilità ed elasticità per soddisfare anche molti altri casi d'uso:

  • Isolamento dell'accesso: è possibile concedere l'accesso a una replica denominata specifica, ma non alla replica primaria o ad altre repliche denominate.
  • Obiettivo del livello di servizio dipendente dal carico di lavoro: dato che una replica denominata può avere un proprio obiettivo a livello di servizio, è possibile usare repliche denominate diverse per carichi di lavoro e casi d'uso diversi. Ad esempio, è possibile usare una replica denominata per gestire le richieste di Power BI e un'altra per gestire i dati ad Apache Spark per le attività di data science. Ognuna può avere un obiettivo del livello di servizio indipendente e dimensionarsi in modo indipendente.
  • Pianificazione percorso dipendente dal carico di lavoro: con un massimo di 30 repliche denominate, è possibile usare repliche denominate in gruppi per poter isolare un'applicazione da un'altra. Ad esempio, è possibile usare un gruppo di quattro repliche denominate per gestire le richieste provenienti da applicazioni per dispositivi mobili, mentre è possibile usare un altro gruppo di due repliche denominate per gestire le richieste provenienti da un'applicazione Web. Questo approccio consente un'ottimizzazione granulare delle prestazioni e dei costi per ogni gruppo.

Nota

Per domande frequenti sulle repliche denominate di Hyperscale, vedi Domande frequenti sulle repliche denominate di Hyperscale per il database SQL di Azure.

Ridondanza della zona per le repliche denominate Hyperscale

La ridondanza della zona per le repliche denominate Hyperscale del database SQL di Azure usa zone di disponibilità Azure per distribuire nodi di calcolo di repliche denominate in posizioni fisiche diverse all'interno di un'area di Azure. Scegliendo la ridondanza della zona per le repliche denominate, è possibile migliorare la resilienza di tutti i livelli dei database Hyperscale rispetto a un'ampia gamma di errori, incluse le interruzioni del data center, senza alcuna modifica della logica dell'applicazione. Per altre informazioni, vedere Disponibilità con ridondanza della zona Hyperscale.

Per un'esercitazione sulla creazione di una replica denominata Hyperscale con ridondanza della zona, vedere Creare una replica denominata Hyperscale.

Per la risoluzione dei problemi e il test della resilienza degli errori dell'applicazione, vedere Testare la resilienza degli errori dell'applicazione.

Replica geografica

Con la replica geografica attiva, è possibile creare una replica secondaria leggibile del database Hyperscale primario nella stessa area o in un'area di Azure diversa. Le repliche geografiche devono essere create in un server logico diverso. Il nome del database di una replica geografica corrisponde sempre al nome del database primario.

Quando si crea una replica geografica, tutti i dati vengono copiati dal server primario a un set diverso di server di pagine. Una replica geografica non condivide i server di pagine con il server primario, anche se si trovano nella stessa area. Questa architettura fornisce la ridondanza necessaria per i failover geografici.

Le repliche geografiche vengono usate per mantenere una copia coerente in modo transazionale del database tramite la replica asincrona. Se si trova in un'area di Azure diversa, una replica geografica può essere usata per il ripristino di emergenza in caso di problemi o interruzioni nell'area primaria. Le repliche geografiche possono essere usate anche per scenari di scalabilità in lettura geografica. A partire da ottobre 2022, è supportata la copia del database da una replica geografica secondaria di Hyperscale.

La replica geografica per il database Hyperscale presenta le seguenti limitazioni correnti:

  • Può essere creata una sola replica geografica (nella stessa area o in una diversa).
  • Il ripristino temporizzato della replica geografica non è supportato.
  • La creazione di una replica geografica di una replica geografica (nota anche come "concatenamento di repliche geografiche") non è supportata.

Risoluzione dei problemi

Risolvere i problemi relativi alle repliche denominate Hyperscale con ridondanza della zona

  • Per la risoluzione dei problemi e il test della resilienza degli errori dell'applicazione, vedere Testare la resilienza degli errori dell'applicazione.

  • Assicurarsi che sia specificata almeno una replica a disponibilità elevata durante la creazione di una replica denominata con ridondanza della zona in PowerShell e nella CLI. Per un esempio, vedere Creare una replica denominata Hyperscale.

    • Nell'interfaccia della riga di comando di Azure è necessario specificare sia i parametri "ha-replicas" che "redundant".
    • In PowerShell è necessario specificare il parametro "HighAvailabilityReplicaCount" e "ZoneRedundant".
    • Se viene omessa, viene visualizzato il messaggio di errore (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database..

  • Per abilitare questa funzionalità per le repliche denominate, il database Hyperscale deve avere la ridondanza della zona già abilitata come prerequisito.

    • È facoltativo abilitare la ridondanza della zona per le repliche denominate, anche se il database primario ha la ridondanza della zona abilitata.
    • Se non è abilitata, viene visualizzato il messaggio di errore (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant..

Problemi noti

Dati parzialmente errati restituiti da sys.databases

I valori di riga restituiti da sys.databases per le repliche denominate in colonne diverse da name e database_id possono essere incoerenti ed errati. Ad esempio, la colonna compatibility_level per una replica denominata può essere segnalata come 140 anche se il database primario da cui è stata creata la replica denominata è impostato su 150. Una soluzione alternativa, quando possibile, consiste nell'ottenere gli stessi dati usando la funzione DATABASEPROPERTYEX(), che restituirà i dati corretti.

Contenuto correlato

Per le esercitazioni sulla configurazione e la gestione di repliche denominate Hyperscale, vedere:

Per altre informazioni, vedi: