Re: FreeBSD Cluster Active/Passive MySQL (iscsi, carp, devd, mysql)

Scusa sono già due volte che ti rispondo e mi dimentico di dirti una cosa.... Sarà l'età...

I nostri problemi "veri" con mysql accadono proprio quando zfs si freeza perchè l'istanza "sembra su" sotto ogni punto di vista... La macchina è viva, mysql è vivo, ma si blocca solo quando fai una select (o una insert ovviamente) reale sul db... Questo scenario è piuttosto "scomodo" da gestire per gli strumenti di monitoraggio che ragionano in termini di tcpip e di processi, mentre mysql proxy, che ha il concetto di time out anche sulla esecuzione della quey, li gestisce facilmente.

Ora ho capito che mysql proxy non ti piace (manco a me a dirla tutta) ma ci sarà qualche alternativa dai ;-)

Comunque, prendilo come spunto di riflessione...

Andrea "Mr.SK" Brancatelli

> On 24/ott/2013, at 00:31, "Davide D'Amico" <[email protected]> wrote:
> 
> [...]
>  
>> 
>> Mi fiderei assolutamente di più di un broker di connessioni in alpha piuttosto che un file system a rischio. Ma assolutamente proprio...
> 
> De gustibus... per fortuna la seconda (che è in alternativa appunto a corosync+pacemaker) è l'alternativa ad una soluzione supportata da MySQL/Oracle.
> 
> [...]
> 
>> Quindi tu hai degli slave ma non li usi per farci HA. Interessante... E che ci fai?
> 
> Mah, un pò di cose interessanti, ma non HA (anche perché uno slave lo devi promuovere manualmente).
>  
>> 
>>>  
>>>> 
>>>> O, poi ognuno fa come gli pare, sia chiaro, ma se il grafico con la freccina ti ha persuaso che valga la pena avere due macchine che puntano alla stessa partizione... Mi sa che la notte ti piace alzarti per rispondere a nagios ;)
>>> 
>>> Non ho capito perché, però mi fido :)
>>> 
>>> In realtà gradirei idee/commenti di chi ha qualcosa di simile in produzione, cosa che non mi sembra sia granché comune :)
>>> 
>> 
>> Beh io ho uno scenario di replicazione always on con nodi master master (6 in tutto) in tre datacenter diversi (roma, Pomezia, Milano) per garantire business continuity e disaster recovery anche a fronte di cataclismi ambientali nel quale sono memorizzati (MOLTI!) dati per conto di Regione Lazio. Attualmente siamo a circa 450GB di database.
> 
> E usi mysql-proxy davanti ai 6 master? Paura!
> 
>  
>> 
>> Mai avuto problemi "ordinari" lato replicazione, come ti accennavo precedentemente gli unici problemi che ho in maniera piuttosto costante, purtroppo, è zfs che si freeza sul volume in scan iscsi costringendomi a riavviare la macchina.
> 
> Ecco, di ZFS sulla dbdir si, ne avrei paura :)
>  
>> 
>> Ora ci stiamo accingendo a migrare a mysql 5.6 di modo da avere la replicazione basata sui guiid per poter gestire in automatico anche l'inserimento/espulsione/bypass/promozione dei nodi all'interno del cerchio di replicazione.
>> 
>>> Grazie comunque per i suggerimenti.
>>> 
>> 
>> Figurati, le mailing list servono proprio a stimolare la discussione.
>> 
>> Ribadisco, ognuno ha il suo scenario e i suoi constraint, IO avrei i brividi ad avere i dischi che si montano da soli.
> 
> Mah, ripeto: corosync+pacemaker (anzi, loro ci mettono sopra anche DRBD) è una configurazione supportata (e credo anche certificabile) da Oracle che, ora, non saranno i paladini dell'open source ma in fatto di database qualcosina ne sanno :)
>  
>> 
>> Voglio dire, perfino redHat per usare GPFS (che questo lo fa di mestiere) ti costringe a configurare il fencing di modo da essere in grado di "spegnere" fisicamente un master "decaduto".
>> 
>> Ecco, forse questo è il punto: se veramente sei convinto di dover far così allora nello scenario che hai descritto, secondo me, DEVI assolutamente inserire un meccanismo di fencing in modo da essere sicuro che il master sia _SPENTO_ prima di montare il volume sullo stand by.
> 
> Chiaramente il fencing va inserito 'a corredo' nella soluzione all'inizio del thread (benedetto IPMI), ma l'innesto è abbastanza semplice :)
>  
>> P.s.: non vorrei suonare offensivo, ma si, probabilmente mi fiderei di più di mysql proxy in alpha piuttosto che di una "pila" di software (carp, iscsi, fsck, ipmi...) che assembli tu a suon di script... Ma non dico per te specificamente, sia chiaro, è un "tu" impersonale :-)
> 
> Ci mancherebbe altro, il mondo open source è bello proprio perché è vario :)
> 
> d.
> 
> _______________________________________________
> Esperti mailing list
> [email protected]
> http://mailman.gufi.org/mailman/listinfo/esperti

_______________________________________________
Esperti mailing list
[email protected]
http://mailman.gufi.org/mailman/listinfo/esperti