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

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

Il Server Flessibile di Database di Azure per MySQL 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 effettua automaticamente il provisioning e gestisce una replica di standby. All'utente viene addebitato sia il calcolo che 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 le condivisioni file Premium con ridondanza della zona sono disponibili.

• 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 della 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 in una zona di disponibilità diversa con la stessa configurazione del server primario, inclusi il livello di calcolo, le dimensioni di calcolo, le dimensioni di archiviazione e la configurazione della rete.

È 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".

I file di dati e di log sono ospitati nell'archiviazione con ridondanza della zona (ZRS). Il server di 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 di standby è attivata.
• I file di log binari del server primario continuano a essere applicati al server di 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 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 dei log, vengono eseguiti dal server di database primario e archiviati in un’archiviazione con ridondanza della zona.

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, inclusi il livello di calcolo, le dimensioni di calcolo, le dimensioni di archiviazione e la configurazione della rete

Il server di standby offre ridondanza dell'infrastruttura con una macchina virtuale separata (calcolo). Questa ridondanza riduce il tempo di failover e la latenza di rete tra l'applicazione e il server database per la coubicazione.

I dati e i file di log sono ospitati nell'archiviazione con ridondanza locale (LRS). Il server di 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 di standby è attivata.
• I file di log binari del server primario continuano a essere applicati al server di 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 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 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 inattive per la zona di disponibilità specifica. Si verifica tempo inattivo fino a quando tutti i servizi dipendenti non tornano online per la zona di disponibilità.

I backup automatici, sia snapshot che i backup del log, vengono eseguiti dal server di database primario e archiviati in un’archiviazione con ridondanza locale.

Nota

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

• 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. È 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 di 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 A DNS 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: il failover forzato del Server Flessibile consente di forzare manualmente un failover. Questa funzionalità consente di testare la funzionalità con gli scenari dell'applicazione e consente di prepararsi a eventuali 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 a sinistra. 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 per ricevere assistenza.

Non pianificato: failover automatico

I tempi di inattività del servizio non pianificati possono essere causati da bug software o errori dell'infrastruttura come 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 database e riprendono le operazioni.

Il tempo di failover complessivo dovrebbe essere compreso tra 60 e 120 secondi. Ma, a seconda dell'attività nel server di database primario, ad esempio transazioni di grandi dimensioni e tempo di ripristino, al momento del failover, il processo 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 a sinistra. 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 per ricevere assistenza.

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 Health Monitor 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/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. Se l'esecuzione delle query non riesce, verrà attivato il failover automatico. Gli scenari come il daemon MySQL che si arresta o blocca, il problema di archiviazione back-end e così via, verranno risolti 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 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 lato applicazione client deve essere risolta.

Monitorare la 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	Disponibilità elevata non abilitata.
ReplicatingData	Il server di 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.
FailingOver	Viene effettuato il failover del server di database primario nel server di standby.
Integra	L'opzione di 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 viene eseguito e 0 in caso contrario.
Stato SQL a disponibilità elevata	ha_sql_running	Provincia	Lo stato di SQL a disponibilità elevata indica lo stato della replica a disponibilità elevata. Il valore della metrica è 1 se il thread SQL viene eseguito e 0 in caso contrario.
Ritardo della replica a disponibilità elevata	replication_lag	Secondi	Il ritardo della replica a disponibilità elevata è il numero di secondi in cui il server standby a disponibilità elevata è in ritardo nella riproduzione delle transazioni ricevute dal 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 con il livello di calcolo con possibilità di 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 stessa area a disponibilità elevata 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

L'aumento automatico dell'archiviazione è abilitato per impostazione predefinita per server configurati 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 nella stessa zona?

  Le informazioni sul contratto di servizio per Server Flessibile di Database di Azure per MySQL sono disponibili in Contratto di servizio per Database di Azure per MySQL.

• Come vengono fatturati i server con 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. All'utente viene addebitato sia il calcolo che 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 di 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 avviene 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à quella usata per il server primario. Per modificare la zona in un secondo momento, è possibile impostare Disponibilità elevata su Disabilitata nel riquadro Disponibilità elevata, quindi impostare di nuovo su Ridondanza della zona e scegliere una zona.
  

• La replica tra le repliche primarie e quelle di standby è sincrona?
  La replica tra il database primario e quello di 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.
  

• C’è 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 doppio nella disponibilità elevata con ridondanza della zona rispetto alla disponibilità elevata nella stessa zona. Per la disponibilità elevata nella 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 nella 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 un 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 inattivo 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 dove la disponibilità elevata è 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 nella stessa zona dopo aver creato il server. Prima di abilitare la disponibilità elevata nella stessa zona, assicurarsi che i parametri del server "enforce_gtid_consistency" e "gtid_mode" siano impostati su ON
  

• È possibile disabilitare la disponibilità elevata in 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 inattivi?
  È necessario essere in grado di ridurre i tempi inattivi 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 sull'applicazione per le attività di manutenzione avviate da Azure, è possibile pianificarle in un giorno della settimana e un'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 in ingresso su 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 inattivi, è possibile eseguire il failover nel server di standby durante i riavvii del server o durante l'aumento o la riduzione delle prestazioni?
  Attualmente, Server Flessibile di Database di Azure per MySQL ha utlizzato il 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, vengono eseguite 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 Disabilitata nel riquadro Disponibilità elevata e quindi impostarla di nuovo su Ridondanza della zona o sulla stessa zona e scegliere Modalità disponibilità elevata.
  

Passaggi successivi

• Informazioni sulla continuità aziendale.
• Informazioni sulla disponibilità elevata con ridondanza della zona.
• Informazioni su backup e ripristino.