Repliche secondarie Hyperscale

  • Articolo

Si applica a:database SQL di Azure

Come descritto in Architettura delle funzioni distribuite, database SQL di Azure Hyperscale 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 set di funzionalità, uno scopo e un costo diversi. In base alle funzionalità necessarie, è possibile usare solo uno o anche tutti e tre insieme. Le repliche secondarie sono supportate sia dai livelli di calcolo serverless che da quello con provisioning.

Per 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 aggiungere una replica a disponibilità elevata. Le repliche a disponibilità elevata vengono usate principalmente 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 a disponibilità elevata esistenti è automatico e rapido. Il stringa di connessione non deve cambiare. Durante le applicazioni di failover potrebbe verificarsi un tempo di inattività 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 a 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 a disponibilità elevata non sono visibili o gestibili come risorsa autonoma dal portale o da qualsiasi API.

Possono essere presenti da zero a quattro repliche a 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, interfaccia della riga di comando di Azure, portale, API REST. 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 usato dal client determina se la connessione viene instradata alla replica primaria di lettura/scrittura o a una replica a disponibilità elevata di sola lettura. Se ApplicationIntent è impostato su ReadOnly e il database non ha una replica secondaria, la connessione verrà instradata alla replica primaria e verrà predefinito il ReadWrite comportamento.

-- 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 a disponibilità elevata sono identiche nella capacità delle risorse. Se sono presenti più repliche a disponibilità elevata, il carico di lavoro con finalità di lettura viene distribuito in modo arbitrario in tutte le repliche a disponibilità elevata disponibili. Quando sono presenti più repliche a disponibilità elevata, tenere 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 set 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 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 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, 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é si trovi 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 alle repliche 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 viene ridimensionata 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 riduceno.
  • I carichi di lavoro in esecuzione in qualsiasi replica, primaria o denominata, non saranno interessati da query con esecuzione prolungata in esecuzione in altre repliche.

L'obiettivo principale delle repliche denominate è consentire un'ampia gamma di scenari di scalabilità orizzontale in lettura e migliorare i carichi di lavoro HTAP (Hybrid Transactional and Analytical Processing). Ecco 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: poiché 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, una replica denominata può essere usata per gestire le richieste di Power BI, mentre un'altra può essere usata per gestire i dati ad Apache Spark per le attività di data science. Ognuno di essi può avere un obiettivo del livello di servizio indipendente e ridimensionare 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 Hyperscale, vedere database SQL di Azure domande frequenti sulle repliche denominate Hyperscale.

Ridondanza della zona per le repliche denominate Hyperscale

Nota

La ridondanza della zona per database SQL di Azure repliche denominate Hyperscale è attualmente in anteprima.

La ridondanza della zona per database SQL di Azure repliche denominate Hyperscale usa 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 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 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à orizzontale in lettura geografica. A partire da ottobre 2022, è supportata la copia del database da una replica geografica secondaria Hyperscale.

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

  • È possibile creare una sola replica geografica (nella stessa area o in un'area 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 nell'interfaccia della riga di comando. 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 "ridondanti".
    • In PowerShell è necessario specificare il parametro "HighAvailabilityReplicaCount" e "ZoneRedundant".
    • Se omesso, viene visualizzato il messaggio di errore: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.

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

    • È facoltativo abilitare la ridondanza della zona per le repliche denominate, anche se il database primario ha la ridondanza della zona abilitata.
    • Se non è abilitato, 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 non corretti restituiti da sys.databases

I valori di riga restituiti da , per le repliche denominate, in colonne diverse da sys.databasesname e database_id, potrebbero non essere coerenti e non corretti. Ad esempio, la compatibility_level colonna 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 nel ottenere gli stessi dati usando la DATABASEPROPERTYEX() funzione , che restituirà i dati corretti.

Contenuto correlato

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

Per altre informazioni, vedi: