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

Il giorno 22 ottobre 2013 17:53, Gianluca Sordiglioni <[email protected]> ha
scritto:

> Se non ho capito male, è attivo un solo nodo alla volta. Così potrebbe
> funzionare, almeno in ambiti dove a) le scritture non sono molto frequenti,
> b) i dati sono quasi del tutto contenuti in RAM.
> Nel caso a) i dati vengono sì scritti nel binlog, ma magari non hanno
> avuto il tempo di essere scritti nel file, a allora ad ogni switch devi
> gestire il recovery. C'è poi il problema che le scritture in MySQL sono
> sequenziali: due istanze che scrivono sullo stesso file possono fare casino
> se non opportunamente istruite.
> Il caso b) lo cito perché per esperienza la latenza di un disco di rete
> può essere importante, e rallenta di sicuro le performance in caso
> l'applicazione esegua un LOCK TABLE esclusivo.
> Bisognerebbe infine distinguere se vuoi gestire tabelle MyISAM o InnoDB:
> nel secondo caso le cose si complicano, perché è obbligatorio allo switch
> eseguire un recovery, i dati potrebbero essere scritti ma non committati e
> te li perdi, rendendo vano l'uso del cluster.
> A conti fatti mi sembra una soluzione poco efficiente e con vari problemi
> da tenere in considerazione. Visto che la soluzione già c'è, può essere più
> efficace mantenere ogni nodo a sé stante, con due o più macchine identiche,
> e gestire il tutto attraverso tabelle di tipo FEDERATED.
> Dipende come sempre dal tuo ambiente di lavoro, il contesto applicativo e
> cosa ti prefiggi di ottenere.
>

Il mio obbiettivo è quello di avere una coppia active/passive dove sempre e
solo un nodo possiede la share iscsi e l'istanza di mysql che scrive su di
essa. I binlog sono anch'essi su iscsi e l'engine utilizzato è innodb.
Non vedo grossi problemi nel recuperare i dati in caso di fault di un nodo
(e quindi di switch di risorse): cosa che, tranne che casi particolari,
dovrebbe avvenire del tutto automaticamente.

-- 
d.

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