Condividi tramite

Disponibilità elevata in Azure Database for MySQL

Usando Azure Database for MySQL Flexible Server, è possibile configurare l'alta disponibilità 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 l'alta disponibilità, Flexible Server provvede automaticamente al provisioning e alla gestione di una replica secondaria. 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 un isolamento completo e una ridondanza dell'infrastruttura su più zone di disponibilità. Offre il massimo livello di disponibilità, ma richiede di configurare la ridondanza dell'applicazione tra le zone. Scegliere l'alta disponibilità con ridondanza zonale quando si desidera proteggersi da qualsiasi guasto dell'infrastruttura nella zona di disponibilità e quando la latenza tra le zone di disponibilità è accettabile. È possibile abilitare l'alta disponibilità con ridondanza di zona solo quando si crea il server. La disponibilità elevata con ridondanza della zona è disponibile in un sottoinsieme di aree di Azure dove l'area supporta più zone di disponibilità e dove sono disponibili condivisioni file Premium con ridondanza della zona.

  • 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 la 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 Azure in cui puoi utilizzare Azure Database for MySQL Flexible Server.

Architettura a disponibilità elevata con ridondanza della zona

Quando si distribuisce un server con alta disponibilità con ridondanza a livello di zona, Azure crea due server:

  • Un server primario in una zona di disponibilità.
  • Un server di replica standby in un'altra zona di disponibilità della stessa area Azure. Il server di replica standby ha la stessa configurazione del server primario, tra cui il livello di calcolo, le dimensioni di calcolo, le dimensioni di calcolo, le dimensioni storage e la 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 anche di preparare le situazioni di ripristino di emergenza e gli scenari di riduzione della zona.

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

I file di dati e di log sono ospitati in zone-redundant storage (ZRS). 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. Gli aggiornamenti DNS fanno sì che le connessioni client si dirigano al nuovo 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 standby per 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 sincrona utilizzata nell'archiviazione ZRS, è possibile prevedere un aumento della latenza del 5-10% per le operazioni di scrittura e commit delle applicazioni.

Il server di database primario esegue automaticamente il backup sia degli snapshot che dei backup del registro su storage ridondante per zona.

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 calcolo, dimensioni storage e configurazione di rete)

Il server standby offre ridondanza dell'infrastruttura usando 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 in storage 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 sono rese disponibili 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 inattive nella 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à.

Il server primario del database esegue automaticamente il backup sia di snapshot che di log su uno storage con ridondanza locale.

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 connection string.

Processo di failover

Durante il processo di failover in Azure Database for 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 ad alta disponibilità creati con accesso pubblico o collegamento privato adotteranno la nuova architettura con un SLB dedicato per ogni server ad alta disponibilità. 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 vengono migrati gradualmente per minimizzare 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 access privati con l'integrazione della rete virtuale.

Pianificato: failover forzato

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

Il failover forzato avvia il processo che consente alla replica standby di diventare il server primario, utilizzando lo stesso nome del server di database e 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 Azure Resource Health viene generato durante un failover pianificato. L'evento rappresenta il tempo di failover durante il quale il server non è disponibile. Quando si seleziona Resource Health nel riquadro sinistro, è possibile visualizzare gli eventi attivati. Lo stato rappresenta il failover manuale o avviato dall'utente come Non disponibile e contrassegnato come Pianificato. Ad esempio, un'operazione di failover è stata attivata da un utente autorizzato (Pianificato).For example, A failover operation was triggered by an authorized user (Planned). Se la risorsa rimane in questo stato per un periodo prolungato, aprire un ticket support e ti assistiamo.

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 storage. 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 Azure Resource Health 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 Resource Health 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 support e ti aiutiamo.

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 alle storage 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 rete 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à prende in esame scenari come arresti anomali, arresti o blocchi del daemon MySQL e problemi di backend storage e problematiche analoghe.

Note

Il controllo di integrità non monitora i problemi di rete tra l'applicazione e l'endpoint di rete del cliente (accesso privato/pubblico). Questi problemi possono verificarsi nel percorso di rete, 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 le access pubbliche, 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 si sincronizza 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 disponibilità elevata ha_io_running Stato Stato 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 l'alta disponibilità ridondante a livello di zona soltanto 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

Crescita automatica dello storage è abilitata per impostazione predefinita per un server configurato per alta disponibilità e non può essere disabilitata.

Problemi noti

Il server flessibile di Database di Azure per MySQL usa la replica MySQL nativa nel back-end. Esiste un problema noto in MySQL Community Edition 8.0 e versioni successive che possono interrompere la replica quando si esegue un'operazione DELETE multitable che si basa su vincoli di chiave esterna con ON DELETE CASCADE. Questo problema viene rilevato come 102586 bug di MySQL. Di conseguenza, quando si abilita la disponibilità elevata in Azure Database for MySQL Flexible Server, evitare di usare eliminazioni a catena con chiavi esterne, poiché questo schema può causare errori di replica e potrebbe influire sulla disponibilità del server.

Controlli di integrità

Quando si configura la disponibilità elevata per Azure Database for MySQL, i controlli di integrità svolgono un ruolo fondamentale nella gestione dell'affidabilità e delle prestazioni del database. Questi controlli monitorano continuamente lo stato e l'integrità delle repliche primarie e standby, assicurandosi di rilevare tempestivamente eventuali problemi. 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 storage per evitare colli di bottiglia.

Contenuti correlati

  • Disponibilità elevata
  • Continuità aziendale
  • Disponibilità elevata con ridondanza della zona
  • backup e ripristino
  • Last updated on