# Migrazione del database senza downtime: ci stai nella finestra?

> MySQL, MariaDB o PostgreSQL: le strategie che il tuo caso permette, il fermo stimato contro la finestra che hai e i rischi concreti della migrazione.

Strumento gratuito nel browser (nessun upload): https://www.mauriziofonte.it/strumenti/migrazione-database-senza-downtime

Dichiari motore, versioni, dimensioni, scritture e la finestra di fermo che hai. Lo strumento sceglie le strategie possibili **per regole, non per preferenza**, stima il fermo di ciascuna e ti dice **se ci stai o no**. Poi elenca i rischi del tuo caso, a partire da una versione fuori supporto.

## Come si usa

1. **Indica partenza e arrivo** - Motore e versione di partenza, motore e versione di destinazione. Basta la versione principale.
2. **Dai le misure** - Dimensione totale, tabella più grande, scritture al minuto nell'ora di punta e la finestra di fermo che puoi permetterti.
3. **Spunta cosa vale** - Log binario o WAL, chiavi primarie, cambio di charset o di schema, chiavi esterne, trigger, database gestiti, applicazione modificabile.
4. **Leggi il verdetto** - Ci stai o non ci stai, con la strategia più rapida tra quelle possibili e il perché delle escluse.
5. **Porta via i rischi** - Il registro dei rischi è costruito sul tuo caso, con i collegamenti agli articoli che li spiegano. Si copia in Markdown.

## Perché un verdetto secco

La domanda vera, prima di una migrazione, è una sola: il fermo che serve sta dentro la finestra che hai? Un elenco di buone pratiche non risponde. Un confronto tra due numeri sì, e quando la risposta è no lo strumento lo dice, insieme a cosa la cambierebbe: attivare il log binario, poter toccare l'applicazione, rimandare la conversione del charset.

Il registro dei rischi nasce dai dati che inserisci, non da una lista fissa. Una conversione a utf8mb4 porta valori troncati, collation diverse e testi codificati due volte; un salto da MySQL 5.7 porta parole riservate nuove e un altro plugin di autenticazione; una destinazione gestita porta i limiti sui privilegi. E se la versione di partenza è fuori supporto, il verdetto si apre con quello.

## Glossario

- **Finestra di fermo**: Il tempo in cui l'applicazione può restare ferma senza danni: notte, fine settimana, manutenzione concordata.
- **Log binario**: Il registro delle modifiche di MySQL e MariaDB che le repliche leggono per restare allineate.
- **WAL**: Write-ahead log di PostgreSQL: il registro delle modifiche su cui si basano replica fisica e logica.
- **Passaggio**: Il momento in cui si fermano le scritture, si verifica l'allineamento e l'applicazione punta al nuovo database.
- **Collation**: Le regole con cui il database confronta e ordina i testi: maiuscole, accenti, lingua.
- **DEFINER**: L'utente con i cui privilegi gira un trigger, una vista o una procedura in MySQL.

## Domande frequenti

### Si può migrare un database MySQL senza fermare il sito?

Quasi sempre il fermo si riduce a pochi minuti, quelli del passaggio finale. Serve una strategia online: replica logica dal log binario, promozione di una replica o, se l'applicazione si può modificare, doppia scrittura o blue-green. Zero assoluto è raro, perché per qualche secondo le scritture vanno fermate per non perdere dati.

### Quanto dura un dump di MySQL?

Dipende da dischi, compressione, numero di tabelle e strumento. Lo strumento parte da 30 GB all'ora per il dump e 10 per il restore con gli indici, valori di partenza da sostituire con una misura su una copia: i comandi per farla sono nella sezione sulla misura.

### Perché il restore è più lento del dump?

Perché il restore ricostruisce gli indici e verifica i vincoli, mentre il dump legge e scrive testo. Con molte tabelle indicizzate il tempo di restore può essere un multiplo di quello del dump.

### Cosa succede alle scritture durante un dump?

Con --single-transaction su tabelle InnoDB il dump non blocca le scritture, ma quelle successive al suo inizio non sono nel file. Per questo, con dump e restore, le scritture vanno fermate dall'inizio del dump alla fine del restore.

### Convertire a utf8mb4 è rischioso?

Va provato sui dati veri. I rischi tipici sono tre: valori che non entrano più nelle colonne perché un carattere può occupare 4 byte, ordinamenti e confronti diversi con la nuova collation, e testi codificati due volte se la connessione dichiara un charset sbagliato.

### Posso passare da MySQL 5.7 a 8.4 in un colpo?

Con un dump e restore sì, provando lo schema e le query sulla nuova versione. Un aggiornamento sul posto invece passa da 8.0. In entrambi i casi conviene usare il controllo di compatibilità di MySQL Shell, util.checkForServerUpgrade.

### La replica logica funziona tra MySQL e PostgreSQL?

Non in modo nativo: servono strumenti di terze parti che leggono il log binario e scrivono su PostgreSQL. Per questo lo strumento considera la replica logica solo tra motori compatibili, lo stesso motore o da MySQL a MariaDB.

### Perché lo strumento parla della fine del supporto?

Perché una versione fuori supporto non riceve più correzioni di sicurezza, ed è spesso il motivo vero della migrazione. Se la versione di partenza è fuori supporto o lo sarà entro sei mesi, il verdetto si apre con quella data.

### I dati che inserisco vengono salvati?

No. Il calcolo avviene in JavaScript nella pagina: i dati non vengono mandati a un server per ottenere il risultato e lo strumento non li salva nel browser. Come il resto del sito, la pagina raccoglie statistiche di navigazione.

---
Uno strumento di Maurizio Fonte, senior backend engineer. Tutti gli strumenti: https://www.mauriziofonte.it/strumenti/