Database Cluster in alta disponibilità

Galera è uno dei sistemi più solidi per far girare MariaDB in alta disponibilità. È anche uno dei più delicati da configurare: quorum, SST, parametri di replica, bootstrap del primo nodo. Basta un dettaglio sbagliato perché il cluster non riparta proprio quando serve.

Su KonsoleX il cluster nasce con tre nodi in replica sincrona, già bilanciato e testato. Scegli il dimensionamento e il motore, MariaDB o MySQL, e il resto lo fa la piattaforma. Nessun file my.cnf da scrivere, nessun bootstrap da ricordare.

Un cluster Galera usato male rallenta invece di accelerare: scritture concorrenti su più nodi generano conflitti e rollback.

Per questo il cluster KonsoleX nasce con la topologia giusta. Un nodo riceve le scritture, gli altri servono le letture, e ProxySQL instrada ogni query al nodo di competenza. Le app si collegano a un solo endpoint e non devono sapere quanti nodi ci sono dietro né quale sta facendo cosa. Funziona allo stesso modo per le tue Container App e per i cluster Kubernetes, collegati via rete privata.

Con la replica tradizionale, quando il master cade, le ultime transazioni possono andare perse e qualcuno deve promuovere a mano una replica. Spesso di notte.

Con Galera questo problema non esiste. Ogni transazione è confermata solo quando tutti i nodi l’hanno ricevuta, quindi nessun nodo resta indietro e nessun dato si perde. Se un nodo si ferma, gli altri continuano a lavorare, e quando torna si riallinea da solo. I nodi comunicano su rete privata, il gestore database web si accende solo quando serve e i backup per singolo nodo sono disponibili come addon.

Quando un database MariaDB inizia a soffrire, la risposta classica è un server più grosso. Funziona finché non hai già il più grosso.

Qui cresci in orizzontale. Aggiungi un nodo e KonsoleX lo installa, lo unisce al cluster, lo sincronizza e lo mette in servizio, mentre le app restano online. Ogni nuovo nodo è un nodo di lettura in più e una copia completa dei dati in più. Il dimensionamento lo scegli nodo per nodo, tra istanze Shared, Standard o Dedicated.

Un cluster Galera manda segnali prima di andare in difficoltà, ma vanno letti nel posto giusto.

KonsoleX li raccoglie in un’unica vista: stato di sincronizzazione di ogni nodo, flow control, code di replica in ingresso e in uscita, stato EVS. Accanto trovi CPU, RAM e disco di ogni nodo, con le soglie evidenziate. Capisci se un nodo sta rallentando il cluster prima che lo noti un utente. E se serve una mano vera, rispondono le persone che questi cluster li gestiscono ogni giorno in produzione.

Molte applicazioni non possono cambiare database: gestionali certificati, software di terze parti, stack costruiti su MySQL. Per loro l’alta disponibilità è sempre stata un progetto lungo, costoso e rischioso, e spesso è rimasta nel cassetto.

Su KonsoleX il cluster MySQL nasce già pronto, con tre nodi in replica sincrona Galera. La tua applicazione trova lo stesso MySQL di sempre, solo che ora non sta più su un server singolo.

Il modo migliore per portare un’app esistente in cluster è che l’app non se ne accorga.

Le app si collegano a un unico endpoint, come prima. Dietro, ProxySQL manda le scritture al nodo writer e distribuisce le letture sugli altri nodi. Niente stringhe di connessione multiple, niente logica di failover da scrivere nell’applicazione. Cambi l’host nel file di configurazione e il lavoro è finito.

La replica asincrona classica di MySQL ha un punto debole che tutti conoscono: le repliche possono restare indietro, e se il primary cade nel momento sbagliato le ultime transazioni si perdono.

Con la replica sincrona ogni transazione è confermata solo quando tutti i nodi l’hanno ricevuta. Nessun ritardo di replica, nessun dato perso, nessuna promozione manuale. Se un nodo si ferma il cluster continua a servire, e quando il nodo torna si riallinea da solo. Rete privata tra i nodi, gestore database web attivabile solo quando serve e backup per singolo nodo come addon.

Con MySQL su un server singolo crescere vuol dire comprare un server più potente, finché esiste.

Qui aggiungi nodi. KonsoleX li installa, li unisce al cluster, li sincronizza e li mette in servizio senza fermare l’applicazione. Ogni nodo in più è capacità di lettura in più e una copia completa in più dei tuoi dati. Il dimensionamento lo scegli nodo per nodo, tra istanze Shared, Standard o Dedicated.

Dalla stessa vista controlli lo stato di sincronizzazione di ogni nodo, il flow control e le code di replica, insieme a CPU, RAM e disco con le soglie evidenziate. Se qualcosa rallenta il cluster lo vedi subito, non quando arriva la telefonata del cliente.

E se serve una mano vera, rispondono le persone che questi cluster li gestiscono ogni giorno in produzione.

Un PostgreSQL in alta disponibilità di solito si costruisce assemblando strumenti diversi: uno per la replica, uno per il failover, uno per instradare le connessioni. Poi bisogna farli parlare tra loro e sperare che il primo guasto vero non riveli un errore di configurazione.

Su KonsoleX il cluster nasce già assemblato: tre nodi in streaming replication sincrona, con failover integrato e collaudato. Tu scegli il dimensionamento, la piattaforma fa il resto.

Il primary di PostgreSQL è prezioso: deve occuparsi delle scritture, non rispondere a ogni report e a ogni dashboard.

Le repliche si prendono il traffico in lettura e alleggeriscono il primary. Le app vedono un unico endpoint: le scritture vanno al primary, le letture alle repliche. Dal pannello trovi l’elenco dei database con occupazione e credenziali di accesso. Il gestore web lo apri dal browser, senza client locali né tunnel SSH. Il cluster si collega anche ai tuoi cluster Kubernetes via rete privata, così i dati restano fuori dal cluster, dove sono al sicuro.

Con PostgreSQL su un server singolo, un guasto vuol dire ripristinare un backup e perdere tutto quello che è successo dopo. Con una replica gestita a mano vuol dire qualcuno che di notte la promuove e riconfigura le app.

Con KonsoleX la replica è sincrona, quindi ogni transazione confermata esiste su più nodi. Se il primary cade, una replica viene promossa in automatico e il cluster resta operativo, senza intervento manuale. Rete privata tra i nodi e backup per singolo nodo disponibili come addon.

Quando le letture crescono più delle scritture, cioè quasi sempre, non serve un primary più grosso. Servono più repliche.

Aggiungi una replica e KonsoleX la installa, la collega al cluster, la allinea e la mette in servizio da sola. Ogni nuova replica è capacità di lettura in più e un’altra copia dei tuoi dati pronta a diventare primary. Il dimensionamento lo scegli nodo per nodo, tra istanze Shared, Standard o Dedicated.

Su PostgreSQL i problemi si annunciano: connessioni che crescono, WAL che si accumulano, repliche che restano indietro.

KonsoleX ti mostra tutto in un’unica vista: versione, connessioni attive, uptime, esito dei controlli sui WAL e risorse di ogni nodo. Capisci cosa sta succedendo prima che diventi un problema. E se serve una mano vera, rispondono le persone che questi cluster li gestiscono ogni giorno in produzione.