Condividi tramite

Repliche in lettura in Database di Azure per MySQL

MySQL è uno dei motori di database più diffusi per l'esecuzione di applicazioni Web e per dispositivi mobili su scala Internet. Molti clienti usano Database di Azure per MySQL per un'ampia gamma di applicazioni, tra cui formazione online, streaming video, pagamenti digitali, e-commerce, giochi, portali di notizie, enti pubblici e siti Web sanitari. Questi servizi devono essere in grado di gestire e ridimensionare il traffico man mano che aumenta il traffico sul Web o sull'applicazione per dispositivi mobili.

Sul lato applicazioni, gli sviluppatori usano in genere Java o PHP. Eseguono la migrazione dell'applicazione per l'esecuzione in set di scalabilità di macchine virtuali di Azure, in Servizi app di Azure o in contenitori per l'esecuzione nel servizio Azure Kubernetes. Con il set di scalabilità di macchine virtuali, il servizio app o il 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. Tuttavia, il database spesso diventa 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 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 usando la tecnologia di replica basata sulla posizione del file binario nativo del motore MySQL (binlog). Per altre informazioni su questo tipo di replica, vedere MySQL binlog replication overview (Panoramica della replica basata su binlog di MySQL).

Le repliche vengono gestite come nuovi server, proprio come le 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 al mese. Per altre informazioni, vedere la pagina relativa ai prezzi.

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 rimuoviamo il termine dal software, lo rimuoviamo da questo articolo.

Casi d'uso comuni per la replica in lettura

La funzionalità di replica in lettura consente di migliorare le prestazioni e la scalabilità dei carichi di lavoro a elevato utilizzo di lettura. È possibile isolare i carichi di lavoro di lettura nelle repliche, indirizzando i carichi di lavoro di scrittura all'origine.

Gli scenari comuni includono:

  • Ridimensionare i 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
  • Uso di repliche in lettura come origine dati per carichi di lavoro di business intelligence o report analitici
  • Inserimento di informazioni di telemetria nel motore di database MySQL durante l'uso di più repliche in lettura per la creazione di report dei dati in scenari IoT o Manufacturing

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 di una 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. Vedere qui per trovare l'elenco delle aree di Azure in cui è attualmente disponibile il server flessibile di Database di Azure per MySQL.

Creare una replica

Quando si avvia il flusso di lavoro di creazione della replica, si crea un'istanza del server flessibile di Database di Azure per MySQL vuota. Il nuovo server contiene 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 di lettura vengono create con la stessa configurazione del server dell'origine. È possibile modificare la configurazione del server di replica dopo la creazione. Il server di replica viene sempre creato nello stesso gruppo di risorse e nella stessa sottoscrizione del server di origine. Se si vuole creare un server di replica in un gruppo di risorse diverso o in una sottoscrizione diversa, è possibile spostare il server di replica dopo la creazione. Mantenere la configurazione del server di replica con valori uguali o superiori rispetto all'origine per garantire che la replica possa mantenere il passo con l'origine.

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

Connessione a una replica

Quando si crea 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 usa l'accesso privato (integrazione rete virtuale), la replica non può usare l'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 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 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. Monitoraggio di Azure calcola questa metrica usando la seconds_behind_master metrica nel comando di SHOW SLAVE STATUS MySQL. Impostare un avviso per notificare quando il ritardo di replica supera una soglia inaccettabile 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 SLAVE_IO_RUNNING/REPLICA_IO_RUNNING metrica disponibile nel comando di SHOW SLAVESTATUS'/'SHOWREPLICA STATUS MySQL. Questo valore viene sempre visualizzato come "No" e non è indicativo dello stato della replica. Per conoscere lo stato corretto della replica, fare riferimento alle metriche di replica - IO Stato replica e stato SQL della replica nella pagina Monitoraggio.

Arrestare la replica

È possibile arrestare la replica tra un server di origine e un server di replica. Quando si arresta la replica tra un server di origine e una replica in lettura, il server di replica diventa un server autonomo. Il server autonomo contiene i dati disponibili nel server di replica quando è stato avviato il comando di arresto della replica. Il server autonomo non sincronizza i dati mancanti dal server di origine.

Quando si arresta la replica in un server di replica, il server di replica perde tutti i collegamenti al server di origine precedente e ad altri server di replica. Non esiste alcun failover automatico tra un server di origine e i relativi server di replica.

Importante

Non è possibile convertire di nuovo il server autonomo in un server di replica. Prima di arrestare la replica in una replica in lettura, verificare che il server di replica disponga di tutti i dati necessari.

Per altre informazioni, vedere Arrestare la replica in una replica.

Failover

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

Le repliche in lettura ridimensionano i carichi di lavoro a elevato utilizzo di lettura e non offrono disponibilità elevata per un server. Per eseguire il failover manuale, arrestare la replica in una replica in lettura, portandola online in modalità di lettura/scrittura.

Poiché la replica è asincrona, esiste un ritardo tra l'origine e la replica. Molti fattori influenzano la quantità di ritardo, ad esempio il carico di lavoro nel server di origine e la latenza tra data center. Nella maggior parte dei casi, il ritardo della replica varia da pochi secondi a un paio di minuti. È possibile tenere traccia del ritardo effettivo della replica usando la metrica Ritardo 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 nel 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

    È necessario arrestare la replica per consentire al server di replica di accettare scritture. Questo processo scollega il server di replica dall'origine. Dopo aver avviato la replica, il processo back-end richiede in genere circa due 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.

Quando l'applicazione elabora correttamente le operazioni di lettura e scrittura, completare il failover. 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.

Identificatore di transazione globale (GTID)

Un identificatore di transazione globale (GTID) è un identificatore univoco creato dal server di origine con ogni transazione sottoposta a commit. Il server flessibile di Database di Azure per MySQL disattiva GTID per impostazione predefinita. Le versioni 5.7 e 8.0 supportano GTID. Per altre informazioni su GTID e sul modo in cui la replica la usa, vedere la documentazione relativa alla replica di MySQL con GTID .

Usare i parametri del server seguenti per configurare GTID:

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 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. Impostare il valore 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.

Annotazioni

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

Dopo aver abilitato GTID, non è 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, seguendo l’ordine crescente delle modalità. Ad esempio, se gtid_mode è attualmente impostato su OFF_PERMISSIVE, è possibile impostarlo su ON_PERMISSIVE ma non su ON.

Per mantenere la coerenza della replica, non è possibile aggiornarla per un server primario o di replica.

Impostare enforce_gtid_consistency su ON prima di impostare gtid_mode su ON.

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

Se un server di origine abilita GTID (gtid_mode = ON), le repliche appena create abilitano gtid e usano la replica GTID. Per garantire la coerenza della replica, non è possibile modificare gtid_mode dopo la creazione di server primari o di replica 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 dipende dall'area in cui viene eseguito il server di replica.
Tempo di inattività/riavvio del server di origine Durante la creazione di una replica in lettura non è necessario alcun riavvio o tempo di inattività. Questa operazione è un'operazione online.
Nuove repliche Si crea una replica in lettura come nuova istanza del server flessibile di Database di Azure per MySQL. Non è possibile creare un server esistente in una replica. Non è possibile creare una replica di un'altra replica in lettura.
Configurazione della replica Creare una replica 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. È anche possibile modificare il livello di calcolo in modo indipendente.

IMPORTANTE : prima di aggiornare una configurazione del server di origine a 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.
Le impostazioni del metodo di connettività e dei parametri vengono ereditate dal server di origine alla replica quando si crea 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. Non è possibile trasformare nuovamente il server autonomo in una replica.
Server di origine eliminati Quando si elimina un server di origine, la replica si arresta in 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 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 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 predefinito nella replica di lettura siano coerenti con quelli del server di origine.
Aggiunta di una colonna chiave primaria AUTO_INCREMENT alla tabella esistente nel server di origine Non è consigliabile modificare la tabella con AUTO_INCREMENT dopo la creazione di una replica di lettura, perché questa azione interrompe la replica. Se si vuole aggiungere una colonna di incremento automatico dopo la creazione di un server di replica, prendere in considerazione questi approcci:
- Creare una nuova tabella con lo stesso schema della tabella da modificare. Nella nuova tabella modificare la colonna con AUTO_INCREMENTe quindi ripristinare i dati dalla tabella originale. Eliminare la tabella precedente e rinominarla nell'origine; questo approccio non richiede l'eliminazione del server di replica, ma potrebbe comportare un costo di inserimento elevato per creare una tabella di backup.
- Ricreare la replica dopo aver aggiunto 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. Questa limitazione è dovuta alla 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 mySQL nella documentazione di MySQL.

Contenuti correlati

  • Last updated on