database
Come migrare un database (Postgres/MySQL) sul tuo VPS
Una guida in parole semplici per spostare un database Postgres o MySQL sul tuo server senza perdere dati, rompere la tua app o rendere la configurazione impossibile da capire in futuro.
La migrazione di un database rappresenta uno dei passaggi più delicati nella gestione dell'infrastruttura: costituisce la memoria storica dell'applicazione, custodendo utenti, ordini, contenuti, impostazioni, transazioni e tutti quei dati critici non ricostruibili manualmente.
In sintesi: per migrare un database su un server proprietario, occorre esportare i dati dalla sorgente PostgreSQL o MySQL, ripristinarli sul nuovo ambiente, aggiornare le stringhe di connessione dell'applicazione e verificare il corretto funzionamento delle operazioni di lettura e scrittura prima di dismettere l'infrastruttura di origine. Un approccio sicuro non si limita al mero trasferimento dei dati: richiede l'esecuzione preventiva di un backup, la pianificazione di una finestra di manutenzione per sospendere o sincronizzare le Scritture, la verifica di estensioni e permessi utente, e il mantenimento del vecchio database fino a completa conferma di stabilità.
Cosa stai spostando davvero?
Un database non si riduce a un singolo file presente nel filesystem; è un'architettura complessa paragonabile a una biblioteca strutturata, dotata di cataloghi, indici, regole di accesso e sistemi di sicurezza.
Quando si migra un'istanza PostgreSQL o MySQL, si trasferiscono principalmente quattro componenti fondamentali:
- Tabelle e dati: le strutture relazionali e i record effettivi.
- Schema: la definizione della struttura dati, inclusi tipi di colonna, indici, vincoli e relazioni di integrità referenziale.
- Utenti e privilegi: la gestione delle identità e dei permessi di accesso per la connessione e la manipolazione dei dati.
- Componenti specifiche del motore: come le estensioni in PostgreSQL o i set di caratteri e le collation in MySQL.
Per questi motivi, una migrazione apparentemente riuscita può mostrare anomalie in un secondo momento. L'applicazione potrebbe caricare correttamente la homepage ma rallentare nelle ricerche a causa dell'assenza di un indice, rifiutare l'autenticazione per via di privilegi utente non allineati o mostrare errori di codifica del testo dovuti a una discrepanza tra i set di caratteri.
Prima di avviare qualsiasi procedura, esegui un backup completo e collauda la procedura di ripristino. Un piano di salvataggio non testato non offre alcuna garanzia operativa. Per approfondire le buone pratiche di protezione dei dati, consulta la nostra guida su come fare il backup del server ed essere davvero in grado di ripristinarlo.
Meglio dump e restore, o replica?
Per la maggior parte dei progetti di dimensioni contenute o medie, la strategia basata su dump e restore risulta la scelta più indicata. Questa procedura consiste nell'esportare uno snapshot dal database sorgente, importarlo nel nuovo ambiente e reindirizzare successivamente l'applicazione. È un processo assimilabile alla creazione di una copia integrale dell'archivio durante una chiusura programmata.
La replica adotta un approccio differente: mantiene sincronizzate le istanze sorgente e destinazione in tempo reale, consentendo un passaggio finale con tempi di inattività minimi.
| Metodo | Ideale per | Rischio principale |
|---|---|---|
| Dump e restore | Applicazioni a traffico contenuto che possono tollerare una breve sospensione delle scritture | Discrepanza dei dati scritti sul vecchio database successivamente all'esportazione |
| Replica | Sistemi ad alta disponibilità in cui il downtime deve essere ridotto al minimo | Maggiore complessità architetturale, dipendenze di versione e gestione articolata dei permessi |
Per la maggior parte dei siti WordPress, applicazioni SaaS in fase iniziale, dashboard gestionali e strumenti interni, la tecnica di dump e restore garantisce il giusto equilibrio tra semplicità e affidabilità. L'elemento chiave risiede nella gestione rigorosa dell'intervallo compreso tra l'avvio dell'esportazione e la messa in produzione del nuovo database.
Come eviti downtime e perdita di dati?
La fase critica di una migrazione non è rappresentata dall'esportazione dei file, ma dal momento del passaggio definitivo (cutover).
Se l'applicazione sorgente continua ad accettare operazioni di scrittura durante l'esportazione, i nuovi record generati dagli utenti non verranno inclusi nello snapshot. Questo disallineamento è la causa principale della perdita di dati al termine di migrazioni apparentemente corrette.
Per azzerare questo rischio, è sufficiente seguire una procedura sequenziale:
- Individua una finestra temporale a basso traffico.
- Imposta l'applicazione in modalità manutenzione o attiva la modalità di sola lettura per bloccare le Scritture.
- Esegui l'esportazione del dump dall'istanza PostgreSQL o MySQL originale.
- Effettua l'importazione nel nuovo database sul server di destinazione.
- Aggiorna i parametri di connessione dell'applicazione verso il nuovo host.
- Effettua il collaudo funzionale simulando le operazioni utente.
- Ripristina l'operatività completa abilitando nuovamente le Scritture.
Per un'applicazione di piccole dimensioni, questa operazione richiede pochi minuti di manutenzione. Per piattaforme ad alto traffico, sarà opportuno valutare strategie di replica o procedure di cutover avanzate.
Monitora inoltre le risorse del server prima dell'importazione. La fase di ripristino di un database richiede un uso intensivo di disco, memoria RAM e CPU: un server sottodimensionato potrebbe causare un notevole rallentamento del processo o il fallimento dell'operazione. Per una valutazione accurata dei requisiti hardware, consulta la guida su che dimensione di server ti serve.
Cosa si rompe dopo lo spostamento del database?
La maggior parte degli errori post-migrazione appartiene a categorie note ed è facilmente risolvibile.
L'anomalia più comune riguarda la mancata attualizzazione delle variabili di connessione dell'applicazione. La stringa di configurazione definisce parametri fondamentali quali host, nome del database, utente, password e porta di rete. Un'inesattezza in questi campi genererà errori di connessione caratteristici come connection refused, password authentication failed, Unknown database o ECONNREFUSED.
Un secondo elemento di attenzione è rappresentato dalle difformità di versione. Un dump generato da una release recente di PostgreSQL potrebbe non risultare compatibile con una versione precedente. Allo stesso modo, pur condividendo un'origine comune, MySQL e MariaDB presentano differenze operative in termini di estensioni, collation, modalità SQL e stored procedure.
Infine, occorre valutare le prestazioni complessive. Un degrado delle performance sul nuovo server può dipendere da dischi con iOPS inferiori, RAM insufficiente o indici non ricostruiti correttamene. Se il sistema risponde con lentezza dopo il trasferimento, è opportuno verificare se il nuovo ambiente hardware sia adeguato al carico di lavoro. Per un'analisi approfondita delle metriche di sistema, rimandiamo alla guida perché il mio server è lento.
Mantieni l'istanza di origine integra e accessibile finché il nuovo ambiente non avrà dimostrato piena stabilità sotto il traffico di produzione.
FAQ
Le procedure di migrazione per PostgreSQL e MySQL sono identiche? La metodologia generale è analoga: esportazione, importazione, aggiornamento delle configurazioni dell'app e collaudo. Differiscono tuttavia gli strumenti specifici e la gestione di aspetti peculiari come estensioni, utenti, set di caratteri e compatibilità di versione.
È indispensabile sospendere l'applicazione durante la migrazione? Qualora l'applicazione preveda la scrittura di nuovi dati da parte degli utenti, la sospensione temporanea delle Scritture è fortemente raccomandata per prevenire disallineamenti tra l'esportazione e lo stato corrente.
È possibile migrare un database copiando direttamente i file dal filesystem? È una pratica sconsigliata. I file dati grezzi dipendono strettamente dallo stato del motore, dalla versione e dall'architettura di storage. L'utilizzo degli strumenti ufficiali di dump e restore o di replica rappresenta l'approccio più sicuro.
Come si verifica il corretto esito della migrazione? Occorre verificare la corrispondenza del conteggio delle righe tra le tabelle, simulare autenticazioni utente, eseguire operazioni di scrittura di test, completare i flussi operativi principali e monitorare i log applicativi alla ricerca di eventuali eccezioni del database.
La soluzione semplificata
Server Manager semplifica la gestione della migrazione mantenendo la topologia dell'architettura chiara e documentata. Il risultato finale è un'applicazione reindirizzata al database PostgreSQL o MySQL corretto, con dati integri e una configurazione ordinata e consultabile nel tempo.
Questo approccio elimina gli errori più frequenti: parametri di connessione errati, credenziali non aggiornate, sovrapposizioni involontarie tra database di progetti diversi o configurazioni di rete non documentate.
Il vantaggio principale consiste nel mantenere un'infrastruttura trasparente e manutenibile: l'organizzazione dei database, le credenziali associate e le dipendenze applicative rimangono definite in modo chiaro, garantendo piena governabilità dell'ambiente server.
Una volta completata correttamente la migrazione, la gestione del database smette di rappresentare un elemento di criticità: la collocazione dei dati, le modalità di accesso dell'applicazione e le procedure di controllo rimangono definite e sotto il tuo pieno controllo.