Archivi tag: database

Script bash per automatizzare le query su MySQL

Scenario

Supponiamo che il vostro DBMS (MySQL) stia gestendo più database e che sia necessario effettuare delle query  “a tappeto”, ovvero su tutte le tabelle relative a ciascuno di essi (cercando, ad esempio, un determinato record oppure un pattern specifico).

bashEseguire tale operazione “a mano” può essere tedioso e soprattutto controproducente in termini di tempo. Come fare quindi? Semplice, realizzare uno scrip bash in grado di automatizzare tale attività.

Ecco il codice:

#!/bin/bash

mysql -u utente -ppassword -e 'show databases' | grep -v Database | grep -v information_schema | grep -v mysql > databases

while read line
do

        command="mysql -u utente -ppassword -e 'use $line; show tables'"
        eval $command | grep -v "Tables_in_*" > tables_$line

done < databases

num_databases=`cat databases | wc -l`

ls | grep "tables_*" > table

num_tables=`cat table | wc -l`

if [ $num_databases -eq $num_tables ];then

        for i in {1..19}
        do
                database=`cat databases | sed -n "$i p"`
                echo ".......tables for $database......."
                cat tables_"$database" | while read line
                do
                        echo $line
                        command="mysql -u utente -ppassword -e 'use $database; select * from $line LIMIT 1'"
                        echo "....Executing $command...." >> result
                        eval "$command" | tee -a result
                        echo "....End executing $command ...." >> result

                done
                echo ".......end tables for $database......."
        done

fi

Per prima cosa identifico tutti i database definiti su MySQL, escludendo quelli di default (mysql ed information_schema), formattando opportunamente l’output ( grep -v Database) e salvando i risultati all’interno del file databases:

mysql -u utente -ppassword -e 'show databases' | grep -v Database | grep -v information_schema | grep -v mysql > databases

Successivamente listo le tabelle presenti in ciascun database mediante un ciclo while che legge, riga per riga, il contenuto del file databases e, per ognuna, esegue il comando show tables:

while read line
do

        command="mysql -u utente -ppassword -e 'use $line; show tables'"
        eval $command | grep -v "Tables_in_*" > tables_$line

done < databases

Da notare come la stringa $command venga dapprima definita in modo tale da contenere il valore della variabile $line e successivamente venga eseguita sottoforma di comando mediante la direttiva eval.

Verifico, quindi, che il numero dei file tables_$line sia uguale al numero di database (e che quindi vi sia la ragionevole certezza che per ciascun database sia stato individuato il nome delle tabelle di cui è composto):

num_databases=`cat databases | wc -l` ls | grep "tables_*" > table 

num_tables=`cat table | wc -l` 

if [ $num_databases -eq $num_tables ];then

Infine, per ciascuna tabella di ciascun database, lancio la query mysql -u utente -ppassword -e ‘use $database; select * from $line LIMIT 1’, definita come stringa ed eseguita mediante eval (come visto in precedenza):

for i in {1..19}
        do
                database=`cat databases | sed -n "$i p"`
                echo ".......tables for $database......."
                cat tables_"$database" | while read line
                do
                        echo $line
                        command="mysql -u utente -ppassword -e 'use $database; select * from $line LIMIT 1'"
                        echo "....Executing $command...." >> result
                        eval "$command" | tee -a result
                        echo "....End executing $command ...." >> result

                done
                echo ".......end tables for $database......."
        done

fi

Da notare come, nel mio caso, vi sia un totale di 19 database, per cui ho utilizzato un semplice ciclo for così definito:

for i in {1..19}

Nulla però vieta di usare come upper bound la variabile $num_databases o $num_tables.

Infine rendiamo eseguibile lo scrip (che ho denominato, per semplicità, my.sh):

[root@server ~]# chmod +x my.sh

ed eseguiamolo:

[root@server ~]# ./my.sh

E’ tutto, alla prossima.

Shrinking di un database Firebird

L’ABC dell’informatica ci ha insegnato che non esiste un solo tipo di file system. Infatti, oltre al file system utilizzato dal sistema operativo esiste anche il file system del DBMS, il network file system (ad esempio NFS e Microsoft DFS) e così via.

Bene, solitamente quando si cancellano N record da una o più tabelle del DB, il DBMS a cui l’istanza afferisce non rilascerà automaticamente al sistema operativo lo spazio appena liberato. Questo significa che il file che identifica il DB manterrà le propre dimensioni originarie, nonostante le operazioni di rimozione dei record.

Per quanto riguarda Firebird, l’unico modo per effettuare lo shrinking del database (ovvero la sua contrazione in termini di spazio occupato su disco) è eseguire il backup di quest’ultimo e successivamente ripristinarlo.

database, dbms, shrinking, disk space, restore, backup, gfix, gbak, garbage collection, firebird

Fortunatamente, Firebird ci mette a disposizione un valido strumento per tale scopo: gbak.

Per default tale applicativo effettuerà anche la garbage collection dei record duplicati (generati dai rollback delle transazioni), impiegando un certo lasso di tempo (in quanto trattasi di un’operazione abbastanza onerosa in termini computazionali). Per fare in modo che gbak non proceda con la garbage collection occorre usare la flag -G. Ad esempio:

server ~ # gbak -B nomedatabase.fdb nomedatabase.fbk
-v -y backup.log

eseguirà il backup del nostro DB, salvando le informazioni relative a tale operazione (-v -y) nel file backup.log, mentre:

server ~ # gbak -B -G nomedatabase.fdb nomedatabase.fbk
-v -y backup.log

eviterà di eseguire la garbage collection (che, solitamente, viene messa in atto automaticamente ad intervalli di tempo regolari, secondo quanto definito nel file di configurazione di Firebird).

Inoltre, è possibile effettuare la garbage collection in un secondo momento, utilizzando gfix:

server ~ # gfix -s nomedatabase.fdb

Una volta creato il file di backup (con estensione *.fbk), sarà necessario ripristinarlo. Il comando da utilizzare è il seguente:

server ~ # gbak -C nomedatabase.fbk nomedatabase.fdb
-v -y restore.log

Assegnamo i giusti permessi al file appena creato:

server ~ # chown firebird:firebird nomedatabase.fdb

riavviamo Firebird:

server ~ # /etc/init.d/firebird restart

ed abbiamo finito.

Alla prossima.

Script bash per il backup automatico di un database

Dovendo gestire diversi database su più server ho avuto la necessità di creare uno scripino che automatizzasse la creazione dei loro backup. Riporto quindi lo scrip per intero e successivamente provvederò a spiegare le varie sezioni del codice, anche se a primo acchito tutto dovrebbe apparire piuttosto chiaro.

#!/bin/bash

data=$(date +"%d_%b_%y")

montaggio=$(mount | grep /media/disk)

#File di log
FILELOG=/var/log/backup

ROOT_UID=0

if [ "$UID" -ne "$ROOT_UID" ];then

ERRORE1="Errore 1: Devi essere root per eseguire lo scrip"
echo $ERRORE1
echo "$(date) $ERRORE1" >> $FILELOG

exit 1

fi

if [ ! -n "$montaggio"  ]; then

mount /media/disk

fi

if [ ! -d /media/disk/backup/ ]; then

cd /media/disk

mkdir /media/disk/backup

fi

cd /media/disk/backup

mysqldump nomedatabase -u username -pvostrapassword > database_$data.pl

exit 0

Per prima cosa salvo all’interno della variabile “data” l’output del comando date formattato nel seguente modo:

giorno_prime 3 lettere del mese (in inglese)_anno

successivamente definisco all’interno della variabile FILELOG il pathname relativo al file su cui verranno loggati i vari messaggi di errore dello scrip, in questo caso /var/log/backup. Dopodichè mi accerto che lo scrip venga eseguito da root, poichè lo stesso verrà dato in pasto a cron per essere eseguito con tali privilegi.

A questo punto verifico che l’hard disk secondario sia montato, eseguendo il comando:

mount | grep /media/disk

Se tale comando restituisce una stringa vuota eseguo il mount dell’hard disk secondario e successivamente mi posiziono in /media/disk.

Ora devo verificare che la cartalla backup sia presente in /media/disk. Se non lo è provvedo a crearla (in realtà tale operazione verrà effettuata soltanto durante la prima esecuzione dello scrip).

Bene, posso quindi posizionarmi in /media/disk/backup e successivamente effettuare il dump del database mediante il comando mysqldump. Notate che tra la flag -p e la password per accedere al database non vi sono spazi. Inoltre, il dump verrà salvato in un file il cui nome è costituito dalla stringa database_dataattuale.pl, ad esempio:

database_01_Jul_01.pl

Abbiamo quasi finito, non ci resta che creare un binario criptato (RC4) partendo dal nostro scrip, poichè quest’ultimo contiene diverse informazioni critiche, quali, ad esempio, username e password di accesso al database.

Per fare ciò possiamo utilizzare una semplice applicazione, ovvero shc (il sito ufficiale è il seguente: http://www.datsi.fi.upm.es/~frosal/)

Scarichiamo tale applicazione tramite wget:

wget http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.7.tgz

Scompattiamo la tarball:

tar -xvf shc-3.8.7.tgz

e posizioniamoci nella cartella tar -xvf shc-3.8.7:

cd shc-3.8.7/

Lanciamo il make:

make

Dopodichè facciamo un test per verificare che tale operazione sia andata a buon fine:

make test

Se non ci sono errori dovremmo vedere lo scrip shc presente nella dir shc-3.8.7

Ora trasformiamo il nostro scrip per il backup in eseguibile mediante il comando:

./shc -f /home/nomeutente/database

dove database è il nome del nostro scrip.

Se non ci sono problemi di sorta dovremmo ritrovarci i seguenti 2 file nella nostra home:

database.x e database.x.c

Copiamo ora database.x nella dir /usr/bin/

sudo cp database.x /usr/bin

Infine, mediante cron, scheduliamo l’esecuzione di database.x alle 20 e 30 di ogni sera:

sudo nano /etc/crontab

30 20   * * *   root    backupdb.x > /dev/null 2>&1

redirigendo lo standard output e lo standard error su /dev/null.

Il nostro scrip per il backup giornaliero dei database è finalmente pronto.

See ya.

PS: ovviamente se abbiamo a che fare con database di grandi dimensioni eseguire un backup giornaliero è sconsigliato, sarebbe meglio eseguire backup settimanali o mensili.

PPS: inutile dire che tale scrip supporta solo MySQL.

Pillole MySQL – Parte 1

Esistono diversi strumenti che facilitano la vita ai programmatori/DBA. Uno su tutti è certamente PHPMyAdmin, che con la sua interfaccia user-friendly consente di effettuare modifiche sul database in maniera semplice ed intuitiva.

Spesso, però, accade che sia disponibile solo l’interfaccia a linea di comando del nostro DBMS, ragion per cui è bene ricordare alcuni comandi utili:

USE nomedb;

ci consente di selezionare il database.

SHOW TABLES;

ci consente di visualizzare tutte le tabelle relative al database selezionato;

DESCRIBE nometabella;

ci permette di visualizzare la struttura della tabella specificata;

Un altro comando utile riguarda il reset dei campi di auto-increment. Per fare ciò basta digitare:

ALTER TABLE nometabella AUTO_INCREMENT = 1;

Ovviemente, per visualizzare il contenuto di una tabella, per cancellare determinate righe o per modificare la struttura della tabella stessa (o di una sua entry), basta usare la pura e semplice sintassi SQL.

Ad esempio:

SELECT * FROM nometabella;

visualizza tutte le righe di una tabella;

DELETE FROM nometabella;

cancella tutti i record contenuti in una tabella;

DELETE FROM nometabella WHERE ID = '1';

cancella dalla tabella il record avente ID pari a 1;

DROP TABLE nometabella;

cancella la tabella;

INSERT INTO nometabella (campo1, campo2) VALUES ('valore1', 'valore2');

inserisce nella tabella i valori “valore1” e “valore2” rispettivamente per “campo1” e “campo2”;

UPDATE nometabella SET campo1 = 'valore1', campo2 = 'valore2' WHERE ID = '1';

aggiorna il contenuto di “campo1” e “campo2” rispettivamente a “valore1” e “valore2” per la entry che possiede ID pari a 1.

Inutile dire che quelli da me elencati sono solo alcuni dei comandi che MySQL ci mette a disposizione. Morale della favola: meglio non abusare di PHPMyAdmin 😀

A presto.

Effetture il dump di un database sotto Linux con MySQL

Il dump di un database non è altro che un file di testo in cui sono contenute delle istruzioni SQL. Tali istruzioni hanno come scopo quello di riprodurre fedelmente il database esportato, in modo che possa essere caricato su un altra macchina continuando a funzionare correttamente.

logo-mysql.jpg

 

Per effettuare il dump del database MySQL direttamente da linea di comando occorre digitare (da shell):

mysqldump nome_del_database -u root -p > nome_del_file_dump.pl

dove la flag -u indica l’utente (ovvero root), la flag -p richiede l’inserimento della password di root ed il simbolo > indica che il risultato del comando dovrà essere salvato all’interno del file di destinazione (nome_del_file.pl).

Successivamente, per importare sulla macchina di destinazione il file appena creato è necessario usare i seguenti comandi (sempre da shell):

mysqladmin drop nome_del_database -u root -p

mysqladmin create nome_del_database -u root -p

mysql nome_del_database -u root -p < nome_del_file_dump.pl

Il primo comando ci consente di eliminare eventuali database già presenti nella macchina di destinazione e che possiedono lo stesso nome di quello che stiamo per importare; il secondo comando, invece, ci permette di creare un database vuoto. Infine, l’ultimo comando serve all’importazione vera e propria delle informazioni.

Il post termina qui, a presto.