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. È possibile usare repliche secondarie con livelli di calcolo serverless o 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 per aumentare la disponibilità del database; agiscono come repliche 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 si usa .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. Anche l'obiettivo del livello di servizio (SLO) è sempre uguale a quello della replica primaria. Le repliche a disponibilità elevata non sono visibili o gestibili come risorse autonome, dal portale o da qualsiasi API. Vengono fatturati alla stessa tariffa di calcolo della replica primaria, ma i costi di archiviazione non si applicano alle repliche secondarie.

Possono essere presenti da zero a quattro repliche di disponibilità elevata. È possibile specificare le repliche numeriche durante la creazione di un nuovo database oppure aggiornare il numero di repliche per un database esistente. È possibile usare gli endpoint e gli strumenti di gestione comuni( ad esempio Azure PowerShell, interfaccia della riga di comando di Azure, portale di Azure, API REST) per specificare il numero di repliche a disponibilità elevata. La creazione o la rimozione di repliche a 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 dispone di una replica secondaria, la connessione viene instradata alla replica primaria e il comportamento viene ReadWrite predefinito.

-- 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 in esecuzione nella 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 (interfaccia della riga di comando di Azure, 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 vengono disconnessi se la replica primaria viene ridimensionata o ridotta.
  • Gli utenti connessi alla replica primaria non sono interessati quando le repliche denominate vengono ridimensionate verso l'alto o verso il basso.
  • I carichi di lavoro in esecuzione in qualsiasi replica, primaria o denominata, non sono interessati dalle query con esecuzione prolungata in esecuzione 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:

Inoltre, 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: poiché una replica denominata può avere un proprio obiettivo a livello di servizio, è possibile usare repliche denominate diverse per diversi carichi di lavoro e casi d'uso. 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.
  • Routing dipendente dal carico di lavoro: con un massimo di 30 repliche denominate, è possibile usare repliche denominate in gruppi in modo che un'applicazione possa essere isolata 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

Le repliche denominate Hyperscale configurate per la ridondanza della zona usano Azure zone di disponibilità 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 una replica geografica si trova in un'area di Azure diversa, può essere usata per il ripristino di emergenza in caso di emergenza o interruzione 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 ha-replicas redundantparametri che .
    • 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 per il database primario è abilitata la ridondanza della zona.
    • 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 compatibility_level colonna per una replica denominata può essere segnalata come 140 anche se il database primario corrispondente alla replica denominata è impostato sul livello di compatibilità 150. Una soluzione alternativa, quando possibile, consiste nel ottenere gli stessi dati usando la DATABASEPROPERTYEX() funzione , che restituisce dati corretti.

Contenuto correlato

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

Per altre informazioni, vedi: