Come installare MySQL 8.0 su Debian 11 Bullseye

MySQL 8.0 su Debian 11 Bullseye: scelta del repository e impatto sul sistema

Su Debian 11 il punto critico non è tanto l’installazione in sé, quanto la scelta della sorgente pacchetti. I repository ufficiali di Bullseye non sempre allineano la versione che vuoi davvero in produzione, mentre MySQL 8.0 richiede una gestione pulita del repository per evitare conflitti con MariaDB o con metapacchetti già presenti. Se l’obiettivo è avere MySQL 8.0 e non un sostituto compatibile, conviene essere espliciti fin dall’inizio: repo corretto, installazione minimale, verifica del servizio, hardening iniziale e controllo del percorso dati.

Qui assumo un sistema Debian 11 recente, accesso root o sudo e nessun database server già in ascolto sulla porta 3306. Se invece sul nodo è già presente MariaDB o un MySQL precedente, la procedura va adattata prima di toccare i pacchetti: verificare chi occupa la porta, quali file di configurazione sono già in uso e se esistono dati da preservare.

Verifica preliminare: conflitti, spazio e stato del sistema

Prima di installare, conviene controllare tre cose: spazio disco, eventuali servizi già attivi e versione della base OS. È un passaggio banale, ma evita di scoprire dopo che il demone non parte perché il filesystem è pieno o perché un altro server SQL è già bindato sulla stessa porta.

Esegui questi controlli:

cat /etc/debian_version
df -h /
ss -ltnp | grep 3306 || true
systemctl --type=service --state=running | egrep 'mysql|mariadb' || true

Atteso: Debian 11.x, spazio libero sufficiente su `/` e nessun processo in ascolto su `3306` se stai facendo una nuova installazione. Se trovi MariaDB attivo, non procedere alla cieca: MySQL e MariaDB possono coesistere solo con attenzione ai binari, al socket e ai dati. In molti casi la soluzione corretta è migrare, non sovrapporre.

Repository MySQL: installazione del pacchetto ufficiale

Su Debian la via più controllabile è usare il pacchetto del repository MySQL ufficiale. L’alternativa è installare dai repository del sistema, ma così perdi il controllo preciso sulla major version e rischi di ritrovarti una versione diversa da quella prevista dal progetto o dal supporto applicativo.

Scarica il pacchetto di configurazione del repository dal sito Oracle e installalo con dpkg. Il nome del file cambia nel tempo, quindi qui conta il metodo: prendere il pacchetto corretto per Debian 11 e la release MySQL 8.0 disponibile al momento.

wget https://dev.mysql.com/get/mysql-apt-config_0.8.29-1_all.deb
sudo dpkg -i mysql-apt-config_0.8.29-1_all.deb

Durante la configurazione interattiva seleziona MySQL Server & Cluster e imposta MySQL 8.0. Se il sistema è usato in modo standard, lascia invariata la parte relativa agli altri componenti. L’obiettivo è evitare repository inutili o versioni non allineate al tuo standard operativo.

Dopo la configurazione aggiorna l’indice pacchetti e verifica che il repository sia effettivamente presente:

sudo apt update
apt-cache policy mysql-server

Atteso: nella policy di mysql-server deve comparire una candidate coerente con MySQL 8.0 e il repository MySQL deve essere visibile tra le origini. Se non compare, il problema non è l’installazione ma la configurazione del repository; in quel caso controlla i file in /etc/apt/sources.list.d/ e la chiave associata al repo.

Installazione del server e dei client essenziali

Per un’installazione pulita non serve portarsi dietro mezzo ecosistema. In genere bastano server, client e librerie base. Se ti servono strumenti aggiuntivi per scripting o applicazioni legacy, li aggiungi dopo, non prima.

sudo apt install mysql-server mysql-client

Durante l’installazione il pacchetto può inizializzare il data directory e attivare il servizio systemd. A fine installazione verifica subito lo stato del demone:

systemctl status mysql --no-pager
journalctl -u mysql -b --no-pager | tail -n 50

Atteso: servizio active (running) e nessun errore di InnoDB, permission denied o collisione sulla porta. Se il servizio fallisce, il journal è la prima fonte da leggere: spesso il problema è un residuo di configurazione precedente, un percorso dati non accessibile o una directory con ownership errata.

Verifica del socket, della porta e dell’accesso locale

Una volta avviato, MySQL va testato con due viste diverse: quella di systemd e quella del protocollo SQL. Il servizio può risultare attivo ma non accettare connessioni per problemi di autenticazione, socket o binding su localhost.

Controlla che il server ascolti e che il client locale riesca a entrare con il metodo previsto dal sistema Debian:

ss -ltnp | grep 3306
sudo mysql -e 'SELECT VERSION();'

Il comando sudo mysql sfrutta l’autenticazione locale di default, che su Debian spesso è più ordinata del classico accesso con password in chiaro nel terminale. Se il comando non entra, il gap da chiudere è il plugin di autenticazione o il socket: verifica /etc/mysql/my.cnf e i file inclusi in /etc/mysql/mysql.conf.d/.

Hardening iniziale: ridurre superficie e credenziali deboli

Su un server appena installato la parte più utile non è il tuning, ma la riduzione dell’esposizione. MySQL va lasciato accessibile in rete solo se serve davvero. Se l’istanza è per uso locale o per un’app sullo stesso host, il binding su loopback è la scelta più prudente.

Verifica il parametro di ascolto e, se necessario, imposta il server su localhost. Il file tipico da controllare è /etc/mysql/mysql.conf.d/mysqld.cnf.

grep -nE '^(bind-address|skip-networking)' /etc/mysql/mysql.conf.d/mysqld.cnf

Se il server deve essere raggiungibile solo localmente, una configurazione sensata è:

# /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address = 127.0.0.1

Dopo la modifica, ricarica il servizio e verifica che sia ancora operativo:

sudo systemctl restart mysql
systemctl status mysql --no-pager
ss -ltnp | grep 3306

Blast radius: il restart interrompe tutte le connessioni attive e può impattare applicazioni che usano MySQL in quel momento. Rollback: ripristina il file di configurazione precedente e riavvia il servizio. Se lavori su un nodo applicativo, avvisa o esegui in finestra di manutenzione.

A questo punto esegui il controllo base delle installazioni fresche: utenti anonimi, database di test e accesso remoto non richiesto. Su MySQL 8.0 la vecchia utility mysql_secure_installation resta utile, ma la sua interazione dipende dal setup del pacchetto e dal tipo di autenticazione iniziale. Se il tuo ambiente la supporta, usala; altrimenti chiudi manualmente i punti deboli con SQL mirato.

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"
sudo mysql -e "SHOW DATABASES;"

Atteso: niente utenti anonimi, nessun account inatteso su host remoti e solo i database standard previsti. Se trovi account ereditati da installazioni precedenti, non cancellare a caso: identifica prima l’applicazione che li usa, poi pianifica la rotazione delle credenziali.

Autenticazione e account amministrativo: evitare password in chiaro

Per l’uso amministrativo locale su Debian la strada più ordinata è mantenere l’accesso root MySQL legato all’autenticazione del sistema, quando compatibile con il tuo modello operativo. Se invece devi esporre un account amministrativo applicativo, crea un utente dedicato con privilegi minimi e password ruotata fuori banda, non incollata in shell history o file condivisi.

Esempio di creazione di un account amministrativo limitato all’host locale, da adattare al tuo caso reale:

sudo mysql -e "CREATE USER 'admin_local'@'localhost' IDENTIFIED BY 'CHANGE_ME';"
sudo mysql -e "GRANT ALL PRIVILEGES ON *.* TO 'admin_local'@'localhost' WITH GRANT OPTION;"
sudo mysql -e "FLUSH PRIVILEGES;"

Questo esempio è volutamente conservativo solo per mostrare la sintassi. In produzione la password non va lasciata in chiaro nel comando: usa un prompt sicuro, un vault o un file temporaneo con permessi stretti e cancellazione immediata. Se l’account serve a un’applicazione, togli il privilegio globale e limita schema, host e operazioni al minimo indispensabile.

Controllo del percorso dati e backup del primo stato buono

Subito dopo l’installazione conviene fotografare lo stato buono, perché è il punto da cui poi confrontare eventuali problemi futuri. Il data directory di default su Debian è in genere sotto /var/lib/mysql, ma non dare per scontato che permessi e ownership siano corretti se il sistema è stato riutilizzato o se il pacchetto ha ereditato residui di configurazioni precedenti.

Verifica i permessi e il datadir reale direttamente dal server:

sudo mysql -e "SHOW VARIABLES LIKE 'datadir';"
ls -ld /var/lib/mysql
sudo find /var/lib/mysql -maxdepth 1 -type f | head

Atteso: ownership coerente con l’utente del servizio MySQL e directory accessibili solo al demone e all’amministratore. Se il datadir non è quello previsto, fermati e allinea la configurazione prima di continuare: cambiare percorso dati dopo aver caricato dati reali è una fonte classica di errori e downtime evitabile.

Per avere un punto di ritorno semplice, salva almeno la configurazione server e l’elenco pacchetti installati:

dpkg -l | grep -E '^ii\s+mysql|^ii\s+libmysql'
sudo cp -a /etc/mysql /root/etc-mysql-backup-$(date +%F)

Questo non è un backup del database, ma è il minimo per poter tornare indietro lato configurazione senza dover ricostruire a memoria il setup iniziale. Se il server diventa la base di un servizio importante, il passo successivo è un backup consistente dei dati con strategia di restore testata.

Problemi tipici dopo l’installazione e come leggerli senza perdere tempo

Se MySQL parte ma le applicazioni non si connettono, il primo sospetto non è il database “rotto”, ma un mismatch tra ascolto, socket e credenziali. Se il servizio non parte, il sospetto va invece a configurazione, permessi o conflitti di versione. La differenza è importante: cambia completamente il primo comando da lanciare.

Tre letture rapide che in pratica risolvono buona parte dei casi:

Se devi aprire MySQL verso altri host, non limitarti a cambiare bind-address. Devi anche verificare firewall, policy di rete, privilegi dell’utente MySQL e, se presente, la configurazione del layer di sicurezza a monte. Aprire la porta 3306 senza regole precise è esattamente il tipo di modifica che crea esposizione inutile senza beneficio operativo.

Quando fermarsi e non trasformare un’installazione in una migrazione

Se sul server esiste già un database con dati da conservare, questa procedura non basta. In quel caso il problema non è “installare MySQL 8.0”, ma capire come convivere o migrare senza corrompere il servizio esistente. La presenza di MariaDB, di un vecchio MySQL o di configurazioni custom in /etc/mysql/conf.d/ cambia il quadro: prima si inventaria, poi si decide se sostituire, affiancare o migrare.

Le domande giuste, prima di toccare i pacchetti, sono queste: quali applicazioni usano il database, quali versioni di client si collegano, quale schema di autenticazione è in uso e quale downtime è accettabile. Senza queste risposte, qualsiasi installazione “veloce” rischia di diventare un incidente di produzione travestito da manutenzione.

Se parti da una macchina pulita, invece, il flusso corretto è semplice: repository ufficiale, installazione minima, verifica del servizio, hardening base, controllo del datadir e backup della configurazione iniziale. È un percorso breve, ma solo se lo si tiene disciplinato. MySQL funziona bene quando il sistema attorno è ordinato; se il sistema è ambiguo, il database è solo il primo a mostrartelo.