MySQL End of Life (EOL): Date, Rischi e Checklist di Aggiornamento

1. Cos’è la fine vita (EOL) di MySQL? Perché dovresti controllarla ora

Cos’è l’EOL di MySQL? Una spiegazione di base

MySQL è un sistema di gestione di database relazionali open source ampiamente utilizzato in tutto il mondo. Alimenta tutto, dalle applicazioni web ai sistemi aziendali, ma nessuna versione può essere usata per sempre.

MySQL ha anche un punto di “Fine Vita (EOL)”. Questo si riferisce alla data in cui Oracle, lo sviluppatore, termina il supporto per quella versione — come gli aggiornamenti di sicurezza e le correzioni di bug.

Ad esempio, MySQL 5.7 ha raggiunto la fine del supporto nell’ottobre 2023. Questo tipo di “informazione EOL” è estremamente importante perché influisce direttamente sulla sicurezza e sulla futura manutenibilità dei sistemi in produzione.

“Era EOL prima che ce ne accorgessimo” è estremamente pericoloso

Molti sviluppatori e operatori tendono a essere cauti nell’aggiornare MySQL. È facile pensare “è stabile, quindi possiamo lasciarla così”, ma continuare a utilizzare una versione EOL comporta rischi importanti.

In particolare, i rischi includono:

• Le vulnerabilità di sicurezza non vengono corrette
• La compatibilità con il sistema operativo e altri software viene persa
• Non è più possibile ottenere supporto dai fornitori
• I nuovi sviluppatori hanno più difficoltà a mantenerla, aumentando i costi di manutenzione

Per evitare questi rischi, è fondamentale verificare regolarmente lo stato di supporto della versione MySQL che stai utilizzando.

Conoscere lo stato di supporto previene gli “incidenti”

Specialmente per le aziende che usano MySQL nei sistemi aziendali, una situazione come “abbiamo superato l’EOL senza accorgercene” può in seguito portare a gravi interruzioni o incidenti di sicurezza.

Ecco perché comprendere il ciclo di vita del supporto della tua versione MySQL — e effettuare aggiornamenti o migrazioni pianificate prima dell’EOL — è la chiave per operazioni stabili in futuro.

Nella sezione successiva, organizzeremo un elenco chiaro di quali versioni hanno raggiunto l’EOL e quando, come riferimento pratico.

2. Cronologia del fine supporto di MySQL per versione (Riepilogo EOL)

Conosci le principali versioni di MySQL e le loro date EOL

MySQL è stato continuamente aggiornato nel corso degli anni, e ogni versione principale ha un periodo di supporto chiaramente definito. Di seguito è riportato un riepilogo delle EOL (date di fine supporto) pubblicate ufficialmente per le versioni principali.

[EOL Table by Version]

*Le date sono basate su informazioni pubblicamente disponibili da Oracle e dai principali provider cloud.

MySQL 5.5 (supporto terminato nel 2018)

MySQL 5.5 è stato rilasciato nel 2010 e adottato da molte applicazioni web. Tuttavia, il supporto è terminato il 3 dicembre 2018. Poiché non vengono più forniti patch di sicurezza o correzioni di bug, qualsiasi sistema che lo utilizza ancora dovrebbe migrare il prima possibile.

MySQL 5.6 (supporto terminato nel 2021)

MySQL 5.6 è diventato popolare grazie a miglioramenti delle prestazioni e nuove funzionalità, ma ha raggiunto l’EOL il 5 febbraio 2021. Gli ambienti che lo usano ancora sono già fuori supporto ed esposti a rischi significativi.

MySQL 5.7 (supporto terminato nell’ottobre 2023)

MySQL 5.7 è stato ampiamente utilizzato nei sistemi aziendali per molti anni, ma il supporto è terminato il 21 ottobre 2023. Molti sistemi stanno ancora eseguendo questa versione, e sempre più organizzazioni si stanno affrettando a migrare. I controlli di compatibilità e il lavoro di migrazione dei dati sono ora aree di grande attenzione.

MySQL 8.0 (supporto premium previsto per terminare ad aprile 2025)

MySQL 8.0 è l’attuale versione stabile mainstream, ma il supporto premium è previsto per terminare ad aprile 2025. Dopo tale data, è consigliato il supporto esteso o il passaggio a una release LTS (Long Term Support). Sta crescendo l’attenzione su MySQL 8.4 LTS, introdotto nel 2024, e vale la pena considerarlo se desideri operazioni stabili a lungo termine.

Le informazioni EOL sono essenziali per la pianificazione futura

Come mostrato sopra, ogni versione di MySQL ha un EOL pianificato, e di conseguenza è necessaria una preparazione alla migrazione. Verifica nuovamente la versione che il tuo sistema utilizza e non pensare “per ora va bene”, ma “quando migreremo?”.

3. Cosa succede dopo la fine del supporto? Rischi EOL spiegati

I rischi di continuare dopo la fine del supporto sono enormi

Quando una versione di MySQL raggiunge la fine del ciclo di vita (EOL – End of Life), gli aggiornamenti di sicurezza ufficiali, le correzioni di bug e i miglioramenti vengono interamente interrotti. In altre parole, non è più possibile ricevere alcun supporto da Oracle.

Anche se tutto sembra funzionare normalmente, rischi seri possono nascondersi sotto la superficie. Questo è particolarmente critico per i server web esposti a Internet o per i sistemi aziendali core.

Vulnerabilità di sicurezza non corrette

Il problema più grave è che le vulnerabilità appena scoperte non verranno più corrette. Gli aggressori usano le informazioni sulle vulnerabilità note per prendere di mira le versioni EOL.

E poiché MySQL è ampiamente utilizzato, è anche un bersaglio attraente. Anche se le vulnerabilità vengono divulgate dopo l’EOL, le tue opzioni di difesa diventano estremamente limitate se non verrà mai rilasciata una correzione.

🔒 Nessuna patch disponibile = rimani un bersaglio in ogni momento.

Rischio di violare leggi e standard di sicurezza

Sempre più aziende e istituzioni pubbliche sono tenute a conformarsi a standard come ISMS o PCI DSS. Questi standard spesso proibiscono esplicitamente l’uso di software non supportato.

Ciò significa che continuare a utilizzare una versione MySQL in EOL può portare a risultati di audit negativi o a danni alla fiducia dei partner commerciali.

Problemi operativi causati da incompatibilità con OS o altri software

Poiché le versioni EOL non sono più testate per la compatibilità con le nuove versioni di OS o con altri software, possono causare guasti inaspettati o problemi di prestazioni. Casi reali includono MySQL che non riesce ad avviarsi dopo un aggiornamento del sistema operativo o che registra un calo significativo delle prestazioni.

Questo può portare a interventi di emergenza – o, nel peggiore dei casi, a interruzioni del servizio.

Si trasforma in debito tecnico

Mantenere viva una versione EOL accumula debito tecnico. Quando dovrai finalmente aggiornare, i costi di migrazione possono aumentare drasticamente, e potresti scoprire una grande quantità di codice dipendente dal comportamento della vecchia versione.

In sintesi, più a lungo rimandi l’aggiornamento, più costi e rischi aumentano nel tempo.

Come mantenere le operazioni sicure

Per evitare i rischi legati all’EOL, non è necessario aggiornare immediatamente – ma dovresti costruire un piano di migrazione. Comprendendo la tua versione attuale, il tempo rimanente fino all’EOL e scegliendo una destinazione, potrai mantenere un ambiente stabile con fiducia.

Nella sezione successiva, presenteremo le principali opzioni di migrazione e i casi in cui ciascuna è più adatta.

4. Opzioni di migrazione: scegli la strategia migliore per i tuoi obiettivi

La tua risposta all’EOL dipende dalla “strategia di migrazione”.

Quando MySQL si avvicina all’EOL, la decisione più importante è “dove migrare”. Non basta semplicemente aggiornare – scegliere un’opzione che corrisponda ai tuoi requisiti e alla tua struttura operativa determina la stabilità futura.

Ecco tre pattern di migrazione comuni e a quali tipologie di utenti si adattano meglio.

Aggiornare a MySQL 8.0 o 8.4 LTS (conservativo, focalizzato sulla stabilità)

L’opzione più semplice è aggiornare a una versione più recente di MySQL. Attualmente, MySQL 8.0 è lo standard, ma dal 2024, MySQL 8.4 LTS (Long Term Support) sta attirando molta attenzione.

• Pro:
• Alta compatibilità con gli ambienti MySQL esistenti
• Possibilità di continuare a utilizzare il software open source
• Gli strumenti esistenti come MySQL Workbench possono continuare a essere usati
• Contro:
• Possono verificarsi errori di compatibilità a causa di cambiamenti di sintassi/specifica
• È necessario prestare attenzione a impostazioni di storage e set di caratteri
• Ideale per:
• Piccole e medie imprese e sviluppatori che desiderano operazioni stabili senza grandi cambiamenti di sistema

Migrare a RDBMS alternativi come MariaDB o TiDB (flessibilità e futuro garantito)

Passare a un RDBMS compatibile con MySQL è anche una valida alternativa. Due opzioni popolari sono MariaDB e TiDB.

• MariaDB:
• Una fork di MySQL con sintassi e amministrazione simili
• Attivamente sviluppata dalla community
• Ricche funzionalità di ottimizzazione delle performance
• TiDB:
• Un database SQL distribuito e nativo del cloud
• Forte alta disponibilità e scalabilità
• Gestisce bene sia OLAP che OLTP, adatto anche per l’analisi
• Ideale per:
• Organizzazioni che considerano una migrazione futura al cloud o elaborazione dati su larga scala
• Team che vogliono adottare tecnologia open-source avanzata

Servizi di database cloud gestiti (ridotto carico operativo, scalabile)

Se vuoi ridurre il sovraccarico operativo on-prem, considera i servizi RDB cloud gestiti. Esempi comuni includono:

• Amazon RDS for MySQL
• Un servizio gestito da AWS
• Backup automatici e ridondanza sono standard
• Sii consapevole di potenziali aggiornamenti automatici nel tempo
• Google Cloud SQL for MySQL
• Un servizio gestito da Google Cloud
• Scalabile e si integra bene con altri servizi GCP
• Facile da gestire tramite UI, friendly per principianti
• Pro:
• Nessuna manutenzione OS o hardware
• Meno expertise infrastrutturale richiesta
• Contro:
• Costi cloud ongoing
• Il tuning fine-grained potrebbe essere più difficile
• Ideale per:
• Operare applicazioni web di piccole e medie dimensioni
• Startup e business web che vogliono razionalizzare risorse dev/ops

[Comparison Table] Opzioni e caratteristiche

Nella prossima sezione, analizzeremo i passi pratici di migrazione e le precauzioni chiave in modo chiaro e attuabile. Andiamo attraverso la checklist per evitare errori.

5. Passi di Migrazione MySQL e Checklist (Come Evitare Fallimenti)

Il successo della migrazione è “80% preparazione”

Migrare a causa dell’EOL di MySQL è diverso da un semplice bump di versione—richiede passi attenti e preparazione accurata. Specialmente per i sistemi di produzione, garantire l’integrità dei dati e la continuità del servizio è la priorità assoluta.

Qui spieghiamo i passi chiave in cinque fasi.

STEP1: Valuta e inventaria l’ambiente attuale

Prima, identifica la tua attuale MySQL versione, configurazione e dipendenze.
Controlla i seguenti elementi:

• Versione MySQL e numero di build
• Set di caratteri in uso (es. utf8mb4)
• Motore di storage (InnoDB, MyISAM)
• Sintassi SQL e funzioni in uso (potrebbero avere dipendenze di versione)
• Applicazioni connesse e servizi esterni

✅ Obiettivo: comprendere tutte le dipendenze per prevenire fallimenti post-migrazione

STEP2: Verifica la compatibilità

Valida se il tuo ambiente attuale è compatibile con la versione target. Con aggiornamenti major, presta particolare attenzione a:

• Sintassi rimossa / parole riservate che potresti usare
• Cambiamenti nelle impostazioni default (es. SQL mode)
• Differenze in variabili di sistema e parametri

🔎 Puoi diagnosticare la compatibilità usando il comando mysql_upgrade o l’MySQL Shell Upgrade Checker Utility.

STEP3: Prendi backup e costruisci un ambiente di test

Aggiornare la produzione direttamente è troppo rischioso.
Prima, prendi un backup completo e usalo per costruire un ambiente staging (test).

• Backup dump usando mysqldump o mysqlpump
• Backup basati su file (es. XtraBackup)
• Ripristina in staging e testa il comportamento dell’applicazione

Trovando problemi post-migrazione ed errori SQL in anticipo, puoi minimizzare i problemi durante il cutover di produzione.

STEP4: Migra i dati in produzione

Dopo la validazione, migra in produzione. Se possibile, fallo di notte o durante periodi di basso traffico.

• Backup finale proprio prima della migrazione
• Pausa temporanea del servizio (usa una pagina di manutenzione se possibile)
• Importa dati nella nuova versione del database
• Regola file di config e variabili d’ambiente

Se hai anche bisogno di cambiamenti lato applicazione (come switchare l’endpoint MySQL), sii particolarmente attento ai tempi.

STEP5: Valida e ottimizza

La migrazione non finisce al cutover.
Controlla il seguente per confermare che il nuovo ambiente sia stabile:

• Connettività dall’applicazione
• Velocità di esecuzione delle query e eventuali errori
• Monitoraggio dei log (log degli errori, log delle query lente)
• Ottimizzazione delle impostazioni di cache e ricostruzione degli indici

Quando necessario, esegui ANALYZE TABLE o OPTIMIZE TABLE per recuperare le regressioni di performance introdotte dalla migrazione.

Checklist (revisione finale)

✅ Conferma versione attuale e configurazione
✅ Esegui controlli di compatibilità in anticipo
✅ Prendi un backup completo
✅ Testa in un ambiente di staging
✅ Esegui un cutover di produzione pianificato
✅ Monitora errori e performance dopo la migrazione

La chiave del successo è la pianificazione dell’esecuzione. Per le migrazioni guidate da EOL, una preparazione costante, test e un cutover attento sono la migliore strategia di riduzione del rischio.

6. Gestione EOL sui Servizi Cloud (Per Utenti AWS e GCP)

Anche sul cloud, non puoi essere compiacente

Anche se usi MySQL su piattaforme cloud come Amazon RDS o Google Cloud SQL, l’EOL (fine del supporto) è ancora un tuo problema. I fornitori cloud potrebbero implementare upgrade automatici o persino pensionamento del servizio per versioni non supportate, quindi la pianificazione proattiva è importante.

Di seguito un overview della gestione EOL da parte dei principali servizi cloud.

Amazon RDS per MySQL: fai attenzione agli upgrade automatici

Con Amazon RDS per MySQL, AWS ha eseguito pensionamenti di versione e upgrade forzati a causa della fine del supporto più volte.

• MySQL 5.5: terminato nel 2018 → migrato automaticamente a 5.6
• MySQL 5.6: terminato nel 2021 → upgrade automatici a 5.7 implementati dopo il 2022

Di conseguenza, la tua versione di MySQL potrebbe cambiare in un momento non previsto, potenzialmente causando problemi all’applicazione o regressioni di performance.

✅ Mitigazione: pianifica ed esegui gli upgrade secondo il tuo programma

AWS fornisce avvisi in anticipo via email e notifiche sulla console, ma se li ignori, potrebbero essere applicati automaticamente—quindi fai attenzione.

Google Cloud SQL per MySQL: pensionamento first-gen e spinta alla migrazione

Cloud SQL per MySQL sta anche procedendo con il pensionamento di versioni e architetture più vecchie.

• Le istanze di prima generazione non possono più essere create nuove
• Ci sono politiche che incoraggiano gli upgrade per versioni vicine alla fine del supporto

Google tende a rispettare la flessibilità dell’utente, ma ci sono limiti al “supporto vitale” a lungo termine, quindi dovresti aggiornare o ricostruire prima piuttosto che dopo.

Cloud SQL fornisce anche funzionalità forti come backup automatici e failover, ma problemi possono ancora verificarsi se trascuri differenze come impostazioni predefinite della modalità SQL o comportamento del fuso orario.

✅ Testa impostazioni specifiche del cloud e compatibilità in anticipo

Vantaggi del cloud—e trappole EOL

I servizi cloud hanno vantaggi, ma una preparazione EOL debole può causare problemi.

Anche sul cloud, la realtà è la stessa: sei ancora responsabile della gestione dell’EOL.

Checklist EOL per ambienti cloud

✅ Controlla la tua versione attuale di MySQL e la timeline EOL
✅ Abilita notifiche del fornitore (email o altri canali)
✅ Conferma se sei soggetto a upgrade automatici
✅ Testa la nuova versione in staging
✅ Pianifica cambiamenti lato applicazione se necessario

Per ottenere il massimo dalla comodità del cloud, non “imposta e dimentica”. Mantieni gestione e monitoraggio attivi dalla tua parte. Per l’EOL di MySQL in particolare, gli ambienti cloud richiedono ancora una preparazione solida.

7. Domande Frequenti (FAQ)

Q1: Posso continuare a usare MySQL dopo la fine del supporto?

R: Tecnicamente sì, ma non è raccomandato.
MySQL EOL non riceve patch di sicurezza o fix di bug. Questo aumenta rapidamente il rischio di attacchi che sfruttano vulnerabilità e potrebbe violare leggi o politiche di sicurezza.

Anche se il sistema sembra a posto, stai ancora operando con rischio nascosto serio, quindi pianifica un upgrade o migrazione presto.

Q2: Qual è la differenza tra MySQL 8.0 e 8.4 LTS?

A: MySQL 8.4 LTS è una release stabile supportata per un periodo più lungo.
MySQL 8.0 segue il ciclo di release regolare, e il supporto premium è previsto terminare ad aprile 2025. Al contrario, MySQL 8.4 LTS (Long Term Support) è stato introdotto come una release stabile con circa cinque anni di supporto a lungo termine.

Se si dà priorità alla stabilità a lungo termine per i sistemi aziendali, si raccomanda la migrazione a MySQL 8.4 LTS.

Q3: Quanto costa la migrazione?

A: Dipende fortemente dalla scala e dal percorso di migrazione.
Ad esempio, un aggiornamento di versione sullo stesso server potrebbe essere possibile senza costi diretti. Ma migrare a servizi cloud o passare a prodotti diversi (MariaDB/TiDB) può richiedere sforzi e spese per design, costruzione, test e supporto tecnico.

Si dovrebbero anche considerare i costi per la mitigazione del downtime e la preparazione di un ambiente di staging.

Q4: A cosa prestare attenzione durante la migrazione dei sistemi di produzione?

A: I test preliminari e la migrazione graduale sono fondamentali.
In produzione, è necessario eseguire controlli di compatibilità, backup e test di staging. L’uso di repliche di lettura o blue-green deployment (esecuzione di ambienti vecchi e nuovi fianco a fianco e passaggio graduale) può ridurre il downtime.

È più sicuro eseguire il lavoro di notte o nei fine settimana quando il traffico è basso.

Q5: Posso fermare gli aggiornamenti automatici nel cloud?

A: È possibile controllare alcune parti, ma alla fine si deve seguire la politica del fornitore.
RDS e Cloud SQL permettono un certo controllo, come ritardare o regolare le programmazioni di aggiornamento automatico, ma gli aggiornamenti forzati potrebbero comunque verificarsi dopo l’EOL.

Poiché l’evitamento a lungo termine è difficile, l’approccio più affidabile è aggiornamenti pianificati guidati da voi.

Q6: Come dovrei scegliere un database alternativo?

A: Utilizzare questi tre criteri.

1. Compatibilità : quanto della vostra app esistente e SQL funzionerà così com’è
2. Scalabilità / a prova di futuro : se può gestire la crescita dei dati e del traffico
3. Capacità operativa : se potete mantenerlo internamente o necessitate di supporto del fornitore

Per i sistemi aziendali, la selezione dovrebbe basarsi sulla vostra capacità operativa realistica piuttosto che sulle tendenze.

8. Riepilogo: La Migliore Mossa da Fare Prima della Fine del Supporto

L’EOL non è “lontano”—è dietro l’angolo

L’EOL di MySQL (fine del supporto) non è rilevante solo per il personale IT. Colpisce l’intera organizzazione in termini di sicurezza, prestazioni, disponibilità e gestione dei costi.

MySQL 5.7 ha già raggiunto la fine del supporto nell’ottobre 2023, e MySQL 8.0 è previsto raggiungere la fine del supporto premium ad aprile 2025. Se pensate “funziona ancora, quindi va bene”, potreste finire per operare con un rischio critico prima di rendervene conto.

La migrazione pianificata è la migliore strategia di evitamento del rischio

Come mostrato in questo articolo, la migrazione non è difficile quando fatta passo dopo passo:

• Identificare la versione corrente
• Controllare la compatibilità e scegliere una destinazione di migrazione
• Test in un ambiente di staging
• Eseguire migrazione graduale e cutover finale

Seguendo questi passaggi, è possibile completare la migrazione in sicurezza evitando downtime e perdita di dati.

Anche quando si utilizzano servizi cloud, non lasciate tutto al fornitore—comprendete la vostra situazione e costruite proattivamente un piano di aggiornamento.

“Non lo sapevo” non è più una scusa

Nelle operazioni di sistema moderne, ciò che è richiesto non è solo conoscenza tecnica ma anche consapevolezza della manutenzione continua. Conoscere le tempistiche di fine supporto, valutare il rischio e scegliere la migliore opzione di migrazione sono abilità essenziali per tutti gli operatori e sviluppatori.

Infine: tre azioni da intraprendere subito

1. Controllare la versione MySQL utilizzata nel vostro sistema
2. Confermare la data EOL e metterla in calendario
3. Discutere il vostro approccio di migrazione (aggiornamento vs. cambio database) con il team

Anche facendo solo queste renderà chiaro il vostro prossimo passo.

Gestire la fine vita di MySQL è una “polizza assicurativa” contro futuri incidenti.
Usa questo articolo come spunto per rivedere le tue operazioni e creare un ambiente più sicuro e sostenibile.