Premesso che MySQLTuner non fa miracoli ma semplici ottimizzazioni, vediamo come installarlo:

apt-get install mysqltuner

Adesso con un semplice mysqltuner lanciamo il nuovo tool:

>> MySQLTuner 0.9.0 - Major Hayden
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password:
-------- General Statistics --------------------------------------------------
[!!] There is a new version of MySQLTuner available
[OK] Currently running supported MySQL version 5.0.51a-24+lenny4-log
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 4M (Tables: 1311)
[--] Data in InnoDB tables: 300M (Tables: 2275)
-------- Performance Metrics -------------------------------------------------
[--] Up for: 17h 28m 59s (6M q [97.770 qps], 18K conn, TX: 11B, RX: 1B)
[--] Reads / Writes: 84% / 16%
[--] Total buffers: 2.6M per thread and 106.0M global
[OK] Maximum possible memory usage: 368.5M (9% of installed RAM)
[OK] Slow queries: 0% (2/6M)
[OK] Highest usage of available connections: 11% (11/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/4.7M
[OK] Key buffer hit rate: 99.2%
[OK] Query cache efficiency: 93.5%
[!!] Query cache prunes per day: 362758
[OK] Sorts requiring temporary tables: 0%
[!!] Joins performed without indexes: 5599
[!!] Temporary tables created on disk: 78%
[OK] Thread cache hit rate: 99%
[!!] Table cache hit rate: 0%
[OK] Open file limit used: 0%
[OK] Table locks acquired immediately: 100%
[!!] InnoDB data size / buffer pool: 300.1M/8.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
MySQL started within last 24 hours - recommendations may be inaccurate
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (> 64M)
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 32M)
max_heap_table_size (> 16M)
table_cache (> 128)
innodb_buffer_pool_size (>= 300M)


Il risultato è più che eplicito.
MySQLTuner mi dice che vanno aggiunte o modificati i valori, delle seguenti variabili:


query_cache_size (> 64M)
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 32M)
max_heap_table_size (> 16M)
table_cache (> 128)
innodb_buffer_pool_size (>= 300M)


Edito il file di configurazione di MySQL (in Debian /etc/mysql/my.cnf) e lo modifico come suggerito.
Fatta la modifica va ovviamente riavviato il servizio MySQL.

Vedete miglioramenti?

Il database più diffuso in ambito opensource è MySQL forse perché fa parte del mitico quartetto LAMP o semplicemente perché all’epoca era il dbms più veloce della storia… Chissà quale sarà il futuro di MySQL, ma in questo post è meglio parlare del presente.

Di solito chi ha a che fare con MySQL e vuole salvare i preziosi dati contenuti al suo interno, effettua un backup del database (o dei databases) e salva il dump da qualche parte.
Nulla da eccipere a questo modus operandi.
Ma se il db è grande quanto spazio occupa un backup? Quanto tempo ci si impiega a fare un dump?
Mi è capitato che durante un backup di MySQL l’utilizzo delle risorse schizzasse alle stelle e quindi mi sono messo alla ricerca di un sistema di backup degno di chiamarsi tale e la soluzione è stata ZRM fro MySQL.
Zmanda Recovery Manager (ZRM) for MySQL è un tool che permette di:

• effettuare backup incrementali o full
• avere una gestione centralizzata dei backup
• ricevere notifiche via e-mail, RSS ed HTML sull’esito dei backup
• effettuare backup compressi e criptati
• ripristino dei backup in modo facile
• …e molto altro ancora!

Per altri features ed informazioni consiglio di leggere il WiKi.

In questo primo post vedremo come configurare un backup di un server MySQL che si trova sulla stessa macchina dove risiede MySQL. Ovviamente il backup potrà essere salvato su una partizione NFS o su una chiavetta USB ma in sostanza ZRM e MySQL sono sulla stessa macchina.Nel prossimo articolo vedremo come fare un backup di un server MySQL remoto.

Procediamo con l’installazione, ovviamente su Debian.
Nei repository Debian non c’è il pacchetto (eresiaaaa!) ma dal sito possiamo scaricare il comodissimo .deb:

http://www.zmanda.com/download-zrm.php

Basta selezionare l’ultima release (ad oggi la 2.2) e nella pagina successiva possiamo fare il download del pacchetto  mysql-zrm-client_2.2.0_all.deb.

Prima di installarlo abbiamo bisogno di alcuni software a corredo: perl-DBI e perl-XML-parser.

Installiamo:

apt-get install libxml-parser-perl libdbd-mysql-perl

Se tutto è andato a buon fine installiamo ZRM con:

dpkg -i mysql-zrm_2.2.0_all.deb

Adesso abbiamo ciò che ci serve, ma per fare i backup incrementali abbiamo bisogno che MySQL scriva il suo utilissimo logbin.
Per abilitare questa opzione, basta editare /etc//mysql/my.cnf e decommentare:

log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M

Adesso il file va salvato e si deve riavviare il server MySQL.

I file di configurazione si trovano nella directory /etc/mysql-zrm, andiamo a vedere cosa c’è dentro:

• mysql-zrm.conf
• mysql-zrm-release
• mysql-zrm-reporter.conf
• RSS.header

Di vitale importanza sono i .conf, perché mysql-zrm-release ci dice che versione abbiamo e RSS.header è autoeplicativo, serve per l’RSS generato dal sistema di backup.

Dentro la directory /etc/mysql-zrm possiamo creare una nuova directory e dentro copiare i .conf appena illustrati.
Ciò ci permette di avere vari set di backup che hanno delle configurazioni proprie ed in più ereditano quelle presenti sotto /etc/mysql-zrm.
Esempio pratico: se tutti i database hanno la password di root identica possiamo specificare username e password nel file /etc/mysql-zrm/mysql-zrm.conf e non nel file mysql-zrm.conf presente nella directory del set.

Passiamo dalla teoria alla pratica.
Voglio fare in modo che venga fatto un backup di svariati server che hanno in comune:

• la password di root di MySQL
• la directory di destinazione dove salvare i file
• il tipo di backup
• uso di routines e quindi il backup delle stesse
• la directory dove sono salvati i logbin di MySQL
• la directory temporanea
• l’indirizzo e-mail sul quale riceve le notifiche
• il tipo di report
• il path dove salvare i report html
• la URL dal quale consultare i report html
• il path da dove prendere l’header per l’RSS

Detto questo avremo che il file /etc/mysql-zrm/mysql-zrm.conf conterrà (nel mio caso, mi raccomando personalizzate i parametri) questo:

backup-mode=logical
destination=/mnt/nfs/mysql-zrm
routines=1
mysql-binlog-path="/var/log/mysql"
tmpdir=/tmp
mailto="info@ideafactory.it"
html-reports=backup-status-info,backup-performance-info
html-report-directory=/var/www/mysql-zrm/reports/
webserver-url=http://backup.ideafactory.it/reports/html/
rss-header-location=/etc/mysql-zrm/

Adesso mi creo il file di configurazione per il set che chiamerò ”silver”  e quindi creerò la directory /etc/mysql-zrm/silver ed il file mysql-zrm.conf al suo interno conterrà (ripeto: nel mio caso!) :

comment=Silver
backup-level=0
all-databases=1
user="root"
password="superpasswordsegreta"
retention-policy=7D
host="localhost"
port=3306
socket=/var/run/mysqld/mysqld.sock

Ci siamo. Proviamo ad eseguire un backup di prova con:

mysql-zrm-scheduler --now --backup-set silver

Ovviamente a me il set si chiama silver…

Prima di spiegare i vari comandi penso sia il caso di illustrare i parametri di configurazione.
Maggiori dettagli si trovano nel capitolo dedicato ai parametri dell’ottimo manuale di ZRM.

Il set “silver” fa un backup completo (backup-level=0) di tutti i database (all-databases=1)  presenti sul server locale infatti ho chiamato il set silver proprio come il server così rende l’idea che il backup è di tutti i database presenti.

Adesso proviamo a dare un backup incrementale.

Non serve editare il file di configurazione del set, perché se passiamo il parametro da linea di comando backup-level=1 viene ignorato quello presente nel file di configurazione. Proviamo:

mysql-zrm-scheduler --now --backup-set silver --backup-level=1

Non vengono fuori errori? Avete ricevuto la comoda e-mail?

Adesso è il caso di fare qualche strage al database e provare a fare un ripristino ma prima vediamo un report dei backup effettuati con il comodo comando:

mysql-zrm-reporter --show backup-status-info

Sotto forma tabellare comparirà un comodissimo riassunto che qui non riporto per motivi di formattazione ma è ben visibile nella documentazione.

Bene, facciamo fuori un database! L’ho appena fatto con un DROP DATABASE…!

Adesso vediamo come ripristinarlo.

La prima domanda è “che backup ho del set a cui apparteneva il defunto database?” La risposta viene da qui:

mysql-zrm-reporter -show restore-info --where backup-set=silver

Dalla lista scelgo il backup corretto è con un semplice:

mysql-zrm --action restore --backup-set silver --source-directory /mnt/ibm/mysql-zrm/silver/20100325214251

Abbiamo riportato in vita il db defunto partendo dallo snapshot posizionato nella directory illustrata dal report!

Se abbiamo cancellato 2 database e ne vogliamo ripristinare solo uno? Beh le opzioni offerte sono molteplici e la guida sul recovery presente nella documentazione ci mostra comandi per risolvere anche i casi disperatissimi!

Fin ora abbiamo visto come fare un backup e come ripristinarlo, una volta scelta la policy più appropriata alle nostre esigenze è il caso di schedulare i backup:

mysql-zrm-scheduler --add -interval daily --start 08:00 --backup-set silver --backup-level 0
mysql-zrm-scheduler --add -interval daily --start 14:00 --backup-set silver --backup-level 1
mysql-zrm-scheduler --add -interval daily --start 19:00 --backup-set silver --backup-level 1

Con questi 3 semplici ed esplicativi comandi ho detto al mio nuovo amizo ZRM di fare 3 backup:

1. il primo alle 8.00 di mattina ed è un full backup
2. il secondo alle 14.00 ed è di tipo incrementale
3. il terzo alle 19.00 ed è sempre incrementale

Le opzioni sono svariate ed accontenteranno tutti. Una domanda sorge spontanea: ma i backup vecchi quando vengono cancellati? Questo viene deciso dal parametro retention-policy, presente nel file di configurazione.

Per questo primo episodio dedicato a ZRM è tutto, spero di aver stimolato la vostra voglia di backup e la curiosità nello spulciare le mille opzioni di questo indispensabile software.

Se si ha la necessità di  avere due database identici ed eseguire su entrambi operazioni di scrittura è necessario sincronizzarli in qualche modo. Si può optare per rsync e quindi aggiornare i file che compongono il database o, come nel caso che vedremo tra poco, usare i comandi di MySQL e muovere i dati via SSH.

Supponiamo di voler trasferire il dump di un database locale in un db remoto, il comando è questo:

ssh user@www.my_domain.com "mysqldump
-u my_remote_db_username --password=my_remote_db_password my_remote_db_name"
| mysql -u my_local_db_username --password=my_local_db_password --host=localhost -C my_local_db_name

Viceversa, dal database remoto a quello locale:
mysqldump -u my_local_db_username --password=my_local_db_password --host=localhost -C my_local_db_name | ssh user@www.my_domain.com "mysql -u my_remote_db_username --password=my_remote_db_password my_remote_db_name"

Facile no?

Usando SSH con autenticazione a chiave pubblica è possibile automatizzare la sincronizzazione con crond e quindi schedulare il processo di aggiornameno.

Per scaricare la versione open-source del celebre database server bisogna recarsi qui:

http://dev.mysql.com/downloads/mysql/5.0.html#macosx-dmg

Scegliere il pacchetto più adatto all’hardware ed alla versione di Mac OS X che si possiede.

Il file .dmg scaricato contiene il server vero e proprio ed il comodissimo tool, MySQL.prefPane, che aggiunge alle “Preferenze di sistema” la possibilità di avviare MySQL.

Installiamo prima il server e poi MySQL.prefPane.

Un bel messaggio di conferma vi segnalerà che l’installazione del server è andata a buon fine.

Cliccando su MySQL.prefPane vi verrà chiesta conferma per l’aggiunta di “MySQL” al pannello delle preferenze quindi selezionate “Installa” ed immettete la password.

Adesso, in perfetto stile Apple, vi basterà cliccare su “Start MySQL Server” ed il potente DBMS sarà al vostro servizio.

Sicuramente si avrà la necessità di usare PHP con MySQL e per non incappare in questo errore:

Non parte? Bene, o meglio non bene…

La versione che ho provato ad installare io è la 5.0.51 ed ha un piccolo BUG: il file di avvio di MySQL, chiamato MySQLCOM viene creato in /usr/local e non in /Library/StartupItems/ quindi con un semplice:


sudo mv /usr/local/MySQLCOM /Library/StartupItems/


E’ necessario anche verificare i permessi della direcory /usr/local/mysql/data, se con:

ls -al /usr/local/mysql/data/

Avete in risposta un bruttissimo “ls: : Permission denied“, è necessario cambiare i permessi alla directory di MySQL:

sudo chown -R /usr/local/mysql/data

Adesso tutto dovrebbe funzionare e di certo questi piccoli problemini saranno risolti nelle prossime versioni di MySQL per Mac OS X.

Sicuramente si avrà la necessità di usare PHP 5 con MySQL per non incappare in questo errore:

Can't connect to local MySQL server through socket '/var/mysql/mysql.sock'

bisogna configurare PHP a cercare il file di sock nella posizione dove MySQL lo crea.

Nella directory /private/etc/, è presente il file php.ini.default, va rinominato:

sudo mv /private/etc/php.ini.default /private/etc/php.ini


Adesso è necessario editarlo e cambiare queste due direttive:

mysql.default_socket =
mysqli.default_socket =

in:

mysql.default_socket = /private/tmp/mysql.sock
mysqli.default_socket = /private/tmp/mysql.sock


Sarà necessario salvare il file php.ini ed riavviare Apache.

Pratica:

La replicazione fornita da MySQL si definisce “one-way“, perché tale operazione è gestita dal server in modo monodirezionale, ovvero consente di replicare le operazioni di scrittura effettuate su un database master su più database slave.

Come è lecito aspettarsi i server slave saranno utilizzati solo per le letture mentre, sul master, graveranno gli inserimenti e gli update (nessuno vieta di utilizzarlo anche per le operazioni di select).

Il procedimento di replicazione di MySQL si riassume in questi step:

1. Il master registra le query di scrittura (inserimento, update etc) in un file
2. I server slave leggono il file di log del master ed eseguono le operazioni lì riportate aggiornando il database locale

Il rapporto tra master e slave è così definito:

• un master può avere più slave
• uno slave può avere un solo master

Bene si parte.

Configuriamo il master

Prima di tutto:

/etc/init.d/mysql stop

Così non si fanno disastri con il server up.

Utilizzando Debian è necessario editare il file /etc/mysql/my.cnf per abilitare il networking e la scrittura del file di log:

#skip-networking
bind-address = [indirizzo_ip_raggiungibile_dal_server_slave]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
binlog_do_db = [nome_db_da_replicare]

Adesso per sicurezza, cancelliamo (se presenti) i file di log dentro /var/log/mysql/ che iniziano con mysql-bin.*.

Questo serve per far ricreare al server un file di log pulito ed a prova di errore.
A questo punto facciamo ripartire il server con il classico


/etc/init.d/mysql start

Ripartito il server, accediamo via consolle a MySQL:

mysql -u root -p

E diciamo a MySQL di consentire la replica al nostro slave:

GRANT REPLICATION SLAVE ON *.* TO '[nome_utente]'@'[indirizzo_ip_dello_slave]' IDENTIFIED BY '[password]';
FLUSH PRIVILEGES;

Ora bisogna selezionare il database da replicare e sbloccare eventuali lock di lettura per spostare i dati (se presenti) dal master allo slave:

USE [nome_database];
FLUSH TABLES WITH READ LOCK;

Controlliamo lo stato del master:

SHOW MASTER STATUS;

Dovrebbe venir fuori qualcosa del genere:

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 98 | [nome_db] | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)


Bene, adesso usciamo dalla shell di MySQL (con il classico quit;) ed esportiamo il database in un file sql da traferire sul server slave:

mysqldump -u root -p --opt [nome_db] > [nome_db].sql


Configuriamo lo slave

E’ necessario creare il database da replicare quindi entriamo nella consolle del server MySQL:


mysql -u root -p
Enter password:
CREATE DATABASE [nome_db];
quit;


Importiamo il dump SQL del server master:


mysql -u root -p [nome_db] < [path_dove_e_salvato_il_file]/[nome_db].sql


Adesso bisogna editare il file /etc/mysql/my.cnf per abilitare la lettura del file di log del master:

server-id=2
master-host=[ip_master]
master-user=[user_creato_sul_master]
master-password=[password]
master-connect-retry=60
replicate-do-db=[nome_db]

Le direttive per il log bin sul server slave possono essere disabilitate.

Bene, abbiamo finito, un bel riavvio e siamo a posto:

/etc/init.d/mysql restart

Ogni cosa che scrivete sul master verrà (forse ) replicato in pochi millesimi di secondo sullo slave.

L’errore è venuto fuori eseguendo questa query:
ALTER TABLE `messages`
DROP `body`,
DROP INDEX `cache_key`,
ADD `structure` TEXT,
ADD UNIQUE `uniqueness` (`user_id`, `cache_key`, `uid`);

Che ha lo scopo di adeguare il vecchio db con la struttura nuova.
In particolare il problema si verificava aggiungendo l’indice univoco composto da `user_id`, `cache_key`, `uid`.
Siccome seguo Roundcube da prima che gli spuntassero i primi dentini è normale che ci sono stati errori nello sviluppo e quindi è logico che si è arrivati ad un problema simile.

Come si procede per risolvere l’inconveniente? In due semplici step:

1. Si elencano i valori duplicati
2. Si eliminano i valori duplicati

Prima di togliere i valori duplicati l’errore era questo:

#1062 - Duplicate entry '8-INBOX.msg-1' for key 2

Giusto per rendere il più pratico possibile l’articolo…

Procediamo con il passo1:
Per elencare i valori duplicati basta usare questa query:

SELECT `cache_key` , `uid` , `user_id`, COUNT(*) AS quanti
FROM `messages`
GROUP BY `cache_key` , `uid` , `user_id`
HAVING quanti > 1;
Seleziono i campi coinvolti nella creazione dell’indice univoco ed in più conto le occorrenze, infine raggruppo i valori per i campi selezionati e mostro solo quelli che hanno occorrenza maggiore di 1.
Il risultato spaventoso della query è:

cache_key uid user_id quanti
INBOX.msg 1 8 2
INBOX.msg 2 70 2
INBOX.msg 3 30 2
INBOX.msg 5 101 3
INBOX.msg 28 43 4
INBOX.msg 40 43 3
INBOX.msg 42 43 2
INBOX.msg 45 43 2
INBOX.msg 52 43 2
INBOX.msg 53 43 2
INBOX.msg 57 101 3
INBOX.msg 63 101 5
INBOX.msg 84 101 2
INBOX.msg 85 101 2
INBOX.msg 1155 68 2
INBOX.msg 1156 68 2
INBOX.msg 1920 7 3
INBOX.msg 3362 7 2
INBOX.msg 3363 7 2

Bene adesso occorre visualizzare e distruggere!
Con questa query:

SELECT *
FROM `messages`
WHERE `cache_key` = 'INBOX.msg'
AND `uid` =1
AND `user_id` =8
si selezionano le occorenze della prima tupla duplicata e quindi è sufficiente cancellare quelle in eccesso. Io ho sempre lasciato la più vecchia, massimo rispetto per gli anziani.
Ripetere la query modificando opportunamente parametri per tutte le tuple duplicate.

Finito?
Proviamo adesso a rieseguire la query….FUNZIONA!
Infine voglio regalare una chicca, mettendo dopo ALTER, prima di TABLE, la clausola IGNORE il DBMS non si ferma al primo errore di record duplicato, ma va avanti, e di fatto salta l’inserimento dei record con valori già inseriti.
Quindi la fatica di prima era evitabile!
Hihihi che dispettoso vero? Sento gli insulti…
Non l’ho detto subito perché non l’ho mai provato e a me piace fare le cose a manina per verificare con i miei occhi che tutto sia a posto.
Quando riavrò il medesimo problema userò IGNORE.