Newsgroup: it.comp.os.linux.sys
Titolo: GlusterFS test su DB MySQL

Qualcuno ha testato MySQL su due o piů nodi GlusterFS ?
 
Grazie!
 
-- Yena --

 Qualcuno ha testato MySQL su due o più nodi GlusterFS ?
 
Uhm, a che pro? 
Tanto non puoi scrivere su ambo i nodi contemporaneamente, in tal caso credo sia molto più performante drbd.

 Tanto non puoi scrivere su ambo i nodi contemporaneamente, in tal caso credo sia molto piů performante drbd.
 
Per avere un alternativa alle repliche e a DRDB ..
Mi sembra piů smart di DRDB ..
 
-- Yena --

 Mi sembra più smart di DRDB ..
 
Ma non saprei.
Fan due cose diverse, DRBD sincronizza a livello di blocchi, questo a livello di file. Per MySQL mi sembra più sensato sincronizzare a blocchi.


Usare la replicazione nativa di mysql pare brutto ?

 Usare la replicazione nativa di mysql pare brutto ?
 
Qualunque cosa è meglio della replicazione nativa.
Compreso un piccione viaggiatore.

 viaggiatore.
 
Concordo.


Moh.
Ne ho (a memoria) un paio di dozzine in giro, perlopiù in replica
circolare, alcune delle quali in esecuzione da anni.
 
Perfettibile, ma funziona senza problemi.
 
Quali sarebbero i problemi che ci trovi?
 
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
 

 Quali sarebbero i problemi che ci trovi?
 
Stanno in piedi con lo sputo, basta una query fatta male o una collisione (nel caso se ne presentasse una) per 'sganciare' il nodo della replica.
 
Non esiste alcun meccanismo di recovery automatico, se si sgancia dalla replica non ti da segni di vita se non tramite sistemi di alert fatti in casa e per reintegrarlo, quando mi è capitato, son sempre state vagonate di bestemmie.
 
Piuttosto, hai mai fatto multimaster? A quante repliche sei arrivato? (intendo simultanee per lo stesso master)

 (intendo simultanee per lo stesso master)
 
L'installazione "più grossa" al momento usa un master e quattro slave...
 
Se poi ti ti senti ben confidente, dai un occhio a 
http://goo.gl/2oF7O
 
 
Mai capitato di usarlo (almeno, non ancora), ma se funziona come deve (e
quelli di Percona non sono proprio gli ultimi arrivati, al riguardo) lo
voglio... :-P

 voglio... :-P
 
HEY! Ma questo è UNA FIGATA PAZZESCA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
Butta un occhio anche al cluster Percona rilasciato da pochi giorni (mi pare), unico neo: solo innodb.
 
 

 Come accedi agli slave, proxy o accessi diretti?
 
diretti.
 
 
 
 

 diretti.
 
E se ti muore lo slave riconfiguri i client?
Avrai qualcosa di dinamico spero.

 a buon fine ed il master non è stato notificato.
 
 
Mi ripeto, ma questa è una troiata. Se lo slave ha problemi temporanei
che lo portano a non essere in condizione di eseguire la query,
semplicemente non la esegue e l'indice del relay log non incrementa.
Ergo, appena sarà in condizione di eseguire qualcosa, ripartirà
esattamente da lì.

 dinamico spero.
 
Ho la logica di roundrobin e failover tra i database all'interno di gran
parte dei client che vi si appoggiano.
Le applicazioni che non lo fanno da sole, invece, puntano ad un IP
flottante tra i due slave, gestito da pacemaker.

 esattamente da lì.
 
Forse le ultime versioni, perchè quando ho usato le repliche io non era così.
Se lo slave non riesce ad eseguire una query, si sgancia la replica e devi intervenire manualmente risolvendo il conflitto e poi riassociarlo al master.
 
Sarà anche una troiata da fare, ma io preferisco dormire tranquillo la notte sapendo di non aver probabili inconsistenze tra i vari server mysql.
Il master ha dei dati, lo slave1 ne ha altri non aggiornati, lo slave2 potrebbe averne ancora diversi.
 
In certe situazioni non è possibile avere database disallineati.

 ho trovato dove ho sbagliato...
 
Non sei l'unico.
Hai poi capito la query che faceva saltare la sincronizzazione?

 flottante tra i due slave, gestito da pacemaker.
 
Ok, in caso contrario mi sembrava un suicidio.


voglio spendere ZERO parole in favore di MySQL, però, chicos, immagino che 
quella quantità smisurata di DB mysql che girano in facebook, funzionino 
proprio con le repliche. 
memcache o non memcache, cassandra o non cassandra, io credo che loro 
usino pure le repliche mysql. Ed avendone loro a migliaia, ed ascoltando 
le vostre esperienze, io mi aspetterei che gli si dovrebbero sbragare al 
ritmo di un o al minuto.
O sbaglio qualcosa? .... potrei addirittura sbagliarmi sul fatto che usano 
le repliche :) ... ma non credo.

 le repliche :) ... ma non credo.
 
Nel loro caso è sensibilmente più facile, hanno un solo applicativo (sviluppato da loro) che deve accedere ad una infrastruttura sempre sviluppata da loro.
Mettere le mani a livello applicativo e gestire le problematiche a tale livello è molto più semplice che dover ospitare centinaia di database di centinaia di clienti con centinaia di software/CMS senza possibilità di intervenire sul codice in alcun modo.
 

 sviluppata da loro.
 
Ma lo sai che stai diventando molto saggio ? :-D
Ari-concordo.

 Ari-concordo.
 
LOL, ti ho preso come mentore :)

 
"binlog_format = MIXED" in my.cnf e hai tolto gli warning.
  Giovanni


Ora che mi ci fai pensare sì avevo risolto così il problema dei log. Non 
ero però riuscito a risolvere il probleman del Seconds_Behind_Master che 
aumentava inesorabilmente