MySQL senza downtime: Master-Master o Galera Cluster

Finché il traffico resta contenuto, una singola istanza MySQL regge senza problemi. Il quadro cambia quando un e-commerce raggiunge picchi reali: ordini simultanei, carrelli attivi, stock che cambia in tempo reale, cron e integrazioni che scrivono sullo stesso database. A quel punto MySQL diventa due cose insieme: il collo di bottiglia delle prestazioni e il punto di guasto unico dell'intera piattaforma.

La domanda non è più se serva alta affidabilità. La domanda è: quale compromesso sei disposto ad accettare fra coerenza, latenza, complessità e tempi di ripristino?

Il dilemma dell'e-commerce

In un gestionale interno un ritardo di replica può essere tollerabile. In un e-commerce, su ordini e magazzino, molto meno. Una giacenza sbagliata genera vendite non evadibili. Un ordine perso genera danno diretto. Un database che accetta scritture divergenti durante una partizione di rete può creare una situazione peggiore del downtime: dati incoerenti da riconciliare a mano.

Per questo, prima di scegliere la tecnologia, va chiarito il requisito:

• RTO: quanto tempo puoi restare fermo?
• RPO: quanti dati puoi perdere?
• Coerenza: accetti letture stale o scritture divergenti?
• Operatività: chi gestisce il cluster quando qualcosa va storto?

Senza queste quattro risposte, "alta affidabilità" resta uno slogan.

Opzione A: replica Master-Master asincrona

L'approccio tradizionale è avere due nodi MySQL che si replicano a vicenda. In teoria entrambi possono accettare scritture. In pratica, se parliamo di dati critici, bisogna essere molto prudenti.

Vantaggi. È una configurazione relativamente semplice, con latenza di scrittura bassa. Può funzionare bene quando un nodo è primario per le scritture e l'altro è usato come replica calda, oppure quando si vuole scalare letture non critiche.

Svantaggi. La replica è asincrona: prima o poi esiste un intervallo in cui una scrittura è presente su un nodo e non ancora sull'altro. Se il failover avviene in quell'intervallo, il rischio di perdita o riconciliazione manuale esiste. Se entrambi i nodi accettano scritture incompatibili, il problema non è più la disponibilità: è la divergenza.

Quando ha senso. Letture scalabili, reporting, replica geografica con accettazione esplicita di RPO, architetture dove le scritture restano canalizzate su un solo primario.

Quando non la sceglierei. Come fondamento di alta affidabilità attiva-attiva per ordini, pagamenti, stock e dati transazionali dove la coerenza pesa più della comodità del failover.

Opzione B: Galera Cluster / Percona XtraDB Cluster

Galera, e quindi Percona XtraDB Cluster, adotta una replica multi-master virtualmente sincrona. Le transazioni vengono certificate dal cluster e la capacità di operare dipende dal quorum: deve restare disponibile una componente primaria, cioè una maggioranza dei voti.

Questo cambia il modello mentale. Non hai due nodi che "si arrangiano". Hai un cluster che, davanti a una partizione, deve scegliere quale parte può continuare e quale deve fermarsi. È proprio questo meccanismo a ridurre il rischio di split brain.

Vantaggi.

• Riduce il rischio di perdita dati nel failover rispetto alla replica asincrona.
• Permette di scrivere su più nodi, se l'applicazione e il routing sono progettati per farlo.
• In caso di partizione, solo la componente con quorum deve continuare a servire traffico.

Svantaggi.

• Tre voti sono il minimo serio: tre nodi, oppure due nodi più arbitrator. Due nodi puri sono una cattiva idea perché non gestiscono bene le partizioni.
• Le scritture non scalano magicamente: ogni commit deve essere certificato, quindi latenza, conflitti e nodo più lento contano.
• Le operazioni pesanti, le migrazioni schema e i picchi di scrittura vanno pianificati.
• Serve competenza operativa: recuperare un cluster non primario non è un click.

Quando ha senso. E-commerce con dati transazionali critici, requisiti forti di continuità, team tecnico capace di gestire quorum, failover e monitoraggio.

Quando non ha senso. Piccole installazioni dove la complessità operativa del cluster supera il valore del downtime evitato.

L'architettura che uso come riferimento

Per un e-commerce italiano ad alto traffico, la configurazione che considero più difendibile è questa:

• Percona XtraDB Cluster a tre nodi, distribuiti in modo da evitare che un singolo guasto fisico o di rete li colpisca tutti.
• ProxySQL davanti al cluster, con monitoraggio Galera/PXC abilitato, hostgroup separati e regole chiare per letture e scritture.
• Sessioni utente fuori da MySQL, ad esempio su Redis, per non caricare il database relazionale con dati volatili ad alta frequenza.
• Backup indipendenti dal cluster, per proteggersi da cancellazioni logiche, corruzioni applicative e ransomware. La replica propaga anche gli errori.
• Runbook di failover e recovery, provato prima del Black Friday, non scritto durante l'incidente.

ProxySQL è importante, ma va capito bene. Non è un talismano. Il suo valore è leggere lo stato dei nodi, togliere dal giro quelli non sani e instradare query verso hostgroup coerenti. Se il monitoraggio non è configurato bene, può continuare a mandare traffico dove non dovrebbe.

Quorum, split brain e numero di nodi

Il punto più sottovalutato è il quorum. In un cluster a tre nodi, se un nodo cade, gli altri due mantengono la maggioranza e continuano. Se una partizione divide il cluster in 2 contro 1, la parte da due resta primaria, quella da uno si ferma.

Con due nodi, invece, ogni partizione vale 1 contro 1. Non c'è maggioranza. Senza un arbitrator o un terzo nodo, il cluster non ha abbastanza informazione per prendere una decisione sicura. Questo è il motivo per cui "due server per alta affidabilità" spesso è una scorciatoia pericolosa.

Il terzo voto non serve per fare scena. Serve per decidere chi ha diritto di continuare a scrivere.

Alta affidabilità non sostituisce il backup

Replica e backup risolvono problemi diversi.

La replica protegge dalla perdita di un nodo. Non protegge da:

• DROP TABLE eseguito per errore;
• bug applicativo che corrompe dati validi;
• cancellazione malevola propagata su tutti i nodi;
• ransomware che colpisce il piano di controllo;
• necessità di tornare allo stato di ieri alle 18:00.

Per questo un cluster senza backup testati è solo un sistema distribuito che può perdere dati più velocemente. La strategia di ripristino va progettata insieme al cluster, come spiegato nell'articolo sui backup a prova di ransomware.

Checklist prima della produzione

Prima di mettere in produzione un cluster MySQL HA, verificherei almeno questi punti:

• quorum chiaro: tre nodi o arbitrator, non due nodi isolati;
• health check di ProxySQL testati su nodo fermo, nodo desincronizzato e cluster non primario;
• backup full e incrementali con test di restore;
• monitoraggio di stato cluster, flow control, replication queue, errori di certificazione;
• procedura di bootstrap documentata;
• test di failover applicativo con traffico reale o realistico;
• sessioni applicative spostate fuori da MySQL;
• piano per manutenzione e upgrade senza fermare l'intero servizio.

L'architettura che ha retto picchi come il Black Friday non è fatta solo di tre nodi e un proxy. È fatta di decisioni operative: cosa può fallire, chi se ne accorge, dove viene spostato il traffico, come si torna indietro e quali dati sono ancora recuperabili.

Fonti principali

• Percona XtraDB Cluster documentation
• Percona XtraDB Cluster - cluster failover
• Galera Cluster - quorum components
• ProxySQL - Galera configuration

Il verdetto pratico: per dati critici di e-commerce, la coerenza viene prima della comodità. Master-Master asincrono può servire in architetture controllate, ma non lo tratterei come garanzia forte di continuità transazionale. Per ordini e magazzino, Galera/Percona XtraDB Cluster con quorum corretto, ProxySQL configurato bene e backup verificati è una base molto più solida.