Condividi tramite

Disponibilità elevata in Database di Azure per MySQL

Il server flessibile di Database di Azure per MySQL consente di configurare la disponibilità elevata con failover automatico. Questa soluzione garantisce che gli errori non causino mai la perdita di dati di cui è stato eseguito il commit e che il database non sia un singolo punto di errore nell'architettura software. Quando si configura la disponibilità elevata, il server flessibile effettua automaticamente il provisioning e gestisce una replica di standby. Si paga per il calcolo e l'archiviazione di cui è stato effettuato il provisioning per le repliche primarie e secondarie. Sono disponibili due modelli di architettura a disponibilità elevata:

  • Disponibilità elevata con ridondanza della zona. Questa opzione offre isolamento completo e ridondanza dell'infrastruttura in più zone di disponibilità. Offre il massimo livello di disponibilità, ma richiede di configurare la ridondanza dell'applicazione tra le zone. Scegliere la disponibilità elevata con ridondanza della zona quando si vuole proteggersi da eventuali errori dell'infrastruttura nella zona di disponibilità e quando la latenza nella zona di disponibilità è accettabile. È possibile abilitare la disponibilità elevata con ridondanza della zona solo quando si crea il server. La disponibilità elevata con ridondanza della zona è disponibile in un subset di aree di Azure in cui l'area supporta più zone di disponibilità e le condivisioni file Premium con ridondanza della zona sono disponibili.

  • Disponibilità elevata con ridondanza locale. Questa opzione offre ridondanza dell'infrastruttura con una latenza di rete inferiore perché i server primario e standby si trovano nella stessa zona di disponibilità. Offre disponibilità elevata senza la necessità di configurare la ridondanza dell'applicazione tra le zone. Scegliere Disponibilità elevata con ridondanza locale quando si vuole ottenere il massimo livello di disponibilità all'interno di una singola zona di disponibilità con la latenza di rete più bassa. La disponibilità elevata con ridondanza locale è disponibile in tutte le aree di Azure in cui è possibile usare il server flessibile di Database di Azure per MySQL.

Architettura a disponibilità elevata con ridondanza della zona

Quando si distribuisce un server con disponibilità elevata con ridondanza della zona, Azure crea due server:

  • Un server primario in una zona di disponibilità.
  • Un server di replica di standby in un'altra zona di disponibilità della stessa area di Azure. Il server di replica di standby con la stessa configurazione del server primario, tra cui livello di calcolo, dimensioni di calcolo, dimensioni di archiviazione e configurazione di rete.

È possibile scegliere la zona di disponibilità sia per il server primario che per la replica di standby. L'inserimento dei server di database di standby e delle applicazioni standby nella stessa zona riduce la latenza. Consente inoltre di prepararsi per situazioni di ripristino di emergenza e scenari di "zona verso il basso".

Diagramma che mostra l'architettura per la disponibilità elevata con ridondanza della zona.

I file di dati e di log sono ospitati nell'archiviazione con ridondanza della zona. Il server standby legge e riproduce continuamente i file di log dall'account di archiviazione del server primario, che protegge la replica a livello di archiviazione.

Se si verifica un failover:

  • La replica di standby viene attivata.
  • I file di log binari del server primario continuano a essere applicati al server standby per portarlo online all'ultima transazione di cui è stato eseguito il commit nel server primario.

I log nell'archiviazione con ridondanza della zona sono accessibili anche quando il server primario non è disponibile. Questa disponibilità consente di garantire che non si verifichi alcuna perdita di dati. Dopo l'attivazione della replica di standby e l'applicazione dei log binari, il server di replica di standby corrente assume il ruolo del server primario. Aggiornamenti DNS in modo che le connessioni client siano dirette al nuovo database primario quando il client si riconnette. Il failover è completamente trasparente dall'applicazione client e non richiede alcuna azione da parte dell'utente. La soluzione a disponibilità elevata restituisce quindi il server primario precedente quando possibile e lo inserisce come standby.

Usare il nome del server di database per connettere le applicazioni al server primario. La soluzione non espone informazioni sulla replica di standby per l'accesso diretto. I commit e le scritture vengono riconosciuti dopo che i file di log vengono scaricati nell'archiviazione con ridondanza della zona del server primario. A causa della tecnologia di replica di sincronizzazione usata nell'archiviazione con ridondanza della zona, è possibile prevedere un aumento della latenza del 5-10% per le operazioni di scrittura e commit dell'applicazione.

I backup automatici, sia gli snapshot che i backup del log, vengono eseguiti nell'archiviazione con ridondanza della zona dal server di database primario.

Architettura a disponibilità elevata con ridondanza locale

Quando si implementa un server a disponibilità elevata con ridondanza locale, si creano due server nella stessa zona:

  • Un server primario
  • Un server di replica standby con la stessa configurazione del server primario (livello di calcolo, dimensioni di calcolo, dimensioni di archiviazione e configurazione di rete)

Il server standby offre ridondanza dell'infrastruttura con una macchina virtuale separata (calcolo). Questa ridondanza riduce i tempi di failover e la latenza di rete tra l'applicazione e il server di database a causa della condivisione del percorso.

Diagramma che mostra l'architettura per la disponibilità elevata con ridondanza locale.

I file di dati e di log sono ospitati nell'archiviazione con ridondanza locale. Il server standby legge e riproduce continuamente i file di log dall'account di archiviazione del server primario, protetto dalla replica a livello di archiviazione.

Se si verifica un failover:

  • La replica di standby viene attivata.
  • I file di log binari del server primario continuano a essere applicati al server standby per portarlo online all'ultima transazione di cui è stato eseguito il commit nel server primario.

I log nell'archiviazione con ridondanza locale sono accessibili anche quando il server primario non è disponibile. Questa disponibilità consente di garantire che non si verifichi alcuna perdita di dati. Dopo l'attivazione della replica standby e l'applicazione dei log binari, la replica di standby corrente assume il ruolo del server primario. DNS viene aggiornato per reindirizzare le connessioni al nuovo database primario quando il client si riconnette. Il failover è completamente trasparente dall'applicazione client e non richiede alcuna azione da parte dell'utente. La soluzione a disponibilità elevata restituisce quindi il server primario precedente quando possibile e lo inserisce come standby.

Il nome del server di database connette le applicazioni al server primario. Le informazioni sulla replica standby non vengono esposte per l'accesso diretto. I commit e le scritture vengono riconosciuti dopo che i file di log vengono scaricati nell'archiviazione con ridondanza locale del server primario. Poiché la replica primaria e di standby si trovano nella stessa zona, tra il server applicazioni e il server di database è presente un ritardo di replica inferiore e una latenza inferiore. La configurazione con ridondanza locale non offre disponibilità elevata quando le infrastrutture dipendenti sono inattiva per la zona di disponibilità specifica. Si verifica un tempo di inattività fino a quando tutti i servizi dipendenti non tornano online per la zona di disponibilità.

I backup automatici, sia gli snapshot che i backup del log, vengono eseguiti nell'archiviazione con ridondanza locale dal server di database primario.

Note

Sia per la disponibilità elevata con ridondanza della zona che per la disponibilità elevata con ridondanza locale:

  • Se si verifica un errore, il tempo necessario perché la replica di standby assuma il ruolo di primaria dipende dal tempo necessario per riprodurre il log binario dall'account di archiviazione primario allo standby. Per ridurre il tempo di failover, usare le chiavi primarie in tutte le tabelle. I tempi di failover sono in genere compresi tra 60 e 120 secondi.
  • Il server standby non è disponibile per le operazioni di lettura o scrittura. Si tratta di uno standby passivo per abilitare il failover rapido.
  • Usare sempre un nome di dominio completo (FQDN) per connettersi al server primario. Evitare di usare un indirizzo IP per connettersi. Se si verifica un failover, dopo che i ruoli del server primario e standby sono stati modificati, un record DNS A potrebbe cambiare. Questa modifica impedisce all'applicazione di connettersi al nuovo server primario se viene usato un indirizzo IP nella stringa di connessione.

Processo di failover

Durante il processo di failover in Database di Azure per MySQL, il sistema passa automaticamente dal server primario alla replica di standby. Questa opzione garantisce la continuità e riduce al minimo i tempi di inattività. Quando il sistema rileva un errore, promuove la replica di standby per diventare il nuovo server primario. Il sistema applica i file di log binari dal server primario originale alla replica di standby. Questo processo sincronizza la replica di standby con l'ultima transazione di cui è stato eseguito il commit e non garantisce alcuna perdita di dati. Questa transizione facile consente di mantenere la disponibilità elevata e l'affidabilità del servizio di database.

Note

Per ridurre la dipendenza del tempo di failover dalla memorizzazione nella cache DNS, a partire da ottobre 2025, tutti i nuovi server a disponibilità elevata creati con accesso pubblico o collegamento privato adotteranno la nuova architettura con un bilanciamento del carico software dedicato per ogni server a disponibilità elevata. Gestendo il percorso del traffico dati MySQL, SLB elimina la necessità di apportare modifiche al DNS durante il failover e migliora significativamente le prestazioni del failover. Reindirizza il traffico all'istanza primaria corrente durante il failover usando regole di bilanciamento del carico. I server esistenti con accesso pubblico o collegamento privato verranno migrati gradualmente per ridurre al minimo l'impatto. I clienti che preferiscono la migrazione anticipata possono disabilitare e riabilitare la disponibilità elevata. Questa funzionalità non è supportata per i server che usano l'accesso privato con l'integrazione della rete virtuale.

Pianificato: failover forzato

Il failover forzato del server flessibile di Database di Azure per MySQL consente di forzare manualmente un failover. Questa funzionalità consente di testare le funzionalità con gli scenari dell'applicazione e di prepararsi per le interruzioni.

Il failover forzato innesca un failover che attiva la replica standby come server primario con lo stesso nome del server di database aggiornando il record DNS. Il server primario originale viene riavviato e passa alla replica di standby. Le connessioni client si disconnettono e devono riconnettersi per riprendere le operazioni.

Il tempo di failover complessivo dipende dal carico di lavoro corrente e dall'ultimo checkpoint. In generale, richiede tra 60 e 120 secondi.

Note

Un evento di Integrità risorse di Azure viene generato durante un failover pianificato. L'evento rappresenta il tempo di failover durante il quale il server non è disponibile. È possibile visualizzare gli eventi attivati quando sono selezionati in Integrità risorse nel riquadro sinistro. Lo stato rappresenta il failover manuale o avviato dall'utente come "Non disponibile" e contrassegnato come "Pianificato". Esempio: "Un'operazione di failover è stata attivata da un utente autorizzato (Pianificato)". Se la risorsa rimane in questo stato per un lungo periodo di tempo, aprire un ticket di supporto e provvederemo a fornire assistenza.

Non pianificato: failover automatico

Il tempo di inattività del servizio non pianificato può verificarsi a causa di bug software o errori dell'infrastruttura, ad esempio errori di calcolo, rete o archiviazione. Le interruzioni dell'alimentazione possono influire anche sulla disponibilità del database. Se il database non è più disponibile, la replica alla replica di standby viene arrestata e la replica di standby diventa il database primario. Gli aggiornamenti DNS vengono eseguiti e i client si riconnettono al server di database, riprendendo le operazioni.

Il tempo di failover complessivo è in genere compreso tra 60 e 120 secondi. Tuttavia, a seconda dell'attività nel server di database primario al momento del failover (ad esempio transazioni di grandi dimensioni e tempo di ripristino), il failover potrebbe richiedere più tempo.

Note

Un evento di Integrità risorse di Azure viene generato durante un failover non pianificato. L'evento rappresenta il tempo di failover quando il server non è disponibile. È possibile visualizzare gli eventi attivati quando si seleziona Integrità risorse nel riquadro sinistro. Il failover automatico mostra lo stato "Non disponibile" e viene contrassegnato come "Non pianificato".

Ad esempio, Non disponibile: un'operazione di failover è stata attivata automaticamente (non pianificata). Se la risorsa rimane in questo stato per molto tempo, aprire un ticket di supporto e provvederemo a fornire assistenza.

Funzionamento del rilevamento automatico del failover nei server abilitati per la disponibilità elevata

Il server primario e il server secondario hanno ognuno due endpoint di rete:

  • Endpoint cliente: i clienti si connettono ed eseguono query sull'istanza usando questo endpoint.
  • Endpoint di gestione: usato internamente per le comunicazioni del servizio ai componenti di gestione e per connettersi all'archiviazione back-end.

Il componente monitoraggio integrità esegue continuamente i controlli seguenti:

  • Il monitoraggio esegue il ping dell'endpoint di rete di gestione del nodo. Se questo controllo ha esito negativo due volte in modo continuo, attiva un'operazione di failover automatico. Questo controllo integrità risolve scenari quali l'indisponibilità del nodo o la mancata risposta a causa di problemi del sistema operativo, problemi di networking tra componenti di gestione e nodi e problemi simili.
  • Il monitoraggio esegue una query semplice nell'istanza. Se l'esecuzione delle query non riesce, viene attivato il failover automatico. Questo controllo integrità risolve scenari quali arresti anomali, arresti o blocchi del daemon MySQL e problemi di archiviazione back-end e problemi simili.

Note

Il controllo integrità non monitora i problemi di rete tra l'applicazione e l'endpoint di networking del cliente (accesso privato/pubblico). Questi problemi possono verificarsi nel percorso di networking, nell'endpoint o nei problemi DNS sul lato client. Se si usa l'accesso privato, assicurarsi che le regole del gruppo di sicurezza di rete per la rete virtuale non blocchino la comunicazione con l'endpoint di networking del cliente dell'istanza sulla porta 3306. Per l'accesso pubblico, assicurarsi che le regole del firewall siano impostate e che il traffico di rete sia consentito sulla porta 3306 (se il percorso di rete include altri firewall). È anche necessario occuparsi della risoluzione DNS dal lato applicazione client.

Monitorare la disponibilità elevata

Per controllare lo stato di configurazione a disponibilità elevata del server, usare lo stato di disponibilità elevata nel riquadro a disponibilità elevata del server nel portale.

Stato Descrizione
NotEnabled La disponibilità elevata non è abilitata.
Replica di dati Il server standby viene sincronizzato con il server primario durante il provisioning del server a disponibilità elevata o quando si abilita l'opzione a disponibilità elevata.
Failover Il failover del server di database viene eseguito dal server primario al standby.
Integra l'opzione a disponibilità elevata è abilitata.
Rimozione della modalità standby Il processo di eliminazione è in corso quando si disabilita l'opzione a disponibilità elevata.

Per monitorare l'integrità del server a disponibilità elevata, usare le metriche seguenti.

Nome visualizzato per la metrica Metrica Unità Descrizione
Stato IO disponibilità elevata ha_io_running Stato Stato IO disponibilità elevata indica lo stato della replica a disponibilità elevata. Il valore della metrica è 1 se il thread di I/O è in esecuzione e 0 in caso contrario.
Stato SQL a disponibilità elevata ha_sql_running Stato Lo stato SQL a disponibilità elevata mostra lo stato della replica a disponibilità elevata. Il valore della metrica è 1 se il thread SQL è in esecuzione e 0 in caso contrario.
Ritardo replica a disponibilità elevata replication_lag Secondi Il ritardo di replica è il numero di secondi in cui lo standby è in ritardo nella riproduzione delle transazioni ricevute nel server primario.

Limitazioni

Quando si usa la disponibilità elevata, tenere presenti le considerazioni seguenti:

  • È possibile configurare la disponibilità elevata con ridondanza della zona solo durante la creazione del server.

  • Il livello di calcolo con possibilità di burst non supporta la disponibilità elevata.

  • Il riavvio del server di database primario per l'applicazione delle modifiche ai parametri statici consente anche di riavviare la replica del server di standby.

  • La soluzione attiva la modalità GTID perché usa GTID. Controllare se il carico di lavoro presenta restrizioni o limitazioni per la replica con GTID.

Note

L'aumento automatico dell'archiviazione è abilitato per impostazione predefinita per un server configurato a disponibilità elevata e non può essere disabilitato.

Controlli di integrità

Quando si configura la disponibilità elevata per Database di Azure per MySQL, i controlli di integrità svolgono un ruolo fondamentale per mantenere l'affidabilità e le prestazioni del database. Questi controlli monitorano continuamente lo stato e l'integrità delle repliche primarie e di standby, assicurando che eventuali problemi vengano rilevati tempestivamente. Monitorando varie metriche, ad esempio velocità di risposta del server, ritardo della replica e utilizzo delle risorse, i controlli di integrità contribuiscono a garantire che i processi di failover possano essere eseguiti senza problemi, riducendo al minimo i tempi di inattività e impedendo la perdita di dati. I controlli di integrità configurati correttamente sono essenziali per ottenere il livello desiderato di disponibilità e resilienza nella configurazione del database.

Monitoraggio dell'integrità

È possibile monitorare l'integrità della configurazione della disponibilità elevata tramite il portale di Azure. Le metriche chiave da osservare includono:

  • Velocità di risposta del server: indica se il server primario è raggiungibile.
  • Ritardo replica: misura il ritardo tra le repliche primarie e di standby, garantendo la coerenza dei dati.
  • Utilizzo delle risorse: monitora l'utilizzo di CPU, memoria e archiviazione per evitare colli di bottiglia.

Contenuti correlati

  • Last updated on