Fine del supporto per il cluster del database open source: una scelta obbligata sulla manutenzione
Secondo Percona, il cluster Galera del database relazionale open source è giunto al termine del suo attuale percorso di sviluppo e manutenzione, ponendo il supporto in caso di incidenti e le correzioni future al centro di una decisione operativa per i team che gestiscono i database. In un articolo dell'8 ottobre 2026, Valeria Bogatyreva riferisce che il fornitore del database, che ha acquisito Codership nel maggio 2025, ha fissato al 30 settembre 2026 la scadenza del supporto per tutte le versioni attuali del cluster Galera di quel database. In base a questa politica cessano lo sviluppo, la manutenzione e il rilascio di versioni binarie, ossia i pacchetti software pronti per l'installazione.
Un cluster è un gruppo di server di database, chiamati nodi, che lavorano insieme. Galera fornisce la replica, il meccanismo che mantiene coordinati i loro dati. La scadenza non modifica di per sé il funzionamento di un cluster installato: il 1° ottobre dovrebbe comportarsi come il giorno precedente. A cambiare è il percorso per sottoporre i problemi agli specialisti e ottenere un'eventuale correzione del software. Questa distinzione è importante perché un database può restare operativo anche quando non esistono più le condizioni necessarie per ripristinarlo dopo il prossimo guasto complesso.
La diagnosi, non soltanto la replica, può incidere maggiormente sulla durata di un'interruzione. Bogatyreva cita incidenti attribuiti al team di Codership in cui le query si accumulavano senza errori utili nei log, le registrazioni che il software lascia della propria attività. Un'interruzione è durata venti minuti e si è conclusa solo dopo che qualcuno ha scelto un nodo da arrestare. Un altro caso riguardava il controllo di flusso, il meccanismo che rallenta il lavoro in ingresso quando i membri del cluster non riescono a tenere il passo: le scritture scadevano per timeout mentre il contatore dei messaggi di controllo di flusso inviati rimaneva a 0. Il segnale atteso, quindi, non rivelava lo stallo.
Percona sostiene che questi guasti abbiano spesso origine al di fuori della replica dei write-set di Galera, che distribuisce le modifiche apportate dalle transazioni del database. Tra gli esempi figurano flashcache, un componente di cache per l'archiviazione; una riga di configurazione delle opzioni del provider di replica sovrascritta; il DNS, il servizio che associa i nomi agli indirizzi, che risolveva un nome nell'indirizzo dell'interfaccia di rete sbagliata; e un firewall che consentiva la comunicazione in una sola direzione. In un altro caso, un team che indagava su riavvii ripetuti in Kubernetes, un software per coordinare i container applicativi, ha dovuto leggere il codice sorgente del relativo operatore, l'automazione che gestisce il database. Questi esempi spiegano perché il tempo medio di ripristino, ossia il tempo necessario per ristabilire il servizio, possa dipendere più dall'individuazione della causa che dalla sua risoluzione.
Il percorso di migrazione consigliato nell'ambito dell'offerta di database aziendali del fornitore è il cluster Galera del suo database alternativo. Non si tratta semplicemente di sostituire il servizio di supporto mantenendo lo stesso database. Come osserva Percona, il database alternativo ha tabelle di sistema diverse, che memorizzano le informazioni interne del database, e un dizionario dei dati fondamentalmente diverso, ossia il catalogo che descrive gli oggetti del database. Anche le note sulla migrazione del database alternativo richiedono di ricreare sistematicamente i privilegi degli utenti, cioè le autorizzazioni che regolano l'accesso. Per le organizzazioni che vogliono continuare a usare il database originale, queste differenze rendono la scelta una decisione architetturale anziché un rinnovo contrattuale.
Percona presenta due alternative, entrambe opzioni commerciali proposte da un fornitore che ha un interesse nella decisione. La sua offerta di supporto per database copre un cluster Galera esistente del database originale senza migrazione, sostituzione della piattaforma o ricostruzione dei privilegi. Percona pubblicizza la disponibilità di ingegneri senior per il database originale 24 ore su 24, 7 giorni su 7, 365 giorni all'anno, attraverso team che lavorano in diversi fusi orari, offrendo sia la valutazione iniziale degli incidenti sia consulenza. La consulenza comprende l'ottimizzazione dell'interfaccia di replica, ossia la regolazione dell'interfaccia tra il database originale e Galera; la strategia DDL, cioè la pianificazione delle modifiche alla struttura del database; la distribuzione delle scritture; e la progettazione del quorum, ossia la definizione di come un numero sufficiente di nodi concordi sul fatto che il cluster possa continuare a funzionare. Il livello Premium pubblicizza tempi contrattuali di risposta iniziale che possono scendere fino a 15 minuti per gli incidenti di gravità 1. Un impegno sui tempi di risposta iniziale non è una garanzia sui tempi di riparazione.
L'altra opzione è la distribuzione cluster mantenuta da Percona, che combina la distribuzione Percona del server del database originale con il fork della libreria Galera sviluppato da Percona, una versione mantenuta separatamente e disponibile in un repository pubblico. Percona la descrive come compatibile con l'edizione community del database originale e afferma che gli schemi del database, ossia le definizioni delle tabelle e delle loro relazioni, le tabelle di sistema e gli account utente vengono trasferiti senza modifiche. Afferma inoltre che il comportamento dell'interfaccia di replica, gli strumenti, i connettori e l'ecosistema nel suo complesso rimangono familiari. È disponibile una guida pubblica alla migrazione in dieci passaggi da seguire autonomamente. Si tratta di dichiarazioni di compatibilità di Percona, non di prove che ogni installazione possa essere trasferita senza verifiche.
Le argomentazioni di Percona a favore della propria distribuzione cluster si basano sulla manutenzione continuativa del livello cluster. L'azienda indica interventi sul trasferimento incrementale dello stato (IST), che fornisce le modifiche non ricevute da un nodo in fase di ripristino, e sul trasferimento di un'istantanea dello stato (SST), che fornisce una copia completa dei dati. Altre aree comprendono l'espulsione dei nodi, ossia la rimozione di un membro dal cluster; il controllo di flusso; e le operazioni DDL durante scritture simultanee. L'azienda rimanda a note di rilascio pubbliche trimestrali con identificativi delle segnalazioni Jira, i riferimenti utilizzati per tenere traccia delle singole correzioni. La fonte fornita include un'immagine con una tabella dei rilasci, ma non ne rende accessibili i contenuti, quindi da quel testo non è possibile accertare le singole correzioni o i relativi identificativi.
Secondo Percona, questa cadenza dei rilasci risale al 2012 e copre le versioni 5.5, 5.6, 5.7, 8.0 e ora 8.4, mentre anche la linea 8.0 continua a ricevere rilasci. L'azienda afferma che, nei 90 giorni precedenti, quasi 4.000 istanze host della sua distribuzione cluster mantenuta hanno trasmesso dati di telemetria, ossia informazioni sull'utilizzo inviate automaticamente, al di fuori di Kubernetes. Riferisce separatamente che l'Operator della distribuzione cluster mantenuta è in esecuzione in altre migliaia di deployment Kubernetes. Si tratta di cifre dichiarate dal fornitore, non di un conteggio indipendente degli utenti né di una misura dell'affidabilità. Percona segnala anche interventi recenti sull'ispezione della cache di replica, ossia l'esame della cache Galera delle modifiche replicate, e sulla replica tra siti nell'Operator, che coordina le copie in ubicazioni diverse.
Per i clienti che utilizzano il suo servizio di migrazione, Percona descrive un ambiente di test di destinazione e un confronto del comportamento dell'interfaccia di replica con quello del cluster esistente. L'obiettivo è osservare come la soluzione sostitutiva gestisce gli stessi guasti prima di procedere definitivamente. Il servizio comprende anche un piano documentato di ritorno al sistema precedente, un passaggio programmato con supporto fuori orario e una verifica dello stato del sistema alcune settimane dopo l'inizio dell'utilizzo in produzione. Sono criteri di valutazione utili per qualsiasi proposta di migrazione: la compatibilità va verificata rispetto al carico di lavoro effettivo e al comportamento in caso di guasto, prevedendo un modo preciso per tornare indietro se il trasferimento fallisce.
I database gestiti e il monitoraggio di AEU Data sono pertinenti a questa sfida operativa, anche se i clienti dovrebbero verificare le condizioni di supporto e manutenzione del proprio specifico software di clustering. La lezione più generale è distinguere due domande: chi aiuterà a diagnosticare la prossima interruzione e chi manterrà il codice che necessita di correzioni? Il supporto per un cluster Galera esistente del database originale può concedere un margine di tempo; la migrazione a una distribuzione mantenuta affronta la mancanza di manutenzione del software. Nessuna delle due opzioni rende impossibili le interruzioni, ma lasciare entrambe le domande senza risposta trasforma una diagnosi difficile in un'esposizione operativa più duratura.