Repliche in lettura in Database di Azure per MySQL

  • Articolo

SI APPLICA A: Database di Azure per MySQL - Server singolo

Importante

Database di Azure per MySQL server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per MySQL server flessibile. Per altre informazioni sulla migrazione a Database di Azure per MySQL server flessibile, vedere Che cosa accade a Database di Azure per MySQL server singolo?

La funzionalità relativa alle repliche in lettura consente di replicare i dati dal server del Database di Azure per MySQL a un server di sola lettura. È possibile creare fino a un massimo di cinque 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 da gestire in modo simile ai normali server di Database di Azure per MySQL. Per ogni replica in lettura, viene addebitato il costo delle risorse di calcolo e di archiviazione sottoposte a provisioning, espresse rispettivamente in vCore e GB/mese.

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.

Quando usare una 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.

Uno scenario comune consiste nel fare in modo che i carichi di lavoro BI e analitici usino le repliche in lettura come origine dati per la creazione di report.

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.

È possibile avere un server di origine in qualsiasi area Database di Azure per MySQL. Un server di origine può avere una replica nell'area abbinata o nelle aree di replica universale. L'immagine seguente mostra le aree di replica disponibili a seconda dell'area di origine.

Aree di replica universali

È possibile creare una replica di lettura in una delle aree seguenti, indipendentemente dalla posizione del server di origine. Le aree di replica universali supportate includono:

Area Disponibilità della replica
Australia orientale ✔️
Australia sud-orientale ✔️
Brasile meridionale ✔️
Canada centrale ✔️
Canada orientale ✔️
Stati Uniti centrali ✔️
Stati Uniti orientali ✔️
Stati Uniti orientali 2 ✔️
Asia orientale ✔️
Giappone orientale ✔️
Giappone occidentale ✔️
Corea centrale ✔️
Corea meridionale ✔️
Europa settentrionale ✔️
Stati Uniti centro-settentrionali ✔️
Stati Uniti centro-meridionali ✔️
Asia sud-orientale ✔️
Svizzera settentrionale ✔️
Regno Unito meridionale ✔️
Regno Unito occidentale ✔️
Stati Uniti centro-occidentali ✔️
Stati Uniti occidentali ✔️
Stati Uniti occidentali 2 ✔️
Europa occidentale ✔️
India centrale* ✔️
Francia centrale* ✔️
Emirati Arabi Uniti settentrionali* ✔️
Sudafrica settentrionale* ✔️

Nota

*Aree in cui Database di Azure per MySQL ha l'archiviazione per utilizzo generico v2 in anteprima pubblica
*Per queste aree di Azure, è possibile creare un server sia nell'archiviazione per utilizzo generico v1 che nella versione 2. Per i server creati con l'archiviazione per utilizzo generico v2 in anteprima pubblica, è possibile creare un server di replica solo nelle aree di Azure che supportano l'archiviazione per utilizzo generico v2.

Aree abbinate

Oltre alle aree di replica universale, è possibile creare una replica di lettura nell'area abbinata di Azure del server di origine. Se non si conosce la coppia di aree di appartenenza, vedere l'articolo Aree associate di Azure per altre informazioni.

Se si usano repliche tra aree per la pianificazione del ripristino di emergenza, è consigliabile creare la replica nell'area abbinata anziché in una delle altre aree. Le aree associate evitano aggiornamenti simultanei e assegnano priorità all'isolamento fisico e alla residenza dei dati.

È tuttavia necessario considerare due limitazioni:

  • Disponibilità a livello di area: Database di Azure per MySQL è disponibile in Francia centrale, Emirati Arabi Uniti settentrionali e Germania centrale. Tuttavia, le aree abbinate non sono disponibili.

  • Coppie uni direzionali: alcune aree di Azure vengono abbinate in una sola direzione. Queste aree includono India occidentale, Brasile meridionale e US Gov Virginia. Ciò significa che un server di origine in India occidentale può creare una replica in India meridionale. Tuttavia, un server di origine in India meridionale non può creare una replica in India occidentale. Ciò è dovuto al fatto che l'area secondaria dell'India occidentale è l'India meridionale, ma l'area secondaria dell'India meridionale non è l'India occidentale.

Creare una replica

Importante

  • La funzionalità relativa alle repliche in lettura è disponibile solo per i server di Database di Azure per MySQL nei piani tariffari Utilizzo generico o Con ottimizzazione per la memoria. Verificare che il server di origine si trova in uno di questi piani tariffari.
  • Se il server di origine non dispone di server di replica esistenti, potrebbe essere necessario riavviare il server di origine per prepararsi per la replica a seconda dello spazio di archiviazione usato (v1/v2). Prendere in considerazione il riavvio del server ed eseguire questa operazione durante gli orari di minore attività. Per altri dettagli, vedere Riavvio del server di origine.

Quando viene avviato il flusso di lavoro per la creazione della replica, viene creato un server di Database di Azure per MySQL vuoto. 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. 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.

Ogni replica è abilitata per l'aumento automatico dello spazio di archiviazione. La funzionalità di aumento automatico consente alla replica di adattarsi ai dati replicati e impedire un'interruzione della replica causata da errori di spazio di archiviazione insufficiente.

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

Connessione a una replica

Al momento della creazione, una replica eredita le regole del firewall del server di origine. Successivamente, queste regole sono indipendenti dal server di origine.

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 relativo nome host e un account utente valido, come si farebbe per un normale server 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@myreplica -p

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

Monitorare la replica

Database di Azure per MySQL offre la metrica Replication lag in seconds (Intervallo di 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 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.

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.

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 indicherà 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 verrà 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 dipenderà dal momento in cui si rileva un problema e si completano i passaggi 1 e 2 elencati 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 ed è OFF per impostazione predefinita in Database di Azure per MySQL. GTID è supportato nelle versioni 5.7 e 8.0 e solo nei server che supportano l'archiviazione fino a 16 TB (archiviazione per utilizzo generico v2). Per altre informazioni su GTID e su come viene usato nella replica, vedere la documentazione relativa alla replica di MySQL con GTID .

MySQL supporta due tipi di transazioni: transazioni GTID (identificate con GTID) e transazioni anonime (non hanno un GTID allocato)

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.

Nota

  • Dopo l'abilitazione di GTID, non è possibile disattivarla. Se è necessario disattivare GTID, contattare il supporto tecnico.

  • Per modificare gtid da un valore a un altro può essere 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.

  • Consigliato per 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, l'interfaccia della riga di comando di Azure o PowerShell.

Se GTID è abilitato in un server di origine (gtid_mode = ON), anche le repliche appena create avranno GTID abilitato e useranno la replica GTID. Per assicurarsi che la replica sia coerente, gtid_mode non può essere modificata dopo che il server master o di replica viene creato con GTID abilitato.

Considerazioni e limitazioni

Piani tariffari

Le repliche in lettura sono attualmente disponibili solo nei livelli di prezzo per utilizzo generico e ottimizzato per la memoria.

Nota

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

Il server con archiviazione per utilizzo generico v1, il log_bin parametro sarà DISATTIVATo per impostazione predefinita. Il valore verrà attivato quando si crea la prima replica di lettura. Se un server di origine non dispone di repliche di lettura esistenti, il server di origine verrà prima riavviato per prepararsi per la replica. Prendere in considerazione il riavvio del server ed eseguire questa operazione durante gli orari di minore attività.

Il server di origine con archiviazione per utilizzo generico v2, il log_bin parametro sarà ATTIVATO per impostazione predefinita e non richiede un riavvio quando si aggiunge una replica di lettura.

Nuove repliche

Una replica in lettura viene creata come nuovo server 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 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 in modo indipendente il piano tariffario, tranne da o verso il livello Basic.

Importante

Prima che la configurazione del server di origine venga aggiornata con nuovi valori, la configurazione delle repliche deve essere aggiornata impostandola su valori uguali o superiori. Questa azione garantisce che le repliche siano sempre aggiornate con le modifiche apportate all'origine.

Le regole del firewall e le impostazioni 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:

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.

GTID

GTID è supportato in:

  • MySQL versioni 5.7 e 8.0.
  • Server che supportano l'archiviazione fino a 16 TB. Per l'elenco completo delle aree che supportano l'archiviazione da 16 TB, vedere l'articolo relativo al piano tariffario.

GTID è OFF per impostazione predefinita. Dopo aver abilitato GTID, non è più possibile disattivarlo. Se è necessario disattivare GTID, contattare il supporto.

Se GTID è abilitato in un server di origine, sarà abilitato anche nelle repliche appena create e verrà usata la replica GTID. Per mantenere la coerenza della replica, non è possibile eseguire l'aggiornamento gtid_mode nei server di origine o di replica.

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 di MySQL nella documentazione di MySQL

Passaggi successivi