Per creare dump schedulati dei database, tra Backup&Migrate (validissimo) e l'utilizzo diretto di mysqldump (in cron) o drush sql-dump (in cron) o drush sql-sync (in cron)... secondo voi quale è la soluzione migliore, la + efficace in termini di prestazioni, la più veloce, quella che richiede meno ram, ecc ecc ?
e come improntereste uno script in bash/sh/ksh ecc ecc... per una gestione efficace e sicura dei backup o delle sincronizzazioni dei DB?
ma come può essere che questo post non interessi?! ...
Cmq, fare un dump non è un problema.
Ho inziato ad intravedere drush sql-sync, penso che posssa essre una soluzione interessante...ma da quel poco che ho potuto vedere richiede che ci sia un settings.php per lo specifico db di destinazione e questo può essere problematico.
http://www.sanisapori.eu
Forse non è che non interessa, ma dovrebbero leggerlo persone alla tua portata.
Io non coscosco queste cose.
Ciao
Prima di tutto devi pensare a cosa ti serve il dump:
E poi devi sempre considerare almeno due fattori:
Nel caso 1, la soluzione piu' efficiente e' esterna a Drupal ed e' http://dev.mysql.com/doc/refman/5.1/en/mysqlhotcopy.html
Nel caso 2, le opzioni SQL di drush o anche http://drupal.org/project/dbscripts configurando opportunamente le tabelle da tenere e quelle da buttare; se vuoi un dump completo, pero', ti basta http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html che e' piu' diretto.
Nel caso 3, il consiglio e' quello di non usare per nulla il dump o almeno di portare in codice tutto usando http://drupal.org/project/features ; usa sicuramente un dump basato su SQL (quelli del caso 2) in modo da poter confrontare le differenze tra le varie versioni del database.
http://nuvole.org
http://youthagora.org
Lo scopo è quello di avere un dump completo dell'intero DB, quindi il punto 1.
L'utilizzo del Lock non l'avevo considerato in questo caso, ma è una prassi + che corretta ed utilizzata praticamente ovunque.
La questione della pulizia è importante e va fatta in ogni caso.
E se invece, oltre al dump, si volessero tenere 2 database sincronizzati così da switchare da un all'altro rapidissimamente in caso di crash?
.. nel senso che uno viene popolato partendo dall'altro (DB di riferimento). potrebbe essere una soluzione interessante nel caso di DB di medie dimensioni cioè 100-500MB, dove la sincronizzazione può risultate + efficiente e rapida rispetto all'effettuare l'import del dump.
http://www.sanisapori.eu
Allora mysqlhotcopy + rsync sui file oppure drush sql-sync (che usa rsync come backend, con gli stessi benefici in termini di quantità di dati trasferiti).
http://nuvole.org
http://youthagora.org
Un'attimo, spiegati meglio!..
.. l'interesse non è nel fare un rsync per mantenere sincronizzata l'aleberatura drupal e le directory dei singoli siti web.
.. l'interesse è riferito solo a sincronizzare il database.
ma drush sql-sync .. mi pare... che necessiti di un settings.php e quindi di un'a seconda albertura drupal per potersi connettere al nuovo DB e sincronizzarlo con quello in uso. Resti obblicato ad avere dentro sites il doppio delle directory, cioè 2 per ogni sito web online, una utilizzata e l'altra solo per sincronizzare il DB.
Non è che questo sia sbagliato... però magari può essere ottimizzato. Infondo non è un cluster! ...Anche xkè magari stanno tutti sulla stesso server.
http://www.sanisapori.eu
Infatti. Intendevo rsync per sincronizzare l'output di mysqlhotcopy (si tratta di file; non hanno nulla in comune con i file di Drupal, ma sempre file sono), anche in locale. Se non ci sono state variazioni rispetto all'ultimo backup, questo e' il sistema piu' veloce.
Se non vuoi il doppio albero Drupal, usa mysqlhotcopy + rsync sui file prodotti da mysqlhotcopy anziche' usare drush. E poi, se capisco bene, cambierai la stringa di connessione mysql in settings.php in caso di problemi.
Ma ricordati di sospendere il cron job se lo fai, altrimenti e' un disastro! E ti consiglio anche di mettere il codice sotto controllo di versione se ne conservi una sola copia.
http://nuvole.org
http://youthagora.org
Problemino... non ho i permessi di lettura!
Quindi non posso usare mysqlhotcopy. Quindi se hai altre idee fammi sapere.
In ogni caso, da una breve analisi fatta, noto che msqlhotcopy praticamente "copia i file da un luogo ad un'altro" facendo un Flush table e un lock table.
Ma questi file "copiati" poi per essere riutilizzati devono prima essere ritrasferiti dove si trova la dove sono stati presi?!... insomma sto iniziando ad inquadrare questa cosa (non avevo mai usato mysqlhotcopy), ma alcuni dettagli ancora non mi sono chiarissimi.
http://www.sanisapori.eu
Per il tuo caso e quello che volevi fare e' mysqlhotcopy la cosa giusta. Certo, se non hai i permessi sui file non c'e' possibilita'.
Per chiarire i tuoi dubbi:
mysqlhotcopy --user=utente --password=password miodatabasefa precisamente quello che volevi tu: crea un database "miodatabase_copy" e lo riempie con una copia del contenuto di "miodatabase".
mysqlhotcopy --user=utente --password=password miodatabase directoryinvece copia il contenuto di miodatabase su file nella directory specificata (il che e' meglio, perche' cosi', cambiando directory, puoi archiviare non solo l'ultimo dump ma una serie). Per ripristinare il database devi semplicemente copiare i file nella directory del server corrispondente al nuovo database (se hai i permessi giusti vedi la struttura delle directory dove MySQL memorizza i database e ti sara' chiaro cosa intendo); questa copia di file si puo' fare con "cp", ed e' una copia ordinaria, ma anche con "rsync". Quale usare dei due dipende: in remoto userei sicuramente rsync, che puo' essere significativamente piu' veloce perche' e' in grado di riconoscere se i file sono inalterati.
http://nuvole.org
http://youthagora.org
mysqlhotcopy è una figata!...
... purtroppo non posso utilizzarlo al momento o meglio devo chiedere se mi autorizzano l'accesso in lettura ed in scrittura.
Ma se non dovessere autorizzarmi, hai qualche altra idea per "copiare e/o sincronizzare" il contenuto di un db in un'altro?
http://www.sanisapori.eu