MySQLTuner è uno script Perl che in analizza il server MySQL e suggerisce le impostazioni migliori basandosi sulle statistiche di utilizzo del server.

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?

La maggior parte delle applicazioni (specie quelle web) utilizzano come backend un database.

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. (continua…)

MySQL supporta nativamente la configurazione master/slave tra due database ma in questo modo si può scrivere solo sul master.

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.

Nel precedente post ho descritto come installare PHP 5, adesso è il turno di MySQL 5.

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. (continua…)

Teoria: two is meglio che one!

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.

(continua…)

Oggi mentre aggiornavo Roundcube alla versione corrente sono incappato in un problema che in teoria non di dovrebbe mai verificare in un db: tuple duplicate.

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.
(continua…)