Condividi tramite

Repliche in lettura in Database di Azure per MySQL - Server flessibile

MySQL è uno dei motori di database più diffusi per l'esecuzione di applicazioni Web e per dispositivi mobili su scala Internet. Molti clienti lo usano per servizi di formazione online, servizi di streaming video, soluzioni di pagamento digitale, piattaforme di e-commerce, servizi per videogiochi, portali di notizie, siti Web di enti pubblici e assistenza sanitaria. Per rispondere alle esigenze dei clienti, questi servizi devono poter essere ampliati con l'aumento del traffico nelle applicazioni Web o per dispositivi mobili.

Sul lato applicazioni, l'applicazione generalmente viene sviluppata in Java o PHP e migrata per l'esecuzione in set di scalabilità di macchine virtuali di Azure o Servizi app Azure oppure containerizzata per l'esecuzione nel servizio Azure Kubernetes (AKS). Con il Set di scalabilità di macchine virtuali, il Servizio app o il servizio Azure Kubernetes come infrastruttura sottostante, la scalabilità dell'applicazione risulta semplificata tramite il provisioning istantaneo di nuove VM e la replica dei componenti senza stato per soddisfare le richieste, ma spesso il database finisce col diventare un collo di bottiglia come componente con stato centralizzato.

La funzionalità di replica in lettura consente di replicare i dati di un'istanza del Server flessibile di Database di Azure per MySQL in un server di sola lettura. È possibile creare fino a 10 repliche da un server di origine. Le repliche vengono aggiornate in modo asincrono tramite la tecnologia di replica basata su posizione del file di registro binario nativo, o binlog, del motore MySQL. Per altre informazioni su questo tipo di replica, vedere MySQL binlog replication overview (Panoramica della replica basata su binlog di MySQL).

Le repliche sono nuovi server gestiti in modo analogo alle istanze del server flessibile di Database di Azure per MySQL di origine. I costi di fatturazione per ogni replica in lettura vengono addebitati in base alle risorse di calcolo di cui è stato effettuato il provisioning in vCore e all'archiviazione in GB/mese. Per altre informazioni, vedere la pagina relativa ai prezzi.

Annotazioni

La funzionalità di replica in lettura è disponibile solo per le istanze del server flessibile di Database di Azure per MySQL nei piani tariffari Per utilizzo generico o Business Critical. Verificare che il server di origine sia incluso in uno di questi piani tariffari.

Per altre informazioni sulle funzionalità di replica di MySQL e sui relativi problemi, vedere la documentazione sulle repliche di MySQL.

Annotazioni

Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.

Casi d'uso comuni per la replica in lettura

La funzionalità di replica in lettura aiuta a migliorare prestazioni e scalabilità dei carichi di lavoro con utilizzo elevato della lettura. I carichi di lavoro in lettura possono essere isolati per le repliche, mentre i carichi di lavoro in scrittura possono essere indirizzati all’origine.

Scenari comuni sono:

  • Eseguire il ridimensionamento dei carichi di lavoro di lettura provenienti dall'applicazione usando un proxy di connessione leggero come ProxySQL o un modello basato su microservizi per aumentare le istanze delle query di lettura provenienti dall'applicazione per leggere le repliche
  • I carichi di lavoro di report analitici o di business intelligence possono usare repliche in lettura come origine dati per la creazione di report
  • Per lo scenario IoT o Produzione in cui le informazioni di telemetria vengono acquisite nel motore di database MySQL mentre più repliche di sola lettura vengono utilizzate per la reportistica dei dati

Poiché le repliche sono in sola lettura, non riducono direttamente gli oneri per la capacità di scrittura sull’origine. Questa funzionalità non è destinata a carichi di lavoro con utilizzo elevato di scrittura.

Questa funzionalità di replica in lettura si avvale della replica asincrona di MySQL. La funzionalità non è concepita per scenari di replica sincrona. Si verifica un ritardo misurabile tra l'origine e la replica. I dati nella replica diventano alla fine coerenti con quelli nell’origine. Usare questa funzionalità per i carichi di lavoro in grado di sostenere questo ritardo.

Replica tra più aree

È possibile creare una replica in lettura in un'area diversa dal server di origine. La replica tra più aree può essere utile per scenari come la pianificazione del ripristino di emergenza o per avvicinare i dati agli utenti. Il server flessibile di Database di Azure per MySQL consente di effettuare il provisioning della replica in lettura in tutte le aree supportate di Azure in cui è disponibile il server flessibile di Database di Azure per MySQL. Usando questa funzionalità, un server di origine può avere una replica nell'area abbinata o nelle aree di replica universali. Fare riferimento qui per trovare l'elenco delle aree di Azure in cui il server flessibile di Database di Azure per MySQL è attualmente disponibile.

Creare una replica

Quando si avvia il flusso di lavoro di creazione della replica, viene creata un'istanza vuota del server flessibile di Database di Azure per MySQL. Il nuovo server viene riempito con i dati presenti nel server di origine. Il tempo necessario per la creazione dipende dalla quantità di dati nell’origine e dal tempo trascorso dall'ultimo backup completo settimanale. Il tempo può variare da pochi minuti a diverse ore.

Annotazioni

Le repliche in lettura vengono create con la stessa configurazione del server dell'origine. La configurazione del server di replica può essere modificata dopo la creazione. Il server di replica viene creato sempre nello stesso gruppo di risorse e nella stessa sottoscrizione del server di origine. Per creare un server di replica in un gruppo di risorse diverso o in una sottoscrizione diversa, è possibile spostare il server di replica dopo averlo creato. È consigliabile mantenere la configurazione del server di replica con valori uguali o maggiori rispetto a quello di origine per garantire che la replica sia in grado restare al passo con l'origine.

Informazioni su come creare una replica di lettura nel portale di Azure.

Connessione a una replica

Al momento della creazione, una replica eredita il metodo di connettività del server di origine. Non è possibile modificare il metodo di connettività della replica. Ad esempio, se il server di origine ha accesso privato (integrazione rete virtuale), la replica non può trovarsi in accesso pubblico (indirizzi IP consentiti).

La replica eredita l'account amministratore dal server di origine. Tutti gli account utente nel server di origine vengono replicati nelle repliche in lettura. È possibile connettersi a una replica in lettura solo tramite gli account utente che sono disponibili nel server di origine.

È possibile connettersi alla replica usando il nome host e un account utente valido, come si farebbe in una normale istanza del server flessibile di Database di Azure per MySQL. Per un server denominato myreplica con il nome utente amministratore myadmin è possibile connettersi alla replica usando l'interfaccia della riga di comando di mysql:

mysql -h myreplica.mysql.database.azure.com -u myadmin -p

Quando richiesto, immettere la password per l'account dell'utente.

Monitorare la replica

Il server flessibile di Database di Azure per MySQL fornisce la metrica Ritardo replica in secondi in Monitoraggio di Azure. Questa metrica è disponibile per solo le repliche. Questa metrica viene calcolata usando la metrica seconds_behind_master disponibile nel comando SHOW SLAVE STATUS di MySQL. Impostare un avviso per essere informati quando l'intervallo di replica raggiunge un valore non accettabile per il carico di lavoro.

Se viene visualizzato un aumento del ritardo di replica, vedere Risoluzione dei problemi di latenza di replica per risolvere i problemi e comprendere le possibili cause.

Importante

Replica di lettura fa uso della tecnologia di replica basata sull'archiviazione, che non usa più la metrica 'SLAVE_IO_RUNNING'/'REPLICA_IO_RUNNING' disponibile nel comando 'SHOW SLAVE STATUS'/'SHOW REPLICA STATUS' di MySQL. Questo valore viene sempre visualizzato come "No" e non indica lo stato della replica. Per conoscere lo stato corretto della replica, fare riferimento alle metriche di replica Stato I/O della replica e Stato SQL della replica nel pannello Monitoraggio.

Arrestare la replica

È possibile scegliere di arrestare la replica tra un’origine e una replica. Dopo l'arresto della replica tra un server di origine e una replica in lettura, la replica diventa un server autonomo. I dati nel server autonomo sono i dati che erano disponibili nella replica al momento dell'esecuzione del comando di arresto della replica. Il server autonomo non è aggiornato con il server di origine.

Quando si sceglie di arrestare la replica in una replica, vengono persi tutti i collegamenti alla relativa origine precedente e ad altre repliche. Non esiste failover automatico tra un'origine e la relativa replica.

Importante

Il server autonomo non può essere di nuovo impostato come replica. Prima di arrestare la replica in una replica in lettura, assicurarsi che la replica abbia tutti i dati necessari.

Informazioni su come arrestare la replica in una replica.

Failover

Non esiste failover automatico tra server di origine e di replica.

Le repliche in lettura sono progettate per il ridimensionamento di carichi di lavoro a elevato utilizzo di lettura e non sono progettate per soddisfare esigenze di disponibilità elevata di un server. L’arresto della replica sulla replica di sola lettura per renderla operativa in modalità di lettura e scrittura è il metodo con cui viene eseguito questo failover manuale.

Poiché la replica è asincrona, si verifica un ritardo tra l'origine e la replica. Sulla quantità del ritardo possono influire molti fattori, ad esempio quanto è pesante il carico di lavoro in esecuzione nel server di origine e la latenza tra data center. Nella maggior parte dei casi il ritardo della replica è compreso tra pochi secondi e un paio di minuti. È possibile tenere traccia del ritardo effettivo della replica usando la metrica Ritardo di replica, disponibile per ogni replica. Questa metrica indica il tempo trascorso dall'ultima transazione riprodotta. È consigliabile identificare il ritardo medio osservando il ritardo della replica per un periodo di tempo. È possibile impostare un avviso in caso di ritardo della replica: in questo modo, se non rientra nell'intervallo atteso, è possibile intervenire.

Suggerimento

Se si esegue il failover alla replica, il ritardo presente al momento della disconnessione dalla sorgente indica la quantità di dati andata persa.

Dopo aver deciso di eseguire il failover in una replica:

  1. Arrestare la replica per la replica
    Questo passaggio è necessario per consentire al server di replica di accettare le scritture. Come parte di questo processo, il server di replica viene scollegato dall'origine. Dopo aver avviato l’arresto della replica, il completamento del processo back-end richiede in genere circa 2 minuti. Vedere la sezione Arrestare la replica di questo articolo per comprendere le implicazioni di questa azione.

  2. Puntare l'applicazione alla replica (precedente)
    Ogni server ha una stringa di connessione univoca. Aggiornare l'applicazione in modo che punti alla replica (precedente) anziché all'origine.

Il failover è completato dopo che l'applicazione ha elaborato correttamente le letture e le scritture. La quantità di tempo di inattività delle esperienze dell'applicazione dipende dal momento in cui si rileva un problema e si completano i passaggi 1 e 2 indicati in precedenza.

Identificatore di transazione globale (GTID)

L'identificatore di transazione globale (GTID) è un identificatore univoco creato con ogni transazione di cui è stato eseguito il commit in un server di origine, e nel server flessibile Database di Azure per MySQL è OFF per impostazione predefinita. GTID è supportato nelle versioni 5.7 e 8.0. Per altre informazioni su GTID e su come viene usato nella replica, vedere la documentazione di MySQL relativa alla replica con GTID.

Per la configurazione di GTID sono disponibili i seguenti parametri del server:

Parametro del server Descrizione Valore predefinito Valori
gtid_mode Indica se vengono utilizzati GTID per identificare le transazioni. Le modifiche tra le modalità possono essere eseguite solo mediante un passaggio alla volta, in ordine crescente (ad esempio OFF ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON) OFF* OFF: le transazioni di replica nuove e di replica devono essere anonime
OFF_PERMISSIVE: le nuove transazioni sono anonime. Le transazioni replicate possono essere anonime o GTID.
ON_PERMISSIVE: le nuove transazioni sono transazioni GTID. Le transazioni replicate possono essere anonime o GTID.
ON: le transazioni nuove e replicate devono essere transazioni GTID.
enforce_gtid_consistency Applica la coerenza GTID consentendo l'esecuzione solo delle istruzioni che possono essere registrate in modo sicuro a livello transazionale. Questo valore deve essere impostato su ON prima di abilitare la replica GTID. OFF* OFF: tutte le transazioni possono violare la coerenza GTID.
ON: nessuna transazione può violare la coerenza GTID.
WARN: tutte le transazioni possono violare la coerenza GTID, ma viene generato un avviso.

**Per le istanze del server flessibile di Database di Azure per MySQL con la funzionalità disponibilità elevata abilitata, il valore predefinito è impostato su ON.

Annotazioni

  • Dopo aver abilitato GTID, non è più possibile disattivarlo. Se GTID deve essere impostato su OFF, contattare l’assistenza.
  • È possibile modificare i GTID da un valore a un altro solo un passaggio alla volta, seguendo l’ordine crescente delle modalità. Ad esempio, se gtid_mode è attualmente impostato su OFF_PERMISSIVE, lo si può passare a ON_PERMISSIVE ma non a ON.
  • Per mantenere la coerenza della replica, non è possibile aggiornarla per un server master/replica.
  • È consigliabile impostare enforce_gtid_consistency su ON prima di poter impostare gtid_mode=ON.

Per abilitare GTID e configurare il comportamento di coerenza, aggiornare i parametri del server gtid_mode e enforce_gtid_consistency tramiteConfigura parametri del server in Database di Azure per MySQL - Server flessibile usando il portale di Azure o Configura i parametri del server in Database di Azure per MySQL - Server flessibile usando l'interfaccia della riga di comando di Azure.

Se GTID è abilitato in un server di origine (gtid_mode = ON), anche le repliche appena create hanno GTID abilitato e usano la replica GTID. Per assicurarsi che la replica sia coerente, gtid_mode non può essere modificato dopo che il server master o i server di replica vengono creati con GTID abilitato.

Considerazioni e limiti

Sceneggiatura Limitazione/Considerazioni
Replica nel server nel piano tariffario burstable Non supportato
Prezzi Il costo dell'esecuzione del server di replica è basato sull'area in cui è in esecuzione il server di replica
Tempo di inattività/riavvio del server di origine Durante la creazione della replica in lettura non sarà necessario alcun riavvio o tempo di inattività, in quanto questa operazione è online
Nuove repliche Una replica in lettura viene creata come nuova istanza del server flessibile di Database di Azure per MySQL. Un server esistente non può essere impostato come replica. Non è possibile creare una replica di un'altra replica in lettura.
Configurazione della replica Una replica viene creata usando la stessa configurazione server dell’origine. Dopo aver creato una replica, è possibile modificare diverse impostazioni in modo indipendente dal server di origine: la generazione di calcolo, i vCore, l'archiviazione e il periodo di conservazione dei backup. Il livello di calcolo può anche essere modificato in modo indipendente.

IMPORTANTE: prima che una configurazione del server di origine venga aggiornata ai nuovi valori, aggiornare la configurazione della replica a valori uguali o superiori. Questa azione garantisce che le repliche siano sempre aggiornate con le modifiche apportate all'origine.
Il metodo di connettività e le impostazioni dei parametri vengono ereditate dal server di origine e applicate alla replica quando viene creata. Successivamente le regole della replica sono indipendenti.
Repliche arrestate Dopo l'arresto della replica tra un server di origine e una replica in lettura, la replica arrestata diventa un server autonomo che accetta operazioni di lettura e scrittura. Il server autonomo non può essere di nuovo impostato come replica.
Server di origine e autonomi eliminati Quando un server di origine viene eliminato, la replica viene arrestata per tutte le repliche in lettura. Queste repliche diventano automaticamente server autonomi e possono accettare operazioni di lettura e scrittura. Lo stesso server di origine viene eliminato.
Account utente Gli utenti del server di origine vengono replicati nelle repliche in lettura. È possibile connettersi a una replica in lettura solo tramite gli account utente disponibili nel server di origine.
Parametri del server Per evitare che i dati siano esclusi dalla sincronizzazione e scongiurarne potenziali perdite o danneggiamenti, alcuni parametri del server vengono bloccati dall'aggiornamento quando si usano repliche di lettura.
I parametri seguenti del server sono bloccati nei server di origine e di replica:
- innodb_file_per_table
- log_bin_trust_function_creators
Il parametro event_scheduler è bloccato nei server di replica.
Per aggiornare uno dei parametri precedenti nel server di origine, eliminare i server di replica, aggiornare il valore del parametro nell'origine e ricreare le repliche.
Parametri a livello di sessione Quando si configurano parametri a livello di sessione, ad esempio 'foreign_keys_checks' nella replica di lettura, assicurarsi che i valori dei parametri impostati nella replica di lettura siano coerenti con quello del server di origine.
Aggiunta della colonna chiave primaria AUTO_INCREMENT alla tabella esistente nel server di origine. Non è consigliabile modificare la tabella con AUTO_INCREMENT dopo la creazione della replica in lettura, poiché ciò interromperebbe la replica. Tuttavia, nel caso in cui si voglia aggiungere la colonna di incremento automatico dopo la creazione di un server di replica, è consigliabile adottare questi due approcci:
- Creare una nuova tabella con lo stesso schema della tabella da modificare. Nella nuova tabella, modificare la colonna con AUTO_INCREMENT e quindi ripristinare i dati dalla tabella originale. Eliminare la tabella precedente e rinominarla nell'origine; non è necessario eliminare il server di replica, ma potrebbe essere necessario un costo di inserimento elevato per la creazione della tabella di backup.
- L'altro metodo più rapido consiste nel ricreare la replica dopo l'aggiunta di tutte le colonne di incremento automatico.
Altri La creazione della replica di replica non è supportata.
- Le tabelle in memoria potrebbero causare la disconnessità delle repliche. Si tratta di una limitazione della tecnologia di replica MySQL. Per altre informazioni, vedere la documentazione di riferimento di MySQL.
- Verificare che le tabelle di server di origine dispongano delle chiavi primarie. La mancanza di chiavi primarie potrebbe comportare la latenza di replica tra l'origine e le repliche.
- Esaminare l'elenco completo delle limitazioni di replica di MySQL nella documentazione di MySQL

Contenuti correlati