Condividi tramite

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

  • Articolo

SI APPLICA A: 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 viene in genere sviluppata in Java o PHP ed è stata eseguita la migrazione per l'esecuzione in Azure set di scalabilità di macchine virtuali o servizi app Azure o sono in contenitori per l'esecuzione in servizio Azure Kubernetes (servizio Azure Kubernetes). Con il set di scalabilità di macchine virtuali, servizio app o servizio Azure Kubernetes come infrastruttura sottostante, il ridimensionamento delle applicazioni viene semplificato eseguendo immediatamente il provisioning di nuove macchine virtuali e replicando i componenti senza stato delle applicazioni per soddisfare le richieste, ma spesso il database finisce per diventare un collo di bottiglia come componente centralizzato con stato.

La funzionalità di replica in lettura consente di replicare i dati da un'istanza del Database di Azure per MySQL - Server flessibile 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 sulla posizione del file di log binario (binlog) nativo 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 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.

Nota

La funzionalità di replica in lettura è disponibile solo per Database di Azure per MySQL istanze del server flessibile 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.

Nota

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:

  • 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 Manufacturing in cui le informazioni di telemetria vengono inserite nel motore di database MySQL, mentre per la creazione di report dei dati vengono usate più repliche in lettura

Poiché le repliche sono in sola lettura, non riducono direttamente gli oneri per la capacità di scrittura sull’origine. Questa funzionalità non è destinata ai carichi di lavoro che eseguono numerose operazioni 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. Database di Azure per MySQL server flessibile consente di effettuare il provisioning della replica in lettura in qualsiasi area supporto tecnico di Azure ed in cui è disponibile Database di Azure per MySQL server flessibile. 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 è attualmente disponibile Database di Azure per MySQL server flessibile.

Creare una replica

Se un server di origine non dispone di server di replica esistenti, l'origine viene prima riavviata per prepararsi per la replica.

Quando si avvia il flusso di lavoro di creazione della replica, viene creata un'istanza vuota del server flessibile 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.

Nota

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 una sottoscrizione o un gruppo di risorse diverso, è possibile spostare il server di replica dopo averlo creato. È consigliabile mantenere la configurazione del server di replica con valori uguali o maggiori rispetto all'origine per garantire che la replica sia in grado di mantenere il 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 nell'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 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

Database di Azure per MySQL server flessibile fornisce Ritardo replica in secondi metrica 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 usa la 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 nella replica in lettura per portarlo online in modalità di scrittura in lettura è il modo in 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 nella replica, il ritardo al momento in cui si scollega la replica dall'origine indica la quantità di dati persi.

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 precedenti.

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 ed è DISATTIVATo per impostazione predefinita in Database di Azure per MySQL server flessibile. 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 Database di Azure per MySQL istanze del server flessibile con la funzionalità disponibilità elevata abilitata, il valore predefinito è impostato su ON.

Nota

  • 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 in ordine crescente di modalità. Ad esempio, se gtid_mode è attualmente impostato su OFF_PERMISSIVE, è possibile passare a ON_PERMISSIVE ma non su 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 gtid_mode parametri del server e enforce_gtid_consistency usando il portale di Azure o 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 modificata dopo che il server master o i server di replica vengono creati con GTID abilitato.

Considerazioni e limitazioni

Scenario Limitazione/Considerazioni
Replica nel server nel piano tariffario burstable Non supportato
Prezzi Il costo dell'esecuzione del server di replica si basa sull'area in cui è in esecuzione il server di replica
Riavvio del server di origine Quando si crea una replica per un'origine che non dispone di repliche esistenti, l'origine verrà prima riavviata per prepararsi alla replica. Prendere in considerazione queste operazioni ed eseguire queste operazioni durante un periodo di minore attività
Nuove repliche Una replica in lettura viene creata come nuova istanza del server flessibile 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 in valori uguali o superiori. Questa azione garantisce che le repliche siano sempre aggiornate con le modifiche apportate all'origine.
Le impostazioni del metodo di connettività e dei parametri vengono ereditate dal server di origine alla replica quando viene creata la replica. 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 di AUTO_INCREMENT colonna Chiave primaria alla tabella esistente nel server di origine. Non è consigliabile modificare la tabella con AUTO_INCREMENT dopo la creazione della replica in lettura, perché interrompe 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 dalla tabella originale ripristinare i dati. 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.
Altro - La creazione di una replica di una replica non è supportata.
- Le tabelle in memoria possono 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 del server di origine abbiano chiavi primarie. La mancanza di chiavi primarie può comportare una latenza di replica tra il server di origine e le repliche.
- Esaminare l'elenco completo delle limitazioni di replica mySQL nella documentazione di MySQL

Passaggi successivi