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.
Aggiornato il · da Maurizio Fonte
Il calcolo avviene nella pagina: i dati non vengono mandati a un server per ottenere il risultato. La pagina scarica solo l'elenco pubblico delle date di fine supporto.
Motore e versione di partenza, motore e versione di destinazione. Basta la versione principale.
Dimensione totale, tabella più grande, scritture al minuto nell'ora di punta e la finestra di fermo che puoi permetterti.
Log binario o WAL, chiavi primarie, cambio di charset o di schema, chiavi esterne, trigger, database gestiti, applicazione modificabile.
Ci stai o non ci stai, con la strategia più rapida tra quelle possibili e il perché delle escluse.
Il registro dei rischi è costruito sul tuo caso, con i collegamenti agli articoli che li spiegano. Si copia in Markdown.
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.
Ogni strategia ha condizioni che si possono verificare dai dati che inserisci. Lo strumento non sceglie quella che preferisce: tiene quelle le cui condizioni sono tutte vere e, tra queste, indica quella con il fermo più breve. Per ogni strategia esclusa scrive quale condizione manca.
Le strategie online fermano le scritture solo per il passaggio finale. Il dump e restore le ferma dall'inizio alla fine.
Le due velocità che lo strumento usa (30 GB all'ora per il dump, 10 per il restore con gli indici) sono valori di partenza. Su una copia del database si misurano in poco tempo:
time mysqldump --single-transaction --routines --events nome_db | gzip > dump.sql.gz, poi time (gunzip < dump.sql.gz | mysql nome_db_prova) su un server simile alla destinazione;time pg_dump -Fd -j 4 -f dump nome_db, poi time pg_restore -j 4 -d nome_db_prova dump.Dividi i GB per le ore misurate e scrivi i due numeri nel risultato con la matita: il verdetto si ricalcola con i tuoi valori.
Non legge il codice. Non sa quanto ritardo di replica l'applicazione tollera, se rilegge subito un dato appena scritto, o quali query si rompono con un nuovo sql_mode o una nuova collation. Sono le domande che decidono il giorno del passaggio.
Le velocità di dump e restore variano molto con dischi, rete, numero di indici e strumento usato, per questo restano modificabili. E le date di fine supporto vengono dal dataset pubblico di endoflife.date, aggiornato ogni giorno: per una decisione contrattuale vale la pagina del produttore.
Termini tecnici usati in questa pagina, spiegati in due righe.
Leggi, tabelle ufficiali e implementazioni di riferimento su cui è stata verificata la logica del tool.
Risposta entro 2 giorni lavorativi, entro 24 ore per emergenze tecniche. La prima call conoscitiva dura un'ora, è gratuita e non vincolante. Al termine ti dico con chiarezza se posso aiutarti, o ti indico chi può farlo meglio di me.
Scrivimi senza impegnoWizard di 7 domande, 2 minuti, gratuito. Output: range di giorni-uomo, range di prezzo orientativo e raccomandazione di ingaggio. Tariffa di riferimento 400 euro al giorno. Pensato per progetti backend custom, integrazioni, audit di sicurezza o automazione AI.
Calcola il preventivo