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

> 
> Non tengo i server in giardino o in tangenziale per cui la probabilità che un fesso inciampi in un cavo di rete sono molto più basse (ordini di grandezza) rispetto a quelle di un fault hardware.
> 

Personalmente mi è successo sia nel DC di Telecom Pomezia che nel DC di Fastweb Milano... Ma magari sono sfortunato ;-)


>   
>> . 
> Veramente tu useresti un software in alpha (cfr  http://dev.mysql.com/downloads/mysql-proxy/) per un compito così delicato? La stessa MySQL/Oracle ne sconsiglia l'uso in ambienti di produzione (cfr. http://dev.mysql.com/doc/refman/5.6/en/mysql-proxy.html).
> 

Mi fiderei assolutamente di più di un broker di connessioni in alpha piuttosto che un file system a rischio. Ma assolutamente proprio...


>> 
>> 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.
> 
> Ravana il filesystem? Cioè?
> 

Chessó un Kernel dump che lascia la partizione in uno stato tragico, ad esempio.


> Che poi non perdo nulla, alla coppia di master ho degli slave attaccati. E i backup.

Quindi tu hai degli slave ma non li usi per farci HA. Interessante... E che ci fai?

>  
>> 
>> 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.

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.

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.

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.

Come farlo dipende dall'hardware ed altre considerazioni, ma in generale ipmi dovrebbe servire a questo. Altrimenti se è hp vai di telnet automatico all'ilo, se è dell alla drac, se è IBM.... Insomma hai capito ;-)

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

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