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

[...]


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