Concetti relativi alla disponibilità elevata nel server flessibile di Database di Azure per MySQL

  • Articolo

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

Database di Azure per MySQL server flessibile consente di configurare la disponibilità elevata con failover automatico. La soluzione a disponibilità elevata è progettata per garantire che i dati di cui è stato eseguito il commit non vadano mai persi a causa di errori e che il database non sia un singolo punto di guasto nell'architettura del software. Quando è configurata la disponibilità elevata, il server flessibile esegue automaticamente il provisioning e gestisce una replica di standby. Vengono addebitati i costi per il calcolo e l'archiviazione di cui è stato effettuato il provisioning per la replica primaria e secondaria. Esistono due modelli architetturali a disponibilità elevata:

  • Disponibilità elevata con ridondanza della zona. Questa opzione è preferibile per l'isolamento completo e la ridondanza dell'infrastruttura in più zone di disponibilità. Offre il massimo livello di disponibilità, ma richiede la configurazione della ridondanza dell'applicazione tra le zone. La disponibilità elevata con ridondanza della zona è preferibile quando si vuole ottenere il massimo livello di disponibilità in caso di errore dell'infrastruttura nella zona di disponibilità e quando la latenza nella zona di disponibilità è accettabile. Può essere abilitata solo quando viene creato 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 condivisioni file Premium con ridondanza della zona.

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

Architettura a disponibilità elevata con ridondanza della zona

Quando si distribuisce un server con disponibilità elevata con ridondanza della zona, verranno creati due server:

  • Un server primario in una zona di disponibilità.
  • 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) in un'altra zona di disponibilità della stessa area di Azure.

È possibile scegliere la zona di disponibilità per la replica primaria e quella di standby. L'inserimento dei server di database di standby e delle applicazioni standby nella stessa zona riduce la latenza. Consente anche di preparare meglio le situazioni di ripristino di emergenza e gli 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, protetto dalla replica a livello di archiviazione.

Se è presente un failover:

  • La replica standby è 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 standby e l'applicazione dei log binari, il server di replica standby corrente assume il ruolo del server primario. DNS viene aggiornato in modo che le connessioni client vengano indirizzate 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 viene usato per connettere 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 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 della stessa zona

Quando si distribuisce un server con disponibilità elevata nella stessa zona, vengono creati 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 della stessa zona.

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 è presente un failover:

  • La replica standby è 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 viene usato per connettere 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 della stessa zona non fornisce disponibilità elevata quando le infrastrutture dipendenti sono inattivo 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.

Nota

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

  • Se si verifica un errore, il tempo necessario per la replica di standby per assumere il ruolo di primario dipende dal tempo necessario per riprodurre il log binario dall'account di archiviazione primario allo standby. È quindi consigliabile usare chiavi primarie in tutte le tabelle per ridurre il tempo di failover. 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 è presente 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

Pianificato: failover forzato

Database di Azure per MySQL failover forzato del server flessibile 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 standby. Le connessioni client vengono disconnesse e devono essere riconnesse per riprendere le operazioni.

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

Nota

L'evento Integrità risorse di Azure viene generato in caso di failover pianificato, che rappresenta il tempo di failover durante il quale il server non era disponibile. Gli eventi attivati possono essere visualizzati quando si fa clic su "Integrità risorse" nel riquadro sinistro. Il failover manuale avviato dall'utente è rappresentato dallo stato "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 ti assisteremo.

Non pianificato: failover automatico

Il tempo di inattività del servizio non pianificato può essere causato da bug software o errori dell'infrastruttura, ad esempio errori di calcolo, rete o archiviazione o interruzioni dell'alimentazione che influiscono sulla disponibilità del database. Se il database non è più disponibile, la replica viene gestita nella replica di standby e questa viene attivata come server di database primario. DNS viene aggiornato e i client si riconnettono al server di database e riprendono le operazioni.

Il tempo di failover complessivo dovrebbe essere 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.

Nota

L'evento Integrità risorse di Azure viene generato in caso di failover non pianificato, che rappresenta il tempo di failover durante il quale il server non era disponibile. Gli eventi attivati possono essere visualizzati quando si fa clic su "Integrità risorse" nel riquadro sinistro. Il failover automatico è rappresentato dallo stato "Non disponibile" e contrassegnato come "Non pianificato". Esempio: "Non disponibile: un'operazione di failover è stata attivata automaticamente (non pianificata)". Se la risorsa rimane in questo stato per un lungo periodo di tempo, aprire un ticket di supporto e ti assisteremo.

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

Il server primario e il server secondario hanno due endpoint di rete,

  • Endpoint cliente: il cliente si connette ed esegue 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 effettua il ping all'endpoint di rete di gestione dei nodi. Se questo controllo ha esito negativo due volte in modo continuo, attiva l'operazione di failover automatico. Lo scenario come il nodo non è disponibile o non risponde a causa di un problema del sistema operativo, il problema di rete tra i componenti di gestione e i nodi e così via verrà risolto da questo controllo integrità.
  • Il monitoraggio esegue anche una query semplice nell'istanza di . Se l'esecuzione delle query non riesce, verrà attivato il failover automatico. Gli scenari come il demone MySQL si arresta/ si arresta/è bloccato, il problema di archiviazione back-end e così via, verrà risolto da questo controllo di integrità.

Nota

Se si verificano problemi di rete tra l'applicazione e l'endpoint di rete del cliente (accesso privato/pubblico), nel percorso di rete , nell'endpoint o nei problemi DNS sul lato client, il controllo integrità non monitora questo scenario. 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 rete 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 la risoluzione DNS dal lato applicazione client deve essere presa in considerazione.

Monitoraggio della disponibilità elevata

Lo stato di disponibilità elevata disponibile nel riquadro Disponibilità elevata del server nel portale può essere usato per determinare lo stato di configurazione della disponibilità elevata del server.

Stato Descrizione
NotEnabled La disponibilità elevata non è abilitata.
Replica diData Il server standby è in fase di sincronizzazione con il server primario al momento del provisioning del server a disponibilità elevata o quando è abilitata l'opzione disponibilità elevata.
Failover Il server di database è in corso di failover dal server primario al standby.
Integra L'opzione a disponibilità elevata è abilitata.
RemovingStandby Quando l'opzione a disponibilità elevata è disabilitata e il processo di eliminazione è in corso.

È anche possibile usare le metriche seguenti per monitorare l'integrità del server a disponibilità elevata.

Nome visualizzato della metrica Metric Unità Descrizione
Stato di I/O a disponibilità elevata ha_io_running Provincia Lo stato di I/O a 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 Provincia Stato SQL a disponibilità elevata indica 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.

Limiti

Di seguito sono riportate alcune considerazioni da tenere presenti quando si usa la disponibilità elevata:

  • La disponibilità elevata con ridondanza della zona può essere impostata solo quando viene creato il server flessibile.
  • La disponibilità elevata non è supportata nel livello di calcolo con burst.
  • Il riavvio del server di database primario per la selezione delle modifiche ai parametri statici consente anche di riavviare la replica del server di standby.
  • La modalità GTID verrà attivata perché la soluzione a disponibilità elevata usa GTID. Controllare se il carico di lavoro presenta restrizioni o limitazioni per la replica con GTID.

Nota

Se si abilita la disponibilità elevata della stessa zona dopo la creazione del server, è necessario assicurarsi che i parametri del server enforce_gtid_consistency" e "gtid_mode" siano impostati su ON prima di abilitare la disponibilità elevata.

Nota

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

Domande frequenti

  • Quali sono i contratti di servizio per il server flessibile con disponibilità elevata con ridondanza della zona e con ridondanza della zona?

    Le informazioni sul contratto di servizio per Database di Azure per MySQL server flessibile sono disponibili in Contratto di servizio per Database di Azure per MySQL.

  • Come vengono fatturati i server a disponibilità elevata? I server abilitati con disponibilità elevata hanno una replica primaria e una replica secondaria. La replica secondaria si può trovare nella stessa zona o può offrire la ridondanza della zona. Vengono addebitati i costi per il calcolo e l'archiviazione di cui è stato effettuato il provisioning per la replica primaria e secondaria. Se ad esempio hai una replica primaria con 4 vCore di risorse di calcolo e 512 GB di risorse di archiviazione con provisioning, anche la replica secondaria avrà 4 vCore e 512 GB di risorse di archiviazione con provisioning. Per il server a disponibilità elevata con ridondanza della zona verranno quindi applicati addebiti pari a 8 vCore e 1.024 GB di risorse di archiviazione. In base al volume dell'archivio di backup, è possibile che ti venga addebitato anche l'archivio di backup.

  • È possibile usare la replica standby per operazioni di lettura o scrittura?
    Il server standby non è disponibile per le operazioni di lettura o scrittura. Si tratta di uno standby passivo per abilitare il failover rapido.

  • Si verifica una perdita di dati quando si verifica il failover?
    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 standby e l'applicazione dei log binari, assume il ruolo del server primario.

  • È necessario eseguire un'azione dopo un failover?
    I failover sono completamente trasparenti dall'applicazione client. Non è necessario eseguire alcuna azione. Le applicazioni devono usare solo la logica di ripetizione dei tentativi per le connessioni.

  • Cosa accade quando non si sceglie una zona specifica per la replica di standby? È possibile modificare la zona in un secondo momento?
    Se non si sceglie una zona, ne verrà selezionata una in modo casuale. Sarà quello usato per il server primario. Per modificare la zona in un secondo momento, è possibile impostare Disponibilità elevata su Disabilitato nel riquadro Disponibilità elevata e quindi impostarlo di nuovo su Ridondanza della zona e scegliere una zona.

  • La replica tra le repliche primarie e di standby è sincrona?
    La replica tra il database primario e lo standby è simile alla modalità semisincrona in MySQL. Quando viene eseguito il commit di una transazione, non viene necessariamente eseguito il commit nello standby. Tuttavia, quando il database primario non è disponibile, lo standby replica tutte le modifiche ai dati dal database primario per assicurarsi che non si verifichi alcuna perdita di dati.

  • Esiste un failover nella replica di standby per tutti gli errori non pianificati?
    Se si verifica un arresto anomalo del database o un errore del nodo, la macchina virtuale del server flessibile viene riavviata nello stesso nodo. Allo stesso tempo, viene attivato un failover automatico. Se il riavvio della macchina virtuale del server flessibile ha esito positivo prima del completamento del failover, l'operazione di failover verrà annullata. La determinazione del server da usare come replica primaria dipende dal processo che termina per primo.

  • Si verifica un impatto sulle prestazioni quando si usa la disponibilità elevata?
    Per la disponibilità elevata con ridondanza della zona, mentre non vi è un impatto significativo sulle prestazioni per i carichi di lavoro di lettura tra zone di disponibilità, potrebbe esserci un calo fino al 40% della latenza delle query di scrittura. L'aumento della latenza di scrittura è dovuto alla replica sincrona nella zona di disponibilità. L'impatto sulla latenza di scrittura è in genere due volte nella disponibilità elevata con ridondanza della zona rispetto alla stessa disponibilità elevata della zona. Per la disponibilità elevata della stessa zona, perché la replica primaria e di standby si trova nella stessa zona, la latenza di replica e di conseguenza la latenza di scrittura sincrona è inferiore. In sintesi, se la latenza di scrittura è più critica rispetto alla disponibilità, è consigliabile scegliere la disponibilità elevata della stessa zona, ma se la disponibilità e la resilienza dei dati sono più importanti a scapito dell'eliminazione della latenza di scrittura, è necessario scegliere la disponibilità elevata con ridondanza della zona. Per misurare l'impatto accurato del calo della latenza nella configurazione a disponibilità elevata, è consigliabile eseguire test delle prestazioni per il carico di lavoro per prendere una decisione informata.

  • In che modo viene eseguita la manutenzione del server a disponibilità elevata?
    Gli eventi pianificati, ad esempio il ridimensionamento delle versioni secondarie e di calcolo, vengono eseguiti prima nell'istanza di standby originale e seguiti dall'attivazione di un'operazione di failover pianificata e quindi operano sull'istanza primaria originale. È possibile impostare la finestra di manutenzione pianificata per i server a disponibilità elevata come per i server flessibili. La quantità di tempo di inattività corrisponde al tempo di inattività per l'istanza del server flessibile Database di Azure per MySQL quando la disponibilità elevata è disabilitata.

  • È possibile eseguire un ripristino temporizzato del server a disponibilità elevata?
    È possibile eseguire un ripristino temporizzato per un'istanza del server flessibile Database di Azure per MySQL abilitata per la disponibilità elevata in una nuova istanza del server flessibile Database di Azure per MySQL disabilitata. Se il server di origine è stato creato con disponibilità elevata con ridondanza della zona, è possibile abilitare la disponibilità elevata con ridondanza della zona o la stessa zona nel server ripristinato in un secondo momento. Se il server di origine è stato creato con disponibilità elevata nella stessa zona, è possibile abilitare solo la disponibilità elevata della stessa zona nel server ripristinato.

  • È possibile abilitare la disponibilità elevata in un server dopo aver creato il server?
    La disponibilità elevata con ridondanza della zona deve essere abilitata quando viene creato il server. È possibile abilitare la disponibilità elevata della stessa zona dopo aver creato il server. Prima di abilitare la stessa disponibilità elevata della zona, assicurarsi che i parametri del server enforce_gtid_consistency" e "gtid_mode" sia impostato su ON

  • È possibile disabilitare la disponibilità elevata per un server dopo averlo creato?
    È possibile disabilitare la disponibilità elevata in un server dopo averlo creato. La fatturazione si arresta immediatamente.

  • Come è possibile ridurre i tempi di inattività?
    È necessario essere in grado di ridurre i tempi di inattività per l'applicazione anche quando non si usa la disponibilità elevata. Tempi di inattività del servizio, ad esempio patch pianificate, aggiornamenti di versioni secondarie o operazioni avviate dal cliente, ad esempio il ridimensionamento delle risorse di calcolo, possono essere eseguite durante le finestre di manutenzione pianificate. Per ridurre l'impatto dell'applicazione per le attività di manutenzione avviate da Azure, è possibile pianificarle in un giorno della settimana e l'ora che riduce al minimo l'impatto sull'applicazione.

  • È possibile usare una replica in lettura per un server abilitato per la disponibilità elevata?
    Sì, le repliche in lettura sono supportate per i server a disponibilità elevata.

  • È possibile usare la replica dei dati in ingresso per i server a disponibilità elevata?
    Il supporto per la replica dei dati per il server abilitato per la disponibilità elevata è disponibile solo tramite la replica basata su GTID. La stored procedure per la replica tramite GTID è disponibile in tutti i server abilitati per la disponibilità elevata in base al nome mysql.az_replication_with_gtid.

  • Per ridurre i tempi di inattività, è possibile eseguire il failover nel server di standby durante i riavvii del server o durante l'aumento o la riduzione delle prestazioni?
    Attualmente, Database di Azure per MySQL server flessibile ha utlizzato failover pianificato per optare per le operazioni a disponibilità elevata, tra cui l'aumento/riduzione delle prestazioni e la manutenzione pianificata per ridurre i tempi di inattività. All'avvio di tali operazioni, viene eseguita prima sull'istanza di standby originale, seguita dall'attivazione di un'operazione di failover pianificata e quindi sull'istanza primaria originale.

  • È possibile modificare la modalità di disponibilità (disponibilità elevata/stessa zona con ridondanza della zona) del server
    Se si crea il server con la modalità a disponibilità elevata con ridondanza della zona abilitata, è possibile passare dalla disponibilità elevata con ridondanza della zona alla stessa zona e viceversa. Per modificare la modalità di disponibilità, è possibile impostare Disponibilitàelevata su Disabilitato nel riquadro Disponibilità elevata e quindi impostarlo di nuovo su Ridondanza della zona o sulla stessa zona e scegliere Modalità disponibilità elevata.

Passaggi successivi