Installare MySQL 5.7 su AlmaLinux 9 e Rocky Linux

Su AlmaLinux 9 e Rocky Linux 9 installare MySQL 5.7 non è un’operazione “standard”: le distribuzioni Enterprise Linux 9 spingono su stack più recenti e, in molti casi, il pacchetto desiderato non è disponibile nei repository di base. Questo significa una cosa semplice: se devi davvero rimanere su 5.7, devi trattare l’intervento come un change controllato, non come una normale installazione di routine.

La domanda giusta, prima ancora dei comandi, è questa: perché 5.7? Se l’applicazione è compatibile con MySQL 8.0, la strada più pulita è aggiornare lo stack. Se invece hai vincoli applicativi, dump storici, query legacy o un vendor che richiede esplicitamente 5.7, allora si può procedere, ma con una consapevolezza chiara: stai scegliendo una versione fuori dal ciclo moderno della piattaforma e questo impatta supporto, sicurezza e manutenzione.

Prima di installare: verifica il vincolo reale

Prima di toccare il sistema, verifica tre cose: compatibilità applicativa, spazio su disco e presenza di eventuali servizi database già installati. Se sul server esiste già MariaDB o un altro MySQL, la convivenza va pianificata con attenzione perché porte, socket, path dati e pacchetti possono sovrapporsi.

Controlla lo stato attuale del sistema con questi comandi:

cat /etc/redhat-release
rpm -qa | egrep 'mysql|mariadb'
df -h /var /var/lib /tmp
ss -ltnp | grep 3306 || true

Se il comando su MySQL/MariaDB restituisce pacchetti già presenti, fermati e valuta la migrazione o la rimozione controllata. Se la porta 3306 è occupata, non forzare: prima identifica quale servizio la sta usando.

Repository MySQL corretto per EL9

Per AlmaLinux 9 e Rocky Linux 9, la strada più lineare è usare il repository ufficiale MySQL per Enterprise Linux 9. In pratica, aggiungi il repository dedicato e poi installi il pacchetto server. L’obiettivo è evitare mix pericolosi con repository terzi non allineati al sistema.

Scarica e installa il pacchetto repo ufficiale, poi verifica che il file sia presente in /etc/yum.repos.d/:

sudo dnf install -y https://dev.mysql.com/get/mysql80-community-release-el9-1.noarch.rpm
rpm -qi mysql80-community-release
ls -l /etc/yum.repos.d/mysql-community*.repo

A questo punto c’è un dettaglio importante: il repository “community” è pensato per le linee recenti. Per ottenere 5.7, in molti ambienti serve abilitare la sorgente corretta e disabilitare il resto. Tuttavia, la disponibilità effettiva di 5.7 su EL9 può variare in base al momento e alla policy del repository. Se il pacchetto non compare, non inventare workaround: devi prima verificare cosa il repository espone davvero.

Controlla i pacchetti disponibili così:

sudo dnf --disablerepo='*' --enablerepo='mysql*' list available | grep -E '^mysql-community-server\.'

Se non vedi una build 5.7, il punto non è il server: è il repository. In quel caso, la soluzione corretta non è “forzare” il sistema, ma scegliere una fonte compatibile, oppure ripensare la versione da installare.

Installazione del server MySQL 5.7

Se il repository espone effettivamente il ramo desiderato, puoi procedere con l’installazione del server. Prima di farlo, fai un backup della configurazione e annota lo stato dei servizi presenti, così hai un rollback semplice se qualcosa non torna.

Installa il pacchetto server e client essenziale:

sudo dnf install -y mysql-community-server mysql-community-client

Se il sistema propone dipendenze conflittuali con MariaDB o con versioni già presenti, non aggirare il problema alla cieca. Prima individua i pacchetti in conflitto:

sudo dnf repoquery --installed | egrep 'mysql|mariadb'
sudo dnf provides '*/mysqld'

In presenza di conflitti, la modifica ha un blast radius chiaro: riguarda database, applicazione e potenzialmente i servizi che dipendono dal socket o dalla porta 3306. Il rollback, in questo caso, deve essere immediato: rimozione del pacchetto appena installato e ripristino del backup di configurazione se già modificato.

Inizializzazione del servizio e primo avvio

Una volta installato il pacchetto, abilita e avvia il servizio. Su EL9 il comportamento standard passa da systemd, quindi il controllo è semplice e verificabile.

sudo systemctl enable --now mysqld
sudo systemctl status mysqld --no-pager

Il primo avvio genera o prepara i file iniziali sotto /var/lib/mysql. Se il servizio non parte, guarda subito i log del journal:

sudo journalctl -u mysqld -b --no-pager | tail -n 80

Le cause più frequenti del fallimento iniziale sono tre: directory dati con permessi errati, porta occupata, oppure incompatibilità tra stato precedente del datadir e versione del server. In tutti e tre i casi, il journal ti dice rapidamente dove guardare.

Password iniziale e hardening minimo

Dopo il primo avvio, recupera la password temporanea se presente nel log, oppure verifica il metodo di autenticazione impostato dal pacchetto. Su alcune distribuzioni il server può generare credenziali iniziali o predisporre l’utente root con accesso locale tramite socket. Non dare per scontato il comportamento: controlla il file di log e il metodo di accesso effettivo.

sudo grep 'temporary password' /var/log/mysqld.log || true
sudo mysql

Una volta entrato, imposta una password forte per l’account amministrativo se il tuo scenario lo richiede, rimuovi accessi anonimi e disabilita l’accesso remoto all’utente root salvo necessità esplicite. Se il server deve essere esposto solo localmente, lascia MySQL in ascolto su 127.0.0.1 o sul socket Unix.

Per un hardening minimo, verifica queste impostazioni nel file /etc/my.cnf o nei file inclusi sotto /etc/my.cnf.d/:

[mysqld]
bind-address=127.0.0.1
skip-name-resolve=1
symbolic-links=0

Se modifichi la configurazione, salva prima una copia del file originale. Il rollback deve essere banale: ripristino del file precedente e riavvio del servizio.

Verifica funzionale: servizio, porta e accesso SQL

La verifica non si ferma a “il servizio è attivo”. Devi controllare anche che MySQL accetti connessioni e che il motore risponda correttamente. Il test più semplice è una query di stato.

mysql -uroot -p -e "SELECT VERSION(), @@hostname, @@port;"

L’output atteso deve mostrare una versione 5.7.x, l’hostname del server e la porta prevista, di solito 3306. Se la connessione fallisce, separa il problema in tre livelli: servizio in ascolto, autenticazione, schema dati.

Puoi fare un controllo rapido della porta con:

ss -ltnp | grep 3306
sudo firewall-cmd --list-ports

Se il firewall è attivo e il database deve essere raggiungibile da altri host, apri solo la sorgente necessaria e non tutto il mondo. Il blast radius qui è evidente: esporre 3306 in modo troppo ampio aumenta il rischio di scansioni e tentativi di login.

Configurazione della memoria e del carico

Su server con poca RAM, MySQL 5.7 può funzionare bene, ma solo se dimensioni correttamente i parametri principali. L’impostazione più delicata è innodb_buffer_pool_size: troppo bassa e perdi prestazioni, troppo alta e rischi pressione di memoria sul sistema.

Una regola pratica: se il server ospita solo MySQL, il buffer pool può occupare gran parte della RAM disponibile; se invece il database convive con web server e PHP-FPM, va tenuto più prudente. Non esiste un valore universale, ma esiste un criterio: osserva swap, OOM e latenza delle query dopo il cambiamento.

Un esempio di configurazione prudente:

[mysqld]
innodb_buffer_pool_size=1G
max_connections=200
tmp_table_size=64M
max_heap_table_size=64M

Dopo ogni modifica, riavvia solo se necessario e misura l’effetto. Se la macchina ha risorse limitate, monitora free -m, top o meglio i metric collector già presenti nel tuo stack.

Database esistente: migrazione o nuova istanza

Se stai installando MySQL 5.7 su un host che aveva già dati, il punto critico non è il pacchetto ma il datadir. Il passaggio da un’istanza all’altra va pianificato con backup completi e test di ripristino. Non limitarti a copiare i file a mano: per un database, il backup va verificato, non solo creato.

Per un cambio controllato, la sequenza corretta è: dump logico, stop del servizio, backup del datadir, installazione, avvio, importazione, verifica applicativa. Se il database è piccolo, il dump logico è spesso il metodo più pulito. Se è grande o con downtime ridotto, serve una strategia più articolata.

mysqldump --single-transaction --routines --triggers --events -u root -p --all-databases > all-databases.sql

Il file generato va conservato fuori dal server se possibile. Il rollback, in questo scenario, è il ripristino del dump o del backup del datadir, a seconda della strategia scelta.

Firewall, SELinux e accesso remoto

Su AlmaLinux e Rocky Linux 9, SELinux non va trattato come un fastidio opzionale. Se lasci il server in enforcing, bene: significa che stai lavorando con un profilo di sicurezza reale. Se invece qualcosa non funziona, prima controlla i contesti e i log AVC, poi valuta eventuali policy o boolean necessari.

Per il firewall, apri la porta solo se il database deve essere raggiungibile dall’esterno della macchina:

sudo firewall-cmd --permanent --add-service=mysql
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Se invece il database è destinato a uso locale, non aprire la porta. È una scelta più sicura e riduce la superficie d’attacco.

Problemi tipici e come leggerli senza perdere tempo

Se il servizio non parte, non andare subito a modificare la configurazione. Leggi prima il log e isola la causa. I casi ricorrenti sono: datadir non inizializzato, permessi errati su /var/lib/mysql, porta occupata, versione incompatibile dei file dati.

Una sequenza diagnostica rapida può essere questa:

sudo systemctl status mysqld --no-pager
sudo journalctl -u mysqld -b --no-pager | tail -n 50
ls -ld /var/lib/mysql
sudo getenforce

Se vedi errori di permesso, correggi ownership e contesti solo dopo aver capito cosa è cambiato sul filesystem. Se vedi errori di SELinux, controlla i log dedicati prima di disattivarlo. Disabilitare SELinux come “fix” è una scorciatoia che sposta il problema, non lo risolve.

Quando conviene fermarsi e cambiare piano

Ci sono situazioni in cui insistere con MySQL 5.7 su EL9 non è la scelta migliore. Se il repository non espone più il pacchetto, se il software applicativo è già compatibile con 8.0, o se il server deve restare mantenuto per anni, la soluzione più sana è aggiornare versione e schemi invece di aggirare il problema. È una valutazione tecnica, non ideologica.

In un ambiente serio, la domanda finale non è “si riesce a installarlo?”, ma “si riesce a mantenerlo in modo sicuro e prevedibile?”. Se la risposta è no, il costo operativo di un’eccezione permanente supera presto il vantaggio iniziale.

Assunzione operativa: il server è in produzione o comunque gestito come tale; ogni modifica va preceduta da verifica del repository disponibile, backup della configurazione e controllo dei log di servizio.