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

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 server flessibile Database di Azure per MySQL a 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 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 di server flessibili nei piani tariffari Per utilizzo generico o Business Critical. Verificare che il server di origine si trova 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 di lettura possono essere isolati nelle repliche, mentre i carichi di lavoro di scrittura possono essere indirizzati all'origine.

Gli 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 di sola lettura, non riducono direttamente i carichi di lavoro di 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 infine coerenti con i dati nell'origine. Usare questa funzionalità per i carichi di lavoro in grado di sostenere questo ritardo.

Replica tra più aree

È possibile creare una replica di 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 del server flessibile vuota Database di Azure per MySQL. Il nuovo server viene riempito con i dati presenti nel server di origine. Il tempo di creazione dipende dalla quantità di dati nell'origine e dall'ora dell'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 sempre creato 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 di lettura. È possibile connettersi a una replica di lettura solo usando gli account utente disponibili nel server di origine.

È possibile connettersi alla replica usando il nome host e un account utente valido, come si farebbe in un'istanza normale 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 informare l'utente quando il ritardo 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 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 raggiunge il server di origine.

Quando si sceglie di arrestare la replica in una replica, perde tutti i collegamenti all'origine precedente e ad altre repliche. Non esiste alcun 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 alcun 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. La quantità di ritardo può essere influenzata da molti fattori come 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 replica, disponibile per ogni replica. Questa metrica mostra l'ora dell'ultima transazione riprodotta. È consigliabile identificare il ritardo medio osservando il ritardo della replica in un periodo di tempo. È possibile impostare un avviso in caso di ritardo della replica, in modo che, se non rientra nell'intervallo previsto, è 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 nella replica
   Questo passaggio è necessario per consentire al server di replica di accettare scritture. Come parte di questo processo, il server di replica viene scollegato dall'origine. Dopo aver avviato la replica di arresto, il 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 un stringa di connessione univoco. Aggiornare l'applicazione in modo che punti alla replica (precedente) anziché all'origine.

Dopo che l'applicazione ha elaborato correttamente le letture e le scritture, il failover è stato completato. 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 relativa alla replica di MySQL con GTID .

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

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 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 transazioni anonime o GTID. ON_PERMISSIVE: le nuove transazioni sono transazioni GTID. Le transazioni replicate possono essere transazioni anonime o GTID. ON: le transazioni nuove e replicate devono essere transazioni GTID.
enforce_gtid_consistency	Applica la coerenza GTID consentendo l'esecuzione solo di tali istruzioni che possono essere registrate in modo sicuro in modo 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 flessibili con la funzionalità disponibilità elevata abilitata, il valore predefinito è impostato su ON.

Nota

• Dopo aver abilitato GTID, non è più possibile disattivarlo. Se è necessario disattivare GTID, contattare il supporto tecnico.
• È 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 edizione Standard T 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 per la 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 del server dell'origine. Dopo aver creato una replica, è possibile modificare diverse impostazioni indipendentemente dal server di origine: generazione di calcolo, vCore, archiviazione e 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. Connessione incrono le impostazioni del metodo e dei parametri vengono ereditate dal server di origine alla replica al momento della creazione della replica. Successivamente le regole della replica sono indipendenti.
Repliche arrestate	Se si arresta la replica tra un server di origine e una replica in lettura, la replica arrestata diventa un server autonomo che accetta sia letture che scritture. 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 in tutte le repliche in lettura. Queste repliche diventano automaticamente server autonomi e possono accettare operazioni di lettura e scrittura. Il server di origine viene eliminato.
Account utente	Gli utenti nel server di origine vengono replicati nelle repliche di lettura. È possibile connettersi a una replica di lettura solo usando 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 del server seguenti 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ò causare la latenza di replica tra l'origine e le repliche. - Esaminare l'elenco completo delle limitazioni di replica mySQL nella documentazione di MySQL

Passaggi successivi

• Informazioni su come creare e gestire le repliche in lettura tramite il portale di Azure
• Leggere le informazioni su come creare e gestire repliche in lettura tramite l'interfaccia della riga di comando di Azure