Repliche secondarie hyperscale

Si applica a: Database SQL di Azure

Come descritto nell'architettura delle funzioni distribuite, Azure SQL Database Hyperscale include due tipi diversi 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 diversa, un set di funzionalità, uno scopo e un costo diversi. In base alle funzionalità necessarie, è possibile usare solo una o anche tutte le tre insieme.

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 standby frequente a scopo di failover. Se la replica primaria non è 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 potrebbero riscontrare tempi di inattività minimi a causa dell'eliminazione delle connessioni attive. Come di consueto per questo scenario, è consigliata la 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 supporto completo nativo per la logica di ripetizione automatica configurabile.

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

Può essere pari a 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, AZ CLI, Portal, 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 utilizzata 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 dispone di una replica secondaria, la connessione verrà indirizzata alla replica primaria e verrà impostata per impostazione predefinita sul 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 di disponibilità elevata sono identiche nella capacità delle risorse. Se sono presenti più repliche di disponibilità elevata, il carico di lavoro di lettura-finalità viene distribuito arbitrariamente in tutte le repliche di disponibilità elevata disponibili. Quando sono presenti più repliche di 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 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 servizio del log delle transazioni, che inoltra i record di log dalla replica primaria alle repliche di 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 in velocità diverse e quindi le repliche diverse potrebbero avere una latenza dei dati diversa rispetto alla replica primaria.

Replica denominata

Una replica denominata, analogamente a 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.

La differenza delle repliche a disponibilità elevata è che le repliche denominate:

  • vengono visualizzati come normali (di sola lettura) Azure SQL database nel portale e nelle chiamate API (AZ CLI, PowerShell, T-SQL);
  • può avere un nome di database diverso dalla replica primaria e, facoltativamente, si trova in un server logico diverso (purché si trovi nella stessa area della replica primaria);
  • avere un proprio obiettivo a livello di servizio che può essere impostato e modificato in modo indipendente dalla replica primaria;
  • supporto per fino a 30 repliche denominate (per ogni replica primaria);
  • supportare 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 o ridotta; allo stesso tempo gli utenti connessi alla replica primaria non saranno interessati da repliche denominate che aumentano o si abbassano
  • i carichi di lavoro in esecuzione in qualsiasi replica, primaria o denominata, non saranno interessati da query a esecuzione prolungata in esecuzione in altre repliche

L'obiettivo principale delle repliche denominate è consentire un'ampia gamma di scenari di scalabilità orizzontale di lettura e per migliorare i carichi di lavoro HTAP (Hybrid Transactional and Analytics Processing). Esempi di come creare tali soluzioni sono disponibili qui:

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

  • Isolamento 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: come 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 servire i dati alle attività apache Spark per l'analisi scientifica dei dati. Ognuno può avere un obiettivo indipendente a livello di servizio e ridimensionare in modo indipendente.
  • Routing dipendente dal carico di lavoro: con fino a 30 repliche denominate, è possibile usare repliche denominate in gruppi in modo che un'applicazione possa essere isolata da un'altra. Ad esempio, un gruppo di quattro repliche denominate può essere usato per gestire le richieste provenienti da applicazioni 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 con granularità fine delle prestazioni e dei costi per ogni gruppo.

Nell'esempio seguente viene creata una replica denominata WideWorldImporters_NamedReplica per il database WideWorldImporters. La replica primaria usa l'obiettivo del livello di servizio HS_Gen5_4, mentre la replica denominata usa HS_Gen5_2. Entrambi usano lo stesso server contosoeastlogico . Se si preferisce usare direttamente l'API REST, questa opzione è anche possibile: Database - Creare un database come secondario di replica denominata.

  1. Nella portale di Azure passare al database per il quale si vuole creare la replica denominata.

  2. Nella pagina database SQL selezionare il database, scorrere fino a Gestione dati, selezionare Repliche e quindi selezionare Crea replica.

    Screenshot che mostra il passaggio di creazione della replica denominata.

  3. Scegliere Replica denominata in Configurazione replica, selezionare o creare il server per la replica denominata, immettere il nome del database di replica denominato e configurare le opzioni di calcolo e archiviazione , se necessario.

    Screenshot che mostra la configurazione della replica denominata.

  4. Fare clic su Rivedi e crea, esaminare le informazioni e quindi fare clic su Crea.

  5. Il processo di distribuzione di replica denominato inizia.

    Screenshot che mostra lo stato di distribuzione della replica denominata.

  6. Al termine della distribuzione, la replica denominata visualizza lo stato.

    Screenshot che mostra lo stato della replica denominata dopo la distribuzione.

  7. Tornare alla pagina del database primario e quindi selezionare Repliche. La replica denominata è elencata in Repliche denominate.

    Screenshot che mostra la replica primaria e denominata del database SQL.

Poiché non è presente alcun movimento di dati, nella maggior parte dei casi verrà creata una replica denominata in circa un minuto. Una volta disponibile la replica denominata, sarà visibile dal portale o da qualsiasi strumento da riga di comando, ad esempio AZ CLI o PowerShell. Una replica denominata è utilizzabile come database di sola lettura regolare.

Connessione a una replica denominata

Per connettersi a una replica denominata, è necessario usare la stringa di connessione per la replica denominata, facendo riferimento ai nomi del server e del database. Non è necessario specificare l'opzione "ApplicationIntent=ReadOnly" come repliche denominate sono sempre di sola lettura.

Proprio come per le repliche di disponibilità elevata, anche se le repliche primarie, a disponibilità elevata e denominate condividono gli stessi dati nello stesso set di server di pagine, le cache dei dati in ogni replica denominata vengono mantenute sincronizzate con il servizio di log primario tramite il servizio log delle transazioni, che inoltra i record di log dall'elemento primario alle repliche denominate. Di conseguenza, a seconda del carico di lavoro elaborato da una replica denominata, l'applicazione dei record di log può verificarsi a velocità diverse e quindi le diverse repliche potrebbero avere una latenza dei dati diversa rispetto alla replica primaria.

Modifica di una replica denominata

È possibile definire l'obiettivo del livello di servizio di una replica denominata quando lo si crea, tramite il ALTER DATABASE comando o in qualsiasi altro modo supportato (Portale, AZ CLI, PowerShell, API REST). Se è necessario modificare l'obiettivo del livello di servizio dopo la creazione della replica denominata, è possibile usarlo usando il ALTER DATABASE ... MODIFY comando nella replica denominata stessa. Ad esempio, se WideWorldImporters_NamedReplica è la replica denominata del WideWorldImporters database, è possibile eseguirla come illustrato di seguito.

Aprire la pagina del database di replica denominata e quindi selezionare Calcolo + archiviazione. Aggiornare i vCore.

Screenshot che mostra l'aggiornamento obiettivo del livello di servizio di replica denominato.

Rimozione di una replica denominata

Per rimuovere una replica denominata, è sufficiente rilasciarla come si vuole un database normale.

Aprire la pagina del database di replica denominata e scegliere Delete l'opzione .

Screenshot che mostra l'eliminazione della replica denominata.

Importante

Le repliche denominate verranno rimosse automaticamente quando viene eliminata la replica primaria da cui sono stati creati.

Problemi noti

Dati parzialmente non corretti restituiti da sys.database

I valori di riga restituiti da sys.databases, per le repliche denominate, in colonne diverse da name e database_id, possono essere incoerenti e non corrette. 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, se possibile, consiste nel ottenere gli stessi dati usando la DATABASEPROPERTYEX() funzione, che restituirà dati corretti.

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 pagina con l'oggetto 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 con transazioni del database tramite 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 geografica.

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

  • È possibile creare una sola replica geografica (nella stessa area o diversa).
  • Il ripristino temporizzato della replica geografica non è supportato.
  • La creazione di una copia del database della replica geografica non è supportata.
  • Secondario di un database secondario (noto anche come "concatenamento di repliche geografiche") non è supportato.

Passaggi successivi