Cos'è MySQL High Availability?

MySQL High Availability è un'opzione attivabile in modo che il database MySQL resti disponibile in caso di guasto o interruzione. Questa funzionalità consente di impostare requisiti superiori per il tempo di attività e una tolleranza alla perdita dei dati pari a zero. In questo articolo descriveremo il concetto generale di alta disponibilità e come funziona l'opzione MySQL High Availability. 

Cos'è l'alta disponibilità?

Con alta disponibilità si intende la capacità di un sistema o servizio di funzionare e restare disponibile anche in caso di guasto o interruzione. In un'architettura ad alta disponibilità, quindi, i sistemi e le applicazioni mission critical di un'organizzazione sono sempre attivi e in funzione. È particolarmente importante per le aziende dei settori sanitario, finanziario e aeronautico, dove il guasto di un sistema mission critical potrebbe comportare gravi conseguenze.

L'alta disponibilità è espressa in percentuale in base al tempo di attività e definita nei Service Level Agreement (SLA): 100 è il valore massimo per indicare un sistema che non si guasta mai. Essendo un valore praticamente irraggiungibile, la maggior parte delle organizzazioni punta a ottenere una disponibilità a "cinque nove", ossia del 99,999%.

Come MySQL raggiunge l'alta disponibilità

Un sistema altamente disponibile deve essere in grado di rientrare subito in funzione quando si verifica un guasto. Per assicurare la ripristinabilità e l'alta disponibilità, sono necessari almeno tre fattori basilari:

Rilevamento dei guasti

L'opzione High Availability di MySQL consente alle applicazioni di soddisfare i requisiti per un maggiore tempo di attività e una tolleranza zero alle perdite dei dati. Quando questa opzione è attiva, il sistema MySQL crea tre istanze in diversi domini di errore o zone di disponibilità.

I dati vengono replicati in queste tre istanze utilizzando la funzione MySQL Group Replication e le applicazioni si collegano all'istanza primaria per la lettura e la scrittura dei dati da e verso il database. In caso di guasto, il sistema attiva il failover automatico sulla seconda istanza nel giro di pochi minuti.

Failover

Il meccanismo di failover permette di trasferire i servizi a un'istanza replicata. Se sono disponibili più istanze di backup, il meccanismo di failover sceglie quella più adatta promuovendola a nodo primario. 

Meccanismo di reindirizzamento

Dopo il failover sull'istanza secondaria, l'alta disponibilità reindirizza tutti i collegamenti di applicazioni e utenti al nuovo nodo primario, reindirizzando inoltre tutte le query dal precedente nodo primario al nuovo database primario. 

MySQL High Availability: tempo di attività

Con tempo di attività si intende il tempo durante il quale un sistema è disponibile e funziona correttamente. È espresso in percentuale in base al tempo totale di operatività previsto. Se la percentuale è alta, vuol dire che il sistema è disponibile e funziona correttamente per la maggior parte del tempo previsto. 

Il tempo di attività associato ai diversi livelli di MySQL High Availability dipenderà dalla soluzione di alta disponibilità (HA) implementata.

MySQL Replication

MySQL Replication consente di configurare più server per fornire ridondanza e failover in modo da supportare tempi di attività più elevati rispetto a un server senza funzionalità HA. La configurazione di server master-slave comprende un server master che accetta operazioni di lettura e scrittura o più server slave di sola lettura. I dati del server master vengono replicati in modo asincrono nei server slave.

Per implementare il failover è necessario configurare uno o più server slave di stand-by in modo che possano essere innalzati a livello master in caso di guasto. Il failover consiste in un processo manuale in cui è necessario innalzare di livello il nodo slave a nodo master modificando lo stato del nodo passato alla modalità di lettura-scrittura affinché possa accettare le query.

Poiché il failover è un'operazione manuale, richiede più tempo e potrebbe dare luogo a errori umani, prolungando l'interruzione. MySQL Replication utilizza anche la replica asincrona: se il server master dovesse subire un guasto, le operazioni confermate su quest'ultimo potrebbero non essere state ancora replicate sui server slave. In caso di perdita di dati cruciali, questi dovranno essere ripristinati, prolungando i tempi di fermo.

MySQL Group Replication

Con MySQL Group Replication si possono raggiungere tempi di attività superiori rispetto alla replica semplice. MySQL Group Replication, infatti, permette di configurare più server MySQL in un gruppo, dove un server funge da nodo primario e gli altri da nodi secondari. Ogni server nel gruppo conserva una copia dei dati e utilizza la replica per garantire che le copie siano sincronizzate. 

Se il server primario va fuori uso, i server secondari nel gruppo rilevano automaticamente il guasto e avviano il processo di failover. Uno dei server secondari viene promosso automaticamente a nuovo server primario e comincia a rispondere alle richieste dei client. Gli altri server secondari ricevono gli aggiornamenti dal nuovo server primario e continuano a elaborare le richieste di lettura dei client.

Quando il server guasto ritorna online, rientra automaticamente nel gruppo come server secondario.

Poiché con MySQL Group Replication i meccanismi di rilevamento dei guasti e failover si attivano automaticamente, il downtime è minimo e viene a malapena rilevato da utenti e applicazioni. 

MySQL Cluster

La soluzione HA MySQL Cluster offre il massimo tempo di attività. Questo sistema di database distribuito altamente disponibile, con failover e bilanciamento del carico automatici, offre disponibilità, performance e scalabilità elevate ed è progettato per un downtime quasi pari a zero. 

MySQL Cluster utilizza tre tipi di nodi che interagiscono per archiviare e gestire i dati:

• Nodi di dati: archiviano i dati e gestiscono le query di lettura e scrittura.
• Nodi di server MySQL: ricevono le query dalle applicazioni client, le elaborano sui nodi di dati e quindi restituiscono il risultato ai client.
• Nodi di gestione: gestiscono il funzionamento del cluster e le operazioni di failover e ripristino in caso di guasto.

Se uno o più nodi del cluster smettono di funzionare, il cluster rileva automaticamente il problema e attiva il processo di failover. Tutto avviene entro un secondo dal guasto, senza interrompere il servizio verso le applicazioni client. Il cluster continua a funzionare, praticamente senza downtime.

MySQL High Availability: tempo di ripristino 

Il tempo di ripristino indica quanto impiega un sistema MySQL a riprendersi da un'interruzione. Tempi di ripristino più lunghi riducono la disponibilità e possono influire direttamente sulla capacità dell'azienda di generare profitti, sulla produttività del personale e sulla soddisfazione dei clienti.

In MySQL, i tempi di ripristino variano a seconda del tipo di replica utilizzata:

• Con MySQL Replication, i tempi di ripristino per la replica master-slave dipendono dal processo di failover manuale. Una volta promosso il server slave a nuovo nodo primario, questo dovrà essere riavviato affinché possa replicare i dati sugli altri server slave. Quindi bisognerà tener conto delle operazioni non eseguite e risolvere eventuali conflitti.
• MySQL Group Replication utilizza un processo automatico di rilevamento dei guasti e failover che comporta tempi di ripristino più brevi rispetto alla replica master-slave. I meccanismi di rilevamento e risoluzione dei conflitti assicurano che i dati di ciascun server siano sempre sincronizzati in tutti server del gruppo. La replica di gruppo utilizza inoltre tipi di dati replicati privi di conflitto (CRDT) che consentono la riconciliazione automatica dei dati in caso di conflitto. Con la replica di gruppo, il sistema è in grado di ripristinarsi da un guasto con un downtime brevissimo.
• MySQL Cluster utilizza un approccio di tipo "shared nothing", vale a dire che ogni nodo nel cluster ha la propria memoria e il proprio storage su disco e comunica con gli altri tramite una connessione ad alta velocità. MySQL Cluster continua a funzionare anche se uno o più nodi non rispondono. Il cluster rileva automaticamente il problema e attiva il processo di failover per il ripristino praticamente senza downtime.

Come determinare i requisiti di MySQL HA

Per determinare i requisiti di MySQL High Availability, si dovranno considerare diversi fattori, tra cui:

• Architettura di sistema attuale: quali componenti comprende il sistema attuale e come sono configurati? Possono supportare MySQL High Availability?
• Budget: quanto bisogna investire in risorse umane, hardware e software? Un’altra voce da considerare riguarda i costi di formazione e manutenzione continua.
• Esigenze aziendali: valutare gli obiettivi RPO (Recovery Point Objective) e RTO (Recovery Time Objective). Quali sono i tempi di ripristino ideali? Entro quando il sistema deve essere ripristinato? Considerare se ci sono requisiti normativi o di conformità specifici che richiedono l'alta disponibilità.
• Criticità dei dati: qual è il livello di criticità dei dati aziendali? Quanto è importante che siano aggiornati? In che misura è consentita la perdita di dati?

Quando utilizzare MySQL High Availability

Esaminiamo un paio di casi d'uso che richiedono soluzioni MySQL High Availability.

Siti Web con traffico elevato

I siti Web con traffico elevato gestiscono migliaia di query e operazioni al secondo, oltre a migliaia di utenti in contemporanea. Misure come la ridondanza dei server e il bilanciamento del carico possono garantire la disponibilità del database e reggere il carico. 

Grazie ai server ridondanti, il sito Web resta disponibile anche in caso di interruzione, mentre il bilanciamento del carico delle richieste in entrata tra i server evita il sovraccarico e la disconnessione di un unico server.

Applicazioni e workload mission critical

Le aziende con sistemi e applicazioni mission critical richiedono un alto livello di disponibilità e tempo di attività. Il più delle volte, questi sistemi non possono permettersi un downtime e il database deve essere sempre disponibile. 

Le soluzioni HA come MySQL Group Replication o MySQL Cluster sono ideali in questo caso, perché impiegano un meccanismo di failover automatico che comporta un downtime brevissimo o nullo.

Come Pure Storage supporta MySQL High Availability

Pure Storage® Evergreen™ è un portafoglio di abbonamenti per deployment a zero downtime. Abbinato all'architettura di array storage di Pure Storage, Evergreen permette di aggiornare l'infrastruttura di storage senza interrompere i workload di servizio. 

Pure supporta inoltre i cluster active-active e il failover automatico e trasparente grazie a Purity ActiveCluster™, uno stretched cluster active-active multisito con RPO e RTO pari a zero.

Un'altra soluzione utile è  Pure Cloud Block Store™, che offre un'affidabilità cloud di livello enterprise per le applicazioni mission critical. Gli aggiornamenti non disruptive e l'alta disponibilità nelle diverse zone di disponibilità garantiscono la business continuity e il disaster recovery multi-cloud.