English
Italianomysql maintenance plan
Ci sono molte cose che possono andare storte. Ci sono però alcune cose che si possono fare per cercare di ridurre la portata del disastro quando le cose vanno storte per davvero. Negli ultimi tempi mi sono dedicato a lavorare su un maintenance plan per MySQL che fosse adatto alle mie esigenze senza per questo diventare troppo complesso da gestire. Quanto segue è il risultato dei miei esperimenti. Uso attualmente MySQL versione 4.1 su server Debian GNU/Linux; la maggior parte dei database sono basati su engine InnoDB.
Integrità dei database
La prima cosa da verificare prima di effettuare i dump veri e propri dei dati è che i singoli database siano integri. Utilizzo il comando:
$ mysqlcheck -u root --password=<password> \
--all-databases --analyze --check --optimize --auto-repair
che agisce su tutti i database del sistema, effettuando l'analisi delle tabelle, la verifica della presenza di errori e l'ottimizzazione. Nel caso vengano rilevate delle tabelle corrotte, le inconsistenze verranno sistemate in automatico.
Dump completo del sistema
La configurazione di default di Debian attiva l'uso dei log binari di MySQL; un apposito cron job si occupa della loro rotazione e di ripulire quelli troppo vecchi.
Non avendo particolari motivi per disabilitarli, non ho modificato l'impostazione di default, ma mi sono premurato di disabilitare la gestione automatica della loro rotazione, preferendo gestirla a mano una volta fatto il dump completo del sistema.
Per disabilitare la rotazione dei log binari va modificato il file
/etc/mysql/debian-log-rotate.conf impostando:
KEEP_BINARY_LOGS=0
A questo punto, per effettuare un dump completo del sistema, si possono usare i comandi:
$ echo "SET FOREIGN_KEY_CHECKS=0;" > mysql-dump
$ mysqldump -u root --password=<password> \
--single-transaction --all-databases \
--flush-logs --master-data=2 --delete-master-logs >> mysql-dump
$ echo "SET FOREIGN_KEY_CHECKS=1;" >> mysql-dump
Il primo e l'ultimo comando si occupano di disabilitare, e riabilitare, i
controlli sulle chiavi esterne delle tabelle - cosa indispensabile in caso
di recovery. mysqldump invece provvede a fare il dump vero e proprio,
includendo tutti i database e generando un nuovo log binario (eliminando
i log binari vecchi, ormai inutili).
Dump di ciascun database
Accanto al dump completo di tutti il sistema, trovo utile avere anche un dump separato per ciascun database:
$ echo "SET FOREIGN_KEY_CHECKS=0;" > [database]-dump
$ echo "USE [database];" >> [database]-dump
$ mysqldump -u root --password=<password> --opt [database] >> [database]-dump
$ echo "SET FOREIGN_KEY_CHECKS=1;" >> [database]-dump
Sostituite a [database] il nome del database di cui volete fare il dump.
Recovery
Nella sciagurata ipotesi in cui serva un recovery, potete procedere come segue.
Ripristinate il sistema usando il dump completo:
$ mysql -u root --password <password> < mysql-dump
A questo punto potete usare i log binari per recuperare tutte le modifiche fatte sul sistema successivamente al dump:
$ mysqlbinlog logfile1 logfile2 ... | mysql -u root --password=<password>
oppure:
$ mysqlbinlog logfile1 logfile2 ... > mysql-log
$ mysql -u root --password=<password> < mysql-log
La seconda opzione è utile se si vuole esaminare il log prima di effettuare il ripristino.
E' anche possibile fare un ripristino parziale del contenuto del log
usando le opzioni --start-datetime/--stop-datetime e
--start-position/--stop-position di mysqlbinlog
Per effettuare il ripristino di un singolo database, invece, potete usare il comando:
$ mysql -u root --password=<password> < [database]-dump
Ringraziamenti
Un grosso ringraziamento a Maurizio Lemmo - Tannoiser per le utili quanto esaurienti spiegazioni.
