Galera Cluster: quello che ho imparato usandolo come sviluppatore C#

Da sviluppatore C#, per molto tempo ho considerato il database come qualcosa di "stabile": un servizio lì sotto che, se configurato bene, fa il suo lavoro e basta. Poi arriva sempre quel momento in cui i requisiti cambiano.

Il sistema cresce, gli utenti aumentano, e soprattutto compare una frase che mette tutti sull'attenti: "Il database non può più permettersi di fermarsi."

È in quel contesto che mi sono trovato ad affrontare MySQL/MariaDB con Galera Cluster. Non da DBA, non da sistemista puro, ma da programmatore C# che deve continuare a scrivere codice applicativo senza impazzire dietro a failover, replica e stati inconsistenti.

Questo non è un articolo su come configurare Galera. È un racconto su cosa cambia davvero nel modo di scrivere software quando sotto c'è un database multi-master sincrono.

Perché Galera, spiegato a un programmatore

Se sei uno sviluppatore, quando senti parlare di cluster di database spesso il cervello traduce tutto in una parola: complessità. Replica, nodi, quorum, failover… roba che qualcun altro dovrebbe gestire.

Galera, però, mi ha colpito per un motivo molto semplice: dal punto di vista del codice applicativo, cerca di sembrare un database "normale".

Multi-master, ma davvero

La prima cosa che cambia il modo di ragionare è questa: non c'è un master unico. Con Galera ogni nodo è scrivibile, ogni transazione viene replicata sugli altri nodi, e quando una INSERT va a buon fine, è già consistente su tutto il cluster.

Da programmatore questo significa una cosa importantissima: non devo sapere dove sto scrivendo. Niente logica applicativa del tipo "scrivi qui, leggi là, se il master cade cambia connection string". Il database si presenta come un singolo sistema logico, anche se sotto è distribuito.

Replica virtualmente sincrona: meno sorprese

Abituato a sistemi master/slave asincroni, avevo sempre in testa un problema latente: "E se leggo da uno slave che non è ancora aggiornato?"

Con Galera questa paura si riduce drasticamente. La replica è sincrona a livello di certificazione: quando il commit ritorna, il cluster ha accettato la transazione. L'applicazione fisica sugli altri nodi avviene subito dopo, ma dal punto di vista della consistenza, sei al sicuro.

In termini pratici: la transazione viene certificata dal cluster prima del commit. Se non può essere replicata, fallisce. Niente dati committed in modo inconsistente tra i nodi. Dal punto di vista del codice C# questo si traduce in meno controlli difensivi, meno workaround, e meno if nati dalla sfiducia nel dato.

Alta disponibilità senza codice "strano"

Uno dei motivi principali per cui Galera entra in gioco è l'alta disponibilità. Nodo giù? Il cluster continua a funzionare e l'applicazione spesso non se ne accorge nemmeno. Questo è fondamentale: la resilienza sta nell'infrastruttura, non nel codice applicativo. Come sviluppatore, il mio obiettivo non è scrivere logica di failover o retry distribuiti ovunque. È scrivere codice di business, sapendo che sotto c'è qualcosa che regge i colpi.

Le prime botte: lock, conflitti e false certezze

La prima illusione che Galera ti regala è questa: "Se è multi-master e sincrono, allora posso scrivere come se fosse un database singolo." Tecnicamente… quasi. Nella pratica, Galera è molto onesto: se fai qualcosa di sbagliato, te lo fa pagare subito.

I conflitti di scrittura esistono (e fanno male)

In un cluster Galera, le transazioni non vengono semplicemente replicate: vengono certificate. Se due nodi scrivono sulle stesse righe (non tabelle, righe!) nello stesso momento con transazioni concorrenti, una delle due perde.

Dal punto di vista del codice C# questo si traduce in eccezioni, rollback, e transazioni che "falliscono senza motivo apparente". La prima reazione è sempre: "Ma il codice è giusto!" Sì. È il modello mentale che è sbagliato.

Le transazioni lunghe sono il nemico

Altro errore tipico (e molto "da sviluppatore"): tenere transazioni aperte più del necessario. In Galera, più una transazione dura, più aumenta la finestra di conflitto, più il cluster soffre. Cose apparentemente innocue come fare logica applicativa dentro una transaction, chiamare servizi esterni, o ciclare su molte righe diventano improvvisamente pericolose.

Qui ho imparato una lezione importante: in un sistema distribuito, una transazione non è solo un concetto logico. È un costo reale.

Lock: non sono spariti, sono solo meglio nascosti

Altro mito: "Galera elimina i lock". No. I lock esistono, servono, e quando li incontri… li senti tutti. La differenza è che non li vedi subito, non sono sempre riproducibili, e spesso emergono solo sotto carico. E allora inizi a rivedere gli indici, semplificare gli UPDATE, spezzare operazioni complesse. Non perché Galera sia "difficile", ma perché non perdona design pigri.

La falsa sicurezza del "tanto replica"

Sapere che i dati sono replicati, che il cluster è resiliente, che un nodo può cadere, ti dà una sensazione di sicurezza. Il rischio è abbassare la guardia su modellazione dei dati, gestione degli errori e retry applicativi.

La verità è questa: Galera protegge i dati, non le cattive abitudini. Come sviluppatore C#, devi comunque gestire le eccezioni, implementare retry sensati, e scrivere codice idempotente dove serve.

Come gestisco i conflitti nel codice C# (su carta pane)

Un pattern che uso per gestire i conflitti Galera. I codici di errore MySQL da intercettare sono principalmente due: 1213 (deadlock) e 1205 (lock wait timeout).

public async Task<T> ExecuteWithRetryAsync<T>(
    Func<Task<T>> operation,
    int maxRetries = 3)
{
    for (int i = 0; i <= maxRetries; i++)
    {
        try
        {
            return await operation();
        }
        catch (MySqlException ex)
            when (ex.Number == 1213 || ex.Number == 1205)
        {
            if (i == maxRetries) throw;
            // Exponential backoff
            await Task.Delay(100 * (int)Math.Pow(2, i));
        }
    }
    throw new InvalidOperationException();
}

Le regole d'oro che mi sono dato:

• Transazioni corte: apri, scrivi, chiudi. Niente logica di business nel mezzo.
• Retry con backoff esponenziale: i conflitti sono fisiologici, non errori.
• Operazioni idempotenti: se un retry riesegue l'operazione, il risultato deve essere lo stesso.
• Evita SELECT ... FOR UPDATE: i pattern pessimistici amplificano i problemi invece di risolverli.

Quando Galera è la scelta giusta (e quando no)

Galera non è una tecnologia da scegliere "perché sì". Non è una moda, non è una scorciatoia, e soprattutto non è gratis in termini di complessità. Ma in alcuni contesti è semplicemente la risposta più sensata.

Quando Galera ha davvero senso

Dal mio punto di vista di sviluppatore, Galera funziona bene quando il database non può fermarsi (downtime non accettabile, manutenzioni senza blackout), la scrittura è distribuita su più servizi e istanze applicative, la consistenza è un requisito non negoziabile, e il team è disposto a ragionare su transazioni, concorrenza e design dei dati. In questi casi, Galera smette di essere "un cluster" e diventa un abilitatore.

Quando probabilmente non è la scelta giusta

Galera non è ideale se l'applicazione è piccola o semplice, il carico è quasi tutto in scrittura su poche tabelle, le transazioni sono lunghe e complesse, o se l'applicazione fa uso massiccio di SELECT ... FOR UPDATE e pattern pessimistici (che Galera amplificherà invece di risolvere). Se il team non ha tempo di capirne le implicazioni, una replica tradizionale o anche un singolo database ben gestito sono spesso soluzioni più sane.

Conclusione

Usare Galera da sviluppatore C# mi ha insegnato una cosa semplice ma potente: l'infrastruttura non è "qualcosa sotto". È parte integrante del software che scriviamo. Quando database e codice iniziano a dialogare davvero, le applicazioni diventano più robuste, e anche chi le scrive… un po' più bravo.