Realizzare una copia dei database memorizzati da MySQL non è esattamente un'operazione immediata. Come ogni strumento studiato per essere impiegato anche in scenari in cui il carico di lavoro sia sostenuto, il prodotto open source di Oracle fa largo uso di meccanismi di caching e separazione dei file sul disco allo scopo di aumentare le performance e rendere disponibili un ampio ventaglio di funzionalità avanzate.
Questo significa che, per creare un backup o fotocopiare uno o più database su un altro sistema, è necessario operare con un po' d'accortezza.
Le tecniche che vedremo sono due: la prima prevede la copia diretta dei file che costituiscono i database. La seconda utilizza l'utilità mysqldump, fornita in dotazione a MySQL.
Entrambe sono state testate su Windows e Linux.
Le due metodologie proposte portano, fondamentalmente, ad un risultato analogo: la generazione di una copia dei database disponibili sul server, pronta per essere ripristinata in caso di problemi o da importare su un sistema secondario da utilizzare a scopo di test.
L'una ha però punti di forza che mancano all'altra, e viceversa: ho schematizzato il tutto in questa semplice tabella
- | Copia dei file | mysqldump |
Velocità | Molto elevata | Medio-bassa |
Affidabilità | Elevata | Buona |
Disagi durante l'operazione | Database irraggiungibile | Database in sola-lettura |
Flessibilità | Media | Ottima |
Spostamento database fra piattaforme differenti | Sì (con cautela) | Sì |
Spostamento database fra software differenti | No | Sì (con cautela) |
Livello di difficoltà | Facile | Medio |
Vediamo ora le due tecniche nei dettagli.
Il primo approccio, particolarmente consigliabile quando i dati da copiare superano la decina di gigabyte, prevede di agire su singoli file che compongono i database in maniera non dissimile da quanto avvenga con la copia dei documenti tradizionali.
Procedendo in questo modo, potrete spostare su Windows i file generati su un server Linux (e viceversa) solo a patto che abbiate utilizzato solamente lettere minuscole per i nomi dei database e delle tabelle.
Per poter procedere in tutta sicurezza con la copia dei file, è necessario arrestare il processo di MySQL.
Ancor prima quindi, si dovrà agire per porre off-line l'applicazione che si interfaccia con il database. Se MySQL funge da backend ad un sito web, il risultato si può ottenere facilmente arrestando il server HTTP. In caso contrario, lo scenario è più complesso e sarà necessario ragionare caso per caso.
Completata la fase di preparazione, arrestate MySQL. Se siete sotto Windows e il database è installato come servizio di sistema (impostazione predefinita), aprite un prompt di comando amministrativo e quindi lanciate net stop mysql. Sotto Linux usate invece service mysqld stop.
È ora indispensabile individuare il percorso su disco in cui sono conservati i file dei dati di MySQL.
Per farlo, aprite il relativo file di configurazione del database.
Se state operando sotto Windows, tale file si trova nella cartella d'installazione del programma stesso: per impostazione predefinita, C:\Programmi\MySQL\MySQL Server <versione>\my.ini.
Se invece il vostro sistema utilizza Linux... individuare il corrispondente my.cnf è meno immediato, poiché il percorso varia da distribuzione a distribuzione. /usr/local/mysql/ potrebbe essere un buon candidato. In caso ancora non lo troviate, aiutatevi con find / -name "my.cnf".
Una volta aperto il file, individuate la riga datadir: seguite il percorso dopo l'uguale e troverete i vostri file.
Non è finita: assicuratevi anche di cercare l'opzione innodb_data_home_dir nel file di configurazione e, se presente, prendete nota del percorso ad essa associato (generalmente i due coincidono, ma è meglio sincerarsene)
Aprite la cartella datadir e troverete una struttura simile a quella indicata nella schermata successiva.
In linea di massima, ogni cartella contiene uno dei database memorizzati da MySQL, ma, in talune circostanze, porzioni significative di dati vengono memorizzate anche nel file ibdata (se non lo vedete qui, controllate nella cartella indicata da innodb_data_home_dir) e nei vari ib_logfile<progressivo>
Notate che, in alcune configurazioni, il file ibdata può non essere presente (in tal caso, ignoratelo) oppure essere chiamato ibdata0 e/o ibdata1 e/o ibdata2 eccetera. In questa seconda circostanza, dovrete chiaramente considerarli tutti.
Assicuratevi ora di fare una copia di tutto quanto: cartelle contenenti i database che vi interessano, file ibdata e/o ibdata<progresivo> e vari ib_logfile<progressivo>.
A copia completata, potete riavviare il processo di MySQL: net start mysql sotto Windows, service mysqld start sotto Linux.
Ripristinare i dati partendo da un backup creato in questo modo è piuttosto semplice.
Per prima cosa, assicuratevi che il servizio del database sia fermo (nuovamente: net stop mysql sotto Windows e service mysqld stop in ambiente Linux).
Accedete quindi nuovamente al file di configurazione di MySQL per scoprire i percorsi datadir e innodb_data_home_dir.
Per evitare di fare confusione, cancellate tutti i file e le cartelle preesistenti in questi due percorsi. Tutto quello che è attualmente memorizzato nel server andrà perso definitivamente ma, d'altro canto, "affiancare" vecchi dati ai nuovi con questa tecnica è una procedura vivamente sconsigliabile.
Copiate ora le cartelle e i file ib_logfile<progressivo> del vostro backup nel percorso datadir, mentre in innodb_data_home_dir piazzate ibdata (oppure i vari ibdata<progressivo>).
A questo punto, avviate il servizio di MySQL (net start mysql per Windows e service mysqld start su Linux). Se tutto è andato per il verso giusto, il programma dovrebbe ripartire senza problemi. In caso contrario, aprite il file .err che verrà creato all'interno della cartella datadir per risalire all'errore.
Notate che, anche in caso aveste ripristinato soltanto alcuni database dalla vostra copia, il file ibdata manterrà comunque il proprio peso originale. Al momento, non pare esservi alcuna soluzione diretta al problema.
Il secondo metodo di generare copie dei dati gestiti da MySQL prevede l'uso di mysqldump, un pratico programma da linea di comando fornito a corredo del database open source.
Lo strumento non fa altro che riversare in un file in testo semplice (apribile quindi anche con il blocco note) tutte le query necessarie a ricreare i database indicati ed i relativi dati
La compatibilità è elevatissima: non solo potrete importare su un server Windows un "dump" creato su Linux (e viceversa) senza alcun problema, ma anche utilizzare tale strumento per iniziare la migrazione dei vostri dati ad un altro motore di database, come Microsoft SQL Server, PostgreSQL eccetera.
Uno degli svantaggi maggiori è costituito dalla relativa lentezza: creare un dump in questo modo (e, ancor più, ricaricare i dati in seguito) richiede nettamente più tempo di quanto non sia necessario con la semplice copia dei file trattata alla pagina precedente.
Così come proposto di seguito, mysqldump inibisce completamente le scritture fino al termine delle operazioni. Sebbene questo comportamento non sia strettamente indispensabile, è sicuramente consigliato per ottenere una copia super-affidabile dei dati.
Durante la creazione del dump, tutti i tentativi di modificare i dati verranno posti in attesa fino alla fine dell'operazione: questo potrebbe comportare qualche timeout o altri tipi di disagi per gli utenti della base di dati.
Se la vostra applicazione è predisposta per consentire l'uso del servizio in sola-lettura, potete facilmente attenuare l'inconveniente agendo su questa caratteristica.
In caso contrario, il consiglio è quello di prevenire completamente i problemi inibendo del tutto l'accesso al database. Se MySQL funge unicamente da backend ad un sito web, il risultato si può ottenere facilmente arrestando il server HTTP. In caso contrario, lo scenario è più complesso e sarà necessario ragionare caso per caso.
Il comando da usare (all'interno di un un prompt di comando amministrativo) per "dumpare" i tre database di nome miodatabase è mysqldump -uNomeUtenteAmministratore -pMiaPassword --opt --add-drop-database --lock-all-tables --databases miodatabase1 miodatabas2 miodatabase3 > C:\mio_dump.sql (sotto Linux è necessario solamente sostituire C:\ con un percorso adeguato al file system, come /usr/).
Per lo scopo di questa guida basti dire che:
Maggiori informazioni sulle opzioni a disposizione sono preposte dal capitolo 4.5.4 della guida ufficiale.
Al termine del dump, potrete ripristinare il regolare funzionamento del servizio: tutti i blocchi imposti al database saranno infatti rilasciati automaticamente ad operazione conclusa.
Ripristinare i dati partendo da un file di dump creato in questo modo è piuttosto semplice.
Per prima cosa, assicuratevi che il database non sia accessibile dall'applicazione (vedi la trattazione "Pronti, partenza... sola lettura! " proposta poco fa).
Aprite un nuovo prompt di comando ed impartite mysql -uNomeUtenteAmministratore -pRelativaPassword < C:\miodump.sql, indicando, naturalmente, il file di dump generato in precedenza.
Gli utenti Linux, ovviamente, devono usare un percorso adeguato al proprio file system.
L'operazione di ripristino è, generalmente, sensibilmente più lunga di quella di creazione del dump. Ad esecuzione terminata potrete comunque abilitare il servizio con la consapevolezza che tutto quanto è ritornato allo stato precedente.
Una procedura che può risultare spesso comoda è quella di generare un dump non tanto dell'intero contenuto del database, ma solamente della struttura delle tabelle e delle varie opzioni ad esso associate.
Il risultato si può ottenere molto facilmente invocando mysqldump in questo modo: mysqldump -uNomeUtenteAmministratore -pMiaPassword --no-data --opt --add-drop-database --lock-all-tables --databases miodatabase1 miodatabas2 miodatabase3 > C:\mio_dump.sql.
L'unica differenza rispetto a quanto visto in precedenza è costituita dal comando --no-data.
L'operazione, in questo caso, sarà molto più rapida: si parla, a meno di infrastrutture particolarmente complesse, di pochissimi secondi.
Mysqldump permette anche di generare dump di specifiche tabelle, invece che di interi database.
Il comando, in questo caso, diviene: mysqldump -uNomeUtenteAmministratore -pMiaPassword --opt --lock-all-tables miodatabase1 miatabella1 miatabella2 miatabella3 > C:\mio_dump.sql.
Notate che è qui sparito il parametro --databases, assieme a --add-drop-database.
Per reimportare un dump di questo tipo, dovrete avere l'accortezza di indicare in seguito il database nel quale inserire la tabella: il comando di importazione diventerà quindi mysql -uNomeUtenteAmministratore -pRelativaPassword miodatabase < C:\miodump.sql.
Anche in questo caso, potete aggiungere al comando di dumping il già citato parametro --no-data per esportare solamente la struttura delle singole tabelle richieste, senza i relativi dati contenuti.
Quello che propongo a conclusione di questo articolo è un semplice script che, combinando la tecnica di dump e importazione appena descritta ad alcuni programmi aggiuntivi, mi consente di scaricare una copia di backup dal server di MegaLab.it e caricarla sul mio PC di sviluppo locale in modo del tutto automatico.
Questo script, nel mio specifico caso, è pianificato per l'esecuzione temporizzata la mattina presto, ed è affiancato ad rsync per la gestione dei file esterni al database.
Lo strumento è sicuramente perfettibile, ma credo possa costituire una buona base di partenza per tutti coloro che debbano sbrigare attività di manutenzione analoghe.
Potete scaricare l'archivio contenente il file seguendo il link al download correlato presente alla sommità della colonna di destra di questo articolo.
Per poter funzionare correttamente, lo script ha alcuni pre-requisiti:
Prima di lanciarlo inoltre, è indispensabile aprire il file ed immettere vari parametri richiesti: le coordinate d'accesso al server remoto, i percorsi da utilizzare e via dicendo.
Il listato propone già alcuni valori d'esempio che, in abbinamento ad i nomi autoesplicativi delle variabili, dovrebbero rendere la personalizzazione piuttosto semplice.
Il programmino è un file batch (.bat) ed è quindi studiato per funzionare su un PC Windows. Configurando a dovere i percorsi remoti però, dovrebbe essere in grado di funzionare sia con server remoti governati da Linux, sia con quelli Windows.
I dati forniti ad esempio fingono l'interazione con una macchina remota Linux.
MegaLab.it rispetta la tua privacy. Per esercitare i tuoi diritti scrivi a: privacy@megalab.it .
Copyright 2008 MegaLab.it - Tutti i diritti sono riservati