Newsgroup: it.comp.os.linux.sys
Titolo: Re: MySQL multi-master replication

 proprie informazioni sull'altro.
un sei mesi fa ho fatto un'analisi del come funziona la replica mysql
per una specie di cluster applicativo (in ambiente di test)
il problema è: le tabelle da replicare vengono aggiornate da uno solo o
entrambi i servers? e soprattutto, sono le stesse?
in questo caso usare una replica è un po' pericoloso. se no, funziona
bene. devi solo adottare alcune attenzioni in più, perchè lui replica
anche operazioni amministrative - tipo check e repair delle tabelle.
per la velocità, lui fa tutto asincrono. quindi spedisce le modifiche in
toto. se fai una update da 1 mb lui spedisce 1 mb, quindi è da valutare
la quantità di dati modificati e se ti servono replicati subito o puoi
aspettare di notte, per esempio. non so se è possibile comprimerlo.
inoltre, mysql specificava di non consigliare una replica circolare
(a->b->c->a), non mi ricordo il perchè
scusa se sono stato un po' didattico, scarta quello che non ti serve

 l'altro negli USA, collegati da una VPN, ma la velocita' non e' eccelsa.
MySQL Cluster sarebbe perfetto nel tuo caso perche' e' una soluzione di 
clustering "share-nothing" (cioe' lo storage non e' condiviso tra inodi), ma 
generalmente e' consigliabile una connessione Gigabit ethernet. Con una VPN 
USA-Europa i tempi di risposta di un'operazione di scrittura potrebbero 
essere molto alti.
A.

 la query ritorni il risultato.
Quando lo provai (un paio d'anni fa, era ancora "giovane") ho 
riscontrato che con tabelle grandi (qualche milione di record) aveva 
richieste esorbitanti di RAM, in sostanza non funzionava. Ora è stato 
risolto?

 l'altro negli USA, collegati da una VPN, ma la velocita' non e' eccelsa.
Attualmente lo utilizzo in una situazione però dove entrambi i server 
sono nella stessa area di rete. Come hanno scritto gli altri funziona, è 
asincrona, e si risolvono alcuni problemi relativi alla generazione di 
chiavi primarie facendo tuning sulla configurazione.
La natura asincrona (ciascuna sessione master memorizza in un file tutte 
le query "non select" effettuate localmente sul server mentre gli slave 
attingono a questo file) da una parte non garantisce che in un dato 
momento i due server siano effettivamente allineati, dall'altra però 
garantisce una certa insensibilità alla velocità del link a differenza 
di MySQL Cluster.
Io ci campo con questa architettura, non ho mai avuto problemi e 
controllo con nagios periodicamente lo stato delle repliche, ma te la 
sconsiglierei per quello che ci vuoi fare.
Angelo

 proprie informazioni sull'altro.
2 mesi fa un consulente mysql mi disse senza mezzi termini che la
replica multi master non andava, e che aveva ancora dei grossi
problemi di stabilita'.
io avevo un esigenza identica alla tua.
-- 
Posted via a free Usenet account from 
http://www.teranews.com

 esorbitanti di RAM, in sostanza non funzionava. Ora è stato risolto?
Sull'ultima versione si' (ma non l'ho mai provata), mentre in quelle 
precedenti le tabelle venivano caricate tutte in RAM, per cui la somma della 
RAM installata sui nodi doveva essere superiore allo spazio totale occupato 
dal db X il numero di repliche.
A. 

 io avevo un esigenza identica alla tua.
E quindi come hai fatto?

 
Ciao,
io ne ho un paio in produzione... per ora (sgrat!) nessun problema, anzi in
un "cluster" una macchina è morta (problema hw) e sull'altra mysql continua
a funzionare egregiamente.. ancora non abbiamo provato a ripristinare la
replicazione, però! :-D
Ho seguito questi due 
how.to
:
http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html
http://www.howtoforge.com/mysql_master_master_replication
Spero di esserti stato utile.
Ciao,
-- 
Sandro.