Alleggerire Drupal dai Moduli superflui come Backup&Migrate e DB Manteinance è un cosa decisamente buona. E' SEMPRE bene avere drupal strutturato con SOLO i Moduli necessari, senza alcuna aggiunta particolare.
Dopo aver strutturato uno script in crontab per i Backup dei vari database, con tanto di funzionalità di Split, Group, Archive, Clean older, ( http://www.drupalitalia.org/node/12997#comment-45113 ), adesso passiamo all'Ottimizzazione delle Tabelle dei nostri Data Base.
Lo scopo è quello di lanciare una query OPTIMIZE ad ogni tabella del nostro DB.
Non ho molta voglia in questo momento di mettermi a descrivervi ragionamenti e algoritmi, quindi per il momento vi aggiungo lo script e voi lo analizzate. Per accelerare il lavoro mi sono aiutato con informazioni raccolte qua e la sul manuale di MySQL e siti appositi.
#!/bin/bash
DBNAMES="
db1
db2
db3
"
USERS=(
user1
user2
user3
)
PASSWORDS=(
pass1
pass2
pass3
)
DATE=`/bin/date '+%y%m%d_%H%M%S'`
log="~/logs/ejarvis_optimizedb_$DATE.log"
HOST="ip_host"
i=0
for DB in $DBNAMES
do
# Test connecting to the database:
mysql --host=$HOST --user=${USERS[${i}]} --password=${PASSWORDS[${i}]} $DB --skip-column-names --batch -e "show status" 2>"$log" >/dev/null
if [[ $? -gt 0 ]]; then
echo "An error occured, check $log for more information.";
exit 1;
fi
# get a list of all of the tables and sort out the fragmented tables
fragmented=( $(mysql --host=$HOST --user=${USERS[${i}]} --password=${PASSWORDS[${i}]} $DB --skip-column-names --batch -e "SHOW TABLE STATUS FROM $DB;" 2>"$log" | awk '{print $1,$2,$10}' | egrep "MyISAM|InnoDB" | awk '$3 > 0' | awk '{print $1}') );
if [[ $? -gt 0 ]]; then
echo "An error occured, check $log for more information."
exit 1;
fi
echo "Checking $DB ... ";
if [[ ${#fragmented[@]} -gt 0 ]]; then
if [[ ${#fragmented[@]} -gt 0 ]]; then
if [[ ${#fragmented[@]} -gt 1 ]]; then
echo "found ${#fragmented[@]} fragmented tables.";
else
echo "found ${#fragmented[@]} fragmented table.";
fi
fi
for table in ${fragmented[@]}; do
let fraggedTables=$fraggedTables+1;
echo -n "Optimizing $table ... ";
mysql --host=$HOST --user=${USERS[${i}]} --password=${PASSWORDS[${i}]} $DB --skip-column-names --batch -e "optimize table $table" 2>"$log" >/dev/null
if [[ $? -gt 0 ]]; then
echo "An error occured, check $log for more information."
exit 1;
fi
echo done
done
fi
unset fragmented
let i=i+1
done
# footer message
if [[ ! $fraggedTables -gt 0 ]]; then
echo "No tables were fragmented, so no optimizing was done.";
else
if [[ $fraggedTables -gt 1 ]]; then
echo "$fraggedTables tables were fragmented, and were optimized.";
else
echo "$fraggedTables table was fragmented, and was optimized.";
fi
fi
if [[ ! -s $log ]]; then
rm -f "$log"
fi
unset fraggedTablesLo scopo di questo script è quello di analizzare un data base al fine di rintracciare le tabelle frammentate e poi deframmentarle una per una tramite l'apposita opzione di mysql e ripetere la cosa per ogni db indicato.
Lo script funziona benissimo, e crea anche un log in che viene mantenuto in caso di errori.
Lo sto già utilizzando per tutti i siti web, ma forse potrebbe necessitare di qualche snellimento.
Non so ancora bene quante volte al giorno farlo girare. In genere una sola volta basta.
Qui è stato schedulato in crontab all'ora 1AM del server. e viene eseguito una sola volta al giorno.
Più grosso è il DB più grandi e frammentate saranno le tabelle node_reviosions e search_index, quindi ottimizzare le tabelle diventa una cosa importante per mantenere sempre fervide le prestazioni.
0 1 * * * ~/scripts/drupal-optimizedb.sh 2>&1 > ~/logs/drupal-optimizedb.logSi accettano suggerimenti e miglioramenti allo script. Nel frattempo disinstallo il modulo DB Mantainance da tutti i siti web, così come già fatto con il modulo Backup&Migrate.
Veramente era proprio quella la soluzione...
... già applicata da diverso tempo ...e decisamente efficace!
Tra l'altro, non è che ci voglia granchè tempo, io l'ho fatta in poco tempo... la query è standard di mysql.
Semmai si può snellire e migliorare ulteriormente.
http://www.sanisapori.eu
mmmm, ma se per seguire questa filosofia rifai cose già fatte nei moduli che vuoi sostituire e con codice che poi devi andare a mantenere… mmmmmmm
Non capisco che cosa ti facciano di male DB Maintainance e B&M…
la questione é + complicata. nel caso di buckup & migrate c'era da tempo la necessità di gestire i db di grosse dimensioni, finché ad un certo punto quando i db hanno superta un certa dimensione, backup & migrate ha iniziato a fallire: troncava i backup e falliva la compressione con gzip. Che avrei dovuto fare, tenermi i db compattati male con dimensione 0KB ? Sono stato obbligato ad intervenire e dopo aver appurato che tramite mysqldump errori non ce n'erano ho preparato uno script che gestiva i db di grosse dimensioni, che esportasse lo schema e un dump separaro x ogni tabella. In questo credo di poter gestire anche db da 1gb e oltre. purtoppo gli import richiedono diverso tempo ma effettuando automaticamente l'import tabella x tabella, in caso di problemi sai da dove ripartire senza dover iniziare da capo. Invece, nel caso di db manteinance, era da tempo che non avevo alcuna voglia di avere un modulo solo x fare una banale query di sistema di mysql x ottimizzare ogni tabella.basta un unico rigo di mysql
http://www.sanisapori.eu
scusa gli errori ma sto scrivendo tramite smartphone. Purtroppo x backup&migrate si é trattato di una stretta necessità che richiedeva un rapido intervento e la soluzione applicata funziona decisamente bene. e lo script é reso pubblico proprio in questo forum. Al massimo può nexessitare di un miglior sistema di logging e di qualche check x qumentarne oa robustezza. nell'altro caso, visto che c'ero, mi aono preparato qualcosa x togliere di mezzo un modulo superfluo?
http://www.sanisapori.eu
Ma il tuo script, se non capisco male, va personalizzato per ogni sito che aggiungi al tuo server (o caricato separatamente e configurato per ogni server): non mi sembra una manutenzione banale, considerato che DBM si attiva con un clic.
Quanto a B&M, non ho mai incontrato i problemi di dimensioni (non voglio dire che non esistano, solo che non ci ho mai fatto attenzione): sei sicuro che non si possa migliorare e rendere più affidabile?
Nessuno degli script indicati, anche se li lasci allo stato attuale, necessitano di manutenzione.
Vanno schedulati in crontab e fanno tutto da soli, compresi i log e li puoi utilizzare anche per DB non associati a drupal (civicrm, o altri siti).
Nessuno degli script va customizzato per ogni sito e se hai gli accessi di root su MySQL, puoi anche fare in modo che si ravanino tutti i DB senza dover aggiungere user e password dei singoli DB.
Gli script fanno tutto da soli e non necessitano di manutenzione, ne di interventi manuali x rimuovere gli script vecchi.
I miglioramenti che si possono ancora fare sono di 4 tipi:
Posso garantire che x il resto, per tutto il resto, funzionano perfettamente.
D'altra parte xkè dare onere a Drupal di fare i Backup, quando invece dovrebbe essere il sistema su cui drupal si appoggia ad occuparsi di tutto questo?!
Questo vale a maggior ragione sia per i DB che per il Cron dei siti fatti con Drupal.
Quando i siti web sono grossi gestire la manutenzione degli stessi all'esterno dei siti (cioè non a carico dei siti web) è doveroso.
http://www.sanisapori.eu
Non va personalizzato per ogni sito xkè sono strutturati per Backappare TUTTI i DB e per ottimizzare tutte le tabelle frammentate di tutti i DB. In teoria nello script x ottimizzare le tabelle si potrebbe anche aggiungere un opzione per riparare le tabelle quando questo diventa necessario.
Configurare per ogni server: questo dipende dall'IP del server in cui ci sono uno o TUTTI i DB.
Se i DB sono tutto sullo stesso server, qualunque esso sia e ovunque si trovi, basta aggiungere una sola volta l'IP del server o il localhost nell'apposita variabile.
Se i DB si trovano su server diversi, allora nello script definisci un'array di IP da passare come opzione di mysql così come sono già gestiti user/passaword/nodedb. Nel mio caso non è necessario.
[ pensadoci un'attimo adesso mi fai venire in mente che potrei fare un'altro script quasi uguale a quello x i backup x sincronizzare 2 DB, così da avere i DB pronti in casi di qualsiasi problema dannoso ]
Beh!.. mi sono accorto che la compressione lanciata dal modulo non andava mai a buonfine, non so xkè. Da li sono risalito, tentando un'esportazione manuale del DB tramite backup&migrate e mi sono accorto che non esportava tutto il DB, arrivava fino ad un certo punto e tutte le altre tabelle non le esportava. Ho provato a compattare a mano il DB troncato, e gzip -9 funzionava benissimo. Ho provare ad esportare con mysqldump ed il DB esportato era completo e senza errori. Non so ancora quale sia il problema.
http://www.sanisapori.eu