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

Premesso che il sistema è tuo e ci fai quello che vuoi tu, la soluzione replicata mi pare di sicuro molto più stabile e certificabile di una soluzione con volumi in riciclo. Non stai facendo un setup GPFS con un file system che "sa" ed è in grado di gestire situazioni di accessi contemporanei al disco. Con il tuo setup un fesso che inciampa nel cavo di rete ti fa partire l'escalation dello slave che monta il file system già montato dall'altra parte e distrugge la partizione prima che tu riesca a dire crostatina alla marmellata. ;-)

La soluzione "giusta" è un setup dual master con replicazione circolare ed un'istanza mysql proxy che rediriga le connessioni dei client verso il nodo master quando è attivo e verso lo slave quando il master è in fail. Il tempo di "reazione" di mysql proxy è istantaneo, neanche i famosi 5 minuti del fsck, entrambi i db sono always on (il che vuol dire che ad esempio puoi fare i backup dal nodo slave senza inficiare le performance del sistema in produzione, o magari lunghe estrazioni statistiche senza degrado delle prestazioni) e sempre coerenti ragionando con i constraint di transazionalita propri del database e dell'acid. Come qualcuno ti ha fatto notare un file system ha una cache e può rimanere sporco, con esiti tragici per le transazioni scritte a metà e per i log di innodb.

Portarlo, voglio dire, la cosa più importante (di solito) sono i dati, non le macchine. Con questo setup se una macchina impazzisce e ravana il file system la cosa non ti tange, nell'altro caso perdi in una botta sola entrambe le macchine. Crei un single point of failure piuttosto importante.

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



Andrea "Mr.SK" Brancatelli

> On 23/ott/2013, at 08:05, "Davide D'Amico" <[email protected]> wrote:
> 
> 
> 
> 
> Il giorno 23 ottobre 2013 07:48, Luca Ferrari <[email protected]> ha scritto:
>> 2013/10/22 Davide D'Amico <[email protected]>:
>> 
>> > L'utilità di questo setup risiede nel fatto che se hai un fault hardware sul
>> > nodo master, lo switch sul nodo slave è automatico e veloce (ok c'è un fsck
>> > di mezzo ma almeno non devi aspettare nagios/alert/telefonate/etc etc),
>> > quindi è una soluzione improntata esclusivamente per HA.
>> 
>> Veloce e automatico stride con fsck.
> Beh, rispetto alle 2h necessarie per alzarsi dal letto, svegliarsi, accendere il pc, capire che è successo etc etc direi che è "veloce e automatico" (specialmente se il filesystem è provvisto di journal): con un filesystem da 128GB la promozione del nodo 'slave' ha impiegato meno di 5 minuti.
>  
>> 
>> > Se usassi due server master/slave 'classici' la promozione non sarebbe
>> > automatica, e potrei anche avere situazioni spiacevoli in cui lo slave sia
>> > indietro rispetto al master.
>> 
>> No.
>> In replica lo slave può essere indietro del master di una latenza di
>> rete (che nella tua configurazione è sicuramente minima), ma almeno è
>> coerente. Nel tuo setup rischi di avere slave e master che sono
>> sincronizzati all'ultimo bit fuori transazione e quindi non sono
>> consistenti, che non penso sia quello che vuoi (ossia è molto piu'
>> spiacevole di non avere lo switch automatico).
>> Ci sono molte soluzioni per fare un pooling di master/slave
>> trasparente, quindi se il tuo unico scopo è avere il database in HA la
>> replica è la soluzione.
> 
> Purtroppo no, la replica non è una soluzione di HA "accettabile" di livello enterprise (cfr. http://dev.mysql.com/doc/mysql-ha-scalability/en/ha-overview.html, Figure 1.1 e Table 1.1).
>  
>> Inoltre il tuo setup ha, sempre secondo me, un problema proprio in
>> caso di failure: come fai ad analizzare (sempre ammesso che ti
>> interessi) cosa è successo sul nodo crollato e magari testare (con
>> dati validi) la sua configurazione in isolamento se i dati sono
>> "posseduti" dall'altro nodo?
> 
> In effetti col mio setup analizzare cosa è successo non mi interessa granché e posso farlo a posteriori in qualsiasi momento, quello che mi interessa è che non ci sia interruzione di servizio (HA, appunto).
> 
> 
> Per rispondere a Gianluca (che mi sembra l'unico che va oltre la 'classica' replica): ho lo storage engine federated disabilitato e non andrei oltre le configurazioni di HA previste da MySQL/Oracle (vedi link precedente).
> 
> Mi sarebbe piaciuto testare la soluzione Percona (xtradb e galera), vedremo.
> 
> Grazie a tutti,
> 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