Migrare MySQL 5.7 e 8.0 da Docker a MariaDB 10.11 senza perdere utenti e permessi

Guida basata su un intervento sistemistico concluso e verificato. Caso reale: 47 database migrati da due istanze MySQL in container a MariaDB nativo. Inventario, dump, utenti, grants, test e cutover controllato.

Il problema

Un server ospitava due motori MySQL in container, versione 5.7 e 8.0, con un HAProxy locale che inoltrava la porta 3306 a un backend diverso. L'obiettivo era arrivare a MariaDB 10.11 nativo, mantenendo database, utenti, privilegi e applicazioni come Magento, Laravel, ISPConfig, Postfix, Dovecot e phpMyAdmin. L'intervento si è concluso con 47 database migrati; i vecchi container e i backup sono stati mantenuti per un possibile rollback.

Inventario prima del cambio

Prima di importare occorre misurare dimensioni, versioni, utenti e definizioni degli oggetti SQL. I dump di dati e definizioni dei GRANT vanno acquisiti separatamente. I riferimenti ad account DEFINER, plugin di autenticazione e differenze di collazione tra MySQL 8.0 e MariaDB richiedono un controllo dedicato.

Comandi di ricognizione

docker ps --format 'table {{.Names}}	{{.Image}}	{{.Ports}}'
mysql --version
mariadb --version
mysql -NBe "SHOW DATABASES;"
mysql -NBe "SELECT User,Host,plugin FROM mysql.user ORDER BY User,Host;"
mysql -NBe "SHOW VARIABLES LIKE 'version';"
ss -ltnp | grep ':3306'
grep -RInE '127\.0\.0\.1:3308|3306|3309' /etc/haproxy /etc/mysql 2>/dev/null

Per le istanze Docker si eseguono gli stessi controlli con docker exec, utilizzando un account amministrativo valido. Non copiare direttamente le tabelle di sistema mysql.* fra versioni diverse.

Dump, test e import

# Esempio: eseguire separatamente per ciascuna istanza
mysqldump --single-transaction --routines --events --triggers   --hex-blob --databases NOME_DB > NOME_DB.sql
sha256sum NOME_DB.sql > NOME_DB.sql.sha256

# Sul sistema di destinazione
mariadb --socket=/run/mysqld/mysqld.sock < NOME_DB.sql
mariadb -e "SHOW DATABASES;"

Nel caso reale è stato usato anche un MariaDB temporaneo con socket e datadir separati, in modo da verificare il risultato senza toccare l'istanza in produzione. I dump delle due origini non devono sovrascrivere accidentalmente database con lo stesso nome: prima del cutover confrontare l'elenco dei database e stabilire l'ordine di import.

Utenti, privilegi e autenticazione

Per ogni account applicativo ricreare l'utente con il plugin appropriato, assegnare solo i GRANT necessari e verificare le connessioni da localhost e dalle interfacce effettivamente usate. Sono stati esaminati oltre cento account e numerosi GRANT, con esclusione esplicita degli account di sistema. Prestare attenzione a DEFINER di viste, trigger e procedure.

Cutover e verifica

mariadb -e "SHOW DATABASES;"
mariadb -e "SELECT COUNT(*) FROM information_schema.SCHEMATA;"
mariadb -e "SHOW PROCESSLIST;"
systemctl status mariadb --no-pager
ss -ltnp | grep ':3306'

Dopo l'aggiornamento dei file di configurazione delle applicazioni, verificare login, lettura e scrittura per ogni servizio, non soltanto la connessione al database. In questo caso i client sono stati riconfigurati verso MariaDB nativo e il proxy SQL locale è stato rimosso. I vecchi container sono stati conservati spenti e non cancellati immediatamente.

Errori da evitare

Non cambiare simultaneamente più variabili senza una copia consistente dei dati. Non importare indiscriminatamente la tabella mysql.user di MySQL in MariaDB. Non eliminare subito container e volumi Docker. Per ogni applicazione eseguire un test funzionale e prevedere un percorso di ritorno ai backup.

Guide correlate

I comandi con nomi segnaposto vanno adattati al proprio ambiente. Le configurazioni di produzione, gli IP e le credenziali non sono riportati.