Newsgroup: it.comp.os.linux.sys
Titolo: mysql proxy

Ciao,
qualcuno utilizza in produzione e con soddisfazione mysql proxy?
Per le INSERT  come fate?

 Per le INSERT  come fate?
bisogna istruire il proxy nel mandare le insert/update/delete verso il 
master.
noi abbiamo MMM (Mysql Multi Master)
# mmm_control show 
Daemon is running!
Servers status:
  slave(10.0.100.13): slave/ONLINE. Roles: reader(10.0.100.103;)
  powny(10.0.100.14): master/ONLINE. Roles: reader(10.0.100.102;), 
writer(10.0.100.101;)
  pwny_wise(10.0.100.19): master/ONLINE. Roles: reader(10.0.100.105;)
  staltra_wise(10.0.100.15): slave/ONLINE. Roles: reader(10.0.100.104;)
e poi c'è mysql_proxy
è veramente una figata, si tratta comunque di configurare un file .lua
cerca rw-splitting.lua su google, poi devi dare vari parametri 
a/etc/init.d/mysql-proxy , qualcosa tipo:
--proxy-address=
10.0.100.13:4040
--proxy-backend-addresses=
10.0.100.101:3306
--proxy-read-only-backend-addresses=
10.0.100.102:3306
--proxy-read-only-backend-addresses=
10.0.100.103:3306
--proxy-read-only-backend-addresses=
10.0.100.104:3306
--proxy-read-only-backend-addresses=
10.0.100.105:3306
--proxy-lua-script=/usr/share/mysql-proxy/rw-splitting.lua
la cosa mitica di MMM è che è lui a gestire automaticamente lo stato dei 
server, come vedi MMM gestisce lo status online/offline/recovery dei vari 
server sotto controllo, quindi ad esempio se muore un master lui 
automaticamente lo mette offline nello stack e cambia IP al primo master 
disponibile e così via finché MMM è soddisfatto.
quando va tutto giù infatti ti risponde con: all backends are down.
MMM poi ha in bundle degli script spettacolari per la ricostruzione degli 
slave o di master andati a donnine attraverso LVM e ssh.
buon divertimento
-- 
give it away

 > qualcuno utilizza in produzione e con soddisfazione mysql proxy?
tocca ferro allora: 
http://dev.mysql.com/doc/refman/5.1/en/mysql-proxy.html
prova a leggere cosa c'è scritto in fondo in fondo alla pagina ... non
te lo anticipo.
Questo è invece un bug che ho segnalato personalmente, proprio ieri:
https://bugs.launchpad.net/bugs/568291
dovrebbe essere un problema su Ubuntu e su Debian ... causato dalla
solita vecchia (e stupida) policy "good old stable" che non è sempre
vera.
good is good e bad is bad.
--
Massimiliano


oltre al resto, a livello architetturale, come gestite:
1. la ridondanza di mysql-proxy
2. l'eventuale ridondanza/backup della console di management del
cluster MySQL
cheers

 C'è qualcosa che mi sfugge?
Sì. Che con MMM *un solo* master è attivo alla volta. Gli altri sono slave 
in replica.
-- 
Vide

 cluster MySQL
nemmeno qui ho capito bene, comunque esistono script per clonare lo stato 
del master attivo che crea immediatamente o un altro slave o un altro 
master.
mmm_clone --host powny --clone-mode master-slave
mmm_clone --host powny --clone-mode master-master
questi script clonano la partizione LVM via ssh e fanno altre operazioni, 
quando hanno finito basta poi fare: 
mmm_control set_online staltra_wise
per quanto riguarda il backup esistono diversi tool  tipo
http://www.maatkit.org/
-- 
give it away

 te lo anticipo.
da noi è in produzione da due anni e non ha mai dato problemi,
il lavoro che fa è tuttavia triviale.
so il significato di alpha, solo che non me la sento di pacioccare un 
software che non ha mai dato un problema sotto carichi decenti.
parlo di ~200k query / minuto in media
-- 
give it away

 in replica.
si. Lo so ma (appena provato in questo istante), se fai un drop sullo
slave, viene replicato sul master....
c'è qualcosa che ci sfugge ^_^ Quel master ha un altro significato.
La configurazione Master-Slave di MySQL è un'altra cosa.

 c'è qualcosa che ci sfugge ^_^ Quel master ha un altro significato.
ah, MMM si preoccupa anche di mettere gli slave in READ_ONLY mode
-- 
give it away

 nemmenoqui ho capito bene,
Mettiamola così: se la macchina dove è installata la console è
inaccessibile cosa fate :)
Non dirmi che avete installato la console di management in uno dei
nodi NDB! E' sconsigliato.


ok... tralasciamo il fatto che il software è considerato alpha e
scrivere dappertutto potrebbe essere pericoloso per questo motivo.
Il multi master ti da, se lo hai configurato in quel modo)
effettivamente la possibilità di collegarti ad uno qualsiasi dei nodi
e di eseguire operazioni di scrittura (e ovviamente di lettura).
Quindi, domanda:
questa cosa che dici tu (ovvero scrivere su un master), l'hai forzata
tu per maggiore sicurezza, o è mysql-proxy che (per maggiore
sicurezza) impedisce di scrivere su un nodo a caso?
è corretto ciò che scrivo?

 è corretto ciò che scrivo?
--proxy-address=
10.0.100.13:4040
--proxy-backend-addresses=
10.0.100.101:3306
--proxy-read-only-backend-addresses=
10.0.100.102:3306
--proxy-read-only-backend-addresses=
10.0.100.103:3306
--proxy-read-only-backend-addresses=
10.0.100.104:3306
--proxy-read-only-backend-addresses=
10.0.100.105:3306
--proxy-lua-script=/usr/share/mysql-proxy/rw-splitting.lua
quando si avvia il mysql-proxy tu fai un bind del writer 
--proxy-backend-addresses=
10.0.100.101:3306
con l'ip virtuale, è compito di MMM gestire questi IP correttamente.
lui sa solo dove mandare le query in lettura  read-only-backend e quelle in 
scrittura le manda sul .101
-- 
give it away

 c'è qualcosa che ci sfugge ^_^ Quel master ha un altro significato.
Quello che ti sfugge è che c'è un solo master su cui scrive *l'applicativo* 
in un istante t. Se il master su cui sta scrivendo muore, oppure gli vuoi 
fare manutenzione, oppure vuoi fare un alter table grossa senza bloccare 
l'applicazione, metti il master dell'applicazione su un altro master del 
MMM. E lo fai usando mysql-proxy o usando la logica nella tua applicazione 
(noi per ora abbiamo la logica nell'applicazione per esempio, per mancanza 
di tempo per provare mysql-proxy)
-- 
Vide

 in un istante t
^^^^^^^^^^^^^^^^^
Dimenticare l'istante t perchè genera solo confusione. L'applicazione scrive 
su un solo master e stop.
-- 
Vide


Questo è un limite "organizzato", poiché il proxy è in stato alpha.
La configurazione "master slave" di MySQL esiste, ma è un'altra roba:
non è mysql cluster.


intendiamoci: nel master slave, non c'è ndb, non c'è console ... è
tutta un'altra roba. Pertanto se vuoi usare quella tecnica, non usare
il cluster, perché non ti serve.
Oppure attendi che il proxy arrivi a un livello più stable.

 intendiamoci: nel master slave, non c'è ndb, non c'è console ...
inoltre (occhio): quello è un master NBD, ma non un master mysqld, che
è consa ben diversa ..... si vede chiaro dalla console.

 a/etc/init.d/mysql-proxy , qualcosa tipo:
Sì, ho visto, è che io avrei bisogno di bilanciare anche il traffico
creato dalle INSERT, possibilmente senza approdare al MySQL-Cluster.
Comunque vedo di documentarmi un po' meglio su mmm.
Thanks

 Comunque vedo di documentarmi un po' meglio su mmm.
C'è un ottimo sito a riguardo:
http://maxadamo.dyndns.org/joomla/technical-stuff-mainmenu-23/mysql-mainmenu-49/cluster-ndb-mainmenu-42
Scherzo, magari fosse ottimo .... ti aiuta se vuoi mettere su una 
installazione di base per poterla testare.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 non è mysql cluster.
Facciamo che lasciamo perdere dato che stai facendo solo una grande 
confusione (oltre a tirare in emzzo cose che non c'entrano nulla).
-- 
Vide


Sono convinto del fatto che tu confondi la replica master/slave di 
mysql, con mysql cluster.
La replica Master Slave (vecchia come il cucco) ha un master e degli 
slave. Il Cluster non funziona così.
Il master, è un master NDB e non un master di replica.
Chiediti perché esiste l'uno, e perché esiste l'altro e che senso 
avrebbe poter scrivere solo su un master, anche sul cluster, quando 
esiste già la replica master/slave per questo.


 esiste già la replica master/slave per questo.
Riesumo perchè mi serviva un link.
hai fatto un gran casino, chi ha mai parlato di mysql-cluster?
Qui si parlava di mysql-mmm (che non ha niente a che vedere con il
cluster e non è nemmeno parente) messo dietro ad un mysql-proxy
che 'splitta' le query.
Dove hai preso mysql-cluster e ndb?