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…)