Newsgroup: it.comp.os.linux.sys
Titolo: Mysql Master/Master

Ciao,
ho un e-commerce LAMP
che ora gira in configurazione
MySQL Master/Slave.
Che voi sappiate c'� modo di far girare
una configurazione Master/Master senza
i "salti" nelle autoincrementali:
auto-increment-increment = 2
auto-increment-offset = 2
Purtroppo l'applicativo le usa come id della Fattura :-(
ed in altri posticini carini ..
Grazie mille
-- Yena --

 ed in altri posticini carini ..
 
Posto che non saprei come risolvere il tuo problema, se puoi mettere mano 
all'applicativo implementa questo:
 
http://appunti-liberi.blogspot.com/2010/12/mysql-e-sequenze.html
 
 
Enrico

 Per quale motivo vuoi master/master?
Non sono l'estensore del post, ma mi trovo in una situazione simile, per 
MySQL e Mongodb.
Mi ci trovo perchè l'idea è di avere dei singoli DB presenti presso 
alcuni carrier che erogano dati all'application server.
La necessità è di leggere molto, ok, ma qualche volta di scrivere pure.
Per qeusto potrebbe essere, tolte le valutazioni di HA e DR  solite, di 
poter tenere tutti i DB coerenti anche se uan scrittura avvennisse sul 
sito A e l'altra nel sito B (per siit intedo siti fisici dove vivono i DB).
Col mongo pare si possa fare, le ReplSet ed il cluster prevedono la 
possibilità, ma con Mysql già è un calvario il master/slave figurarsi se 
esiste master/master (ma è una domanda la mia).
Con postgresl dite che potrebbe essere una via percorribile?

 Con postgresl dite che potrebbe essere una via percorribile?
9.0 repliche asincrone
9.1 repliche sincrone.
Potresti provare il 9.1 che *dovrebbe* farlo (parlo da chi usa postgres 
da anni ma il 9.1 non l'ha ancora provato).

 Con postgresl dite che potrebbe essere una via percorribile?
 
La 9.1 appena uscita dichiara di avere le repliche sincrone.
Mai provato (sono ancorato alla 8.4)
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 


Mi correggo: non multimaster come servirebbe a te.
 
Potresti però guardarti questo: 
http://bucardo.org/wiki/Bucardo
 
 

 da anni ma il 9.1 non l'ha ancora provato).
 
Ho letto, in effetti è sicuramente migliore di Mysql.
Ma manca quel pezzetto che forse è più importante, almeno per i miei scopi.
 
Se il nodo ita1 riceve una scrittura, anche il nodo romania1 deve 
allinearsi (master/slave)
Ma qualora il nodo romania1 ricevesse uan scrittura, il nodo ita1 che fa?
 
Nel caso di Mysql, nulla, non essendo concepibile che uno slave abbia 
modifiche non presenti sul master.
 
Con mongo leggo che riuscirebbe a metterli invece correttamente in 
ordine, replicando anche i dati sul nodo primary.
 
Questa logica è differente dal classico schema di un master ed n slave, 
è proprio master/master.
 
Sto leggendo la documentazione di postgres, ma oltre al fatto che è 
chiaramente più solido e votato alla produzione (senza nulla togliere ad 
altri) non ha la caratteristica di cui parlavo.


Non l'ho mai provato ma potresti dare un occhio a questo:
http://mysql-mmm.org/
 
 Giovanni

 scritture le replichi anche sull'altro master.
E' quello che voglio, non aumento della capacità, ma gestione di nodi 
locali che vivono dei dati del db immediatamente vicino, ma coerente, 
senza doversi collegare al master che vive altrove.

 Con postgresl dite che potrebbe essere una via percorribile?
Si, con la 9.1 la replica multimaster e` fattibile in modo nativo (replica 
sincrona), mentre con tutte le versioni e` fattibile tramite tool esterni 
(PgPool-II e Sequoa lo fanno, per citarne un paio)
Enrico

 altri) non ha la caratteristica di cui parlavo.
 
Ripeto: con la replica sincrona, dovresti fare una replica Master/Master, in 
ogni caso puoi implementarla tramite PgPool-II che, oltre al multimaster, ti 
permette di implementare altre cose carine (e.g. load balancing e 
parallelizzazione della query tra i nodi)
 
Enrico

 di parecchi minuti, anche decine)
Dipende da come lo configuri.
A me entro 30 secondi entra in funzione e comunque mai sopra il minuto.

 consigli realmente utili, quanti più dettagli, meglio è)
 
Parole sante.
 
Spesso  meglio non utilizzare accrocchi strani perchè possono succedere i 
peggiori casini.
Un ambiente di test funziona sempre tutto ma quando sei in produzione e 
hai dei DB su nodi differenti che non sono più sincronizzati sono uccelli 
per diabetici.
 
Meglio andare sul sicuro e utilizzare il classico master/slave o master/
master active/passive che rischiare perdite di dati.
 

 A me entro 30 secondi entra in funzione e comunque mai sopra il minuto.
 
In effetti anche a me non è mai capitato di andare oltre il minuto.
Anzi, quando facevo le prove, il takeover era nell'ordine di
alcuni secondi.
 
 
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 A me entro 30 secondi entra in funzione e comunque mai sopra il minuto.
 
Entro 30 secondi ti fa il takeover e avvia i servizi, ma i servizi ci 
possono mettere anche diversi minuti a completare lo startup e essere 
operativi.
Es: un db Oracle che dopo il crash deve fare il replay di 20 kili di 
redo log.

 dai requisiti del sistema.
 
Io parto dal presupposto che le repliche in mysql *NON* funzionano.
Puoi configurarle bene quanto vuoi, una merda sono ed una merda restano.
Stanno in piedi con lo sputo di una vacca gravida ed alla prima query
non perfetta da parte degli utenti ti muore il cluster.
 
Pertanto, se proprio devo mettere in replica mysql, preferisco avere
qualche minuto di down necessario a spostare i dati o fare il recovery
delle tabelle, ma almeno il sistema è funzionale e *so* che funzionerà.
 
Se invece dovessi fare obbligatoriamente una replica senza disservizi
in caso di takeover, semplicemente non adotterei mysql perchè non adatto.
 
Tutto imho.


 redo log.
 
Se uno si lamenta che il restore dell'altro nodo ci mette troppo allora 
probabilmente ha sbagliato architettura.
 
Leggasi: se devi riavviare un altro nodo di oracle ed il tempo è sempre 
troppo alto, allora usa le repliche sincrone (*) che ti permettono di 
avere copie sempre consistenti... O qualche altro metodo.
 
(*) le repliche su oracle non le ho mai messe in piedi ma so che esistono.
 
N.B: tralascio mysql da ogni considerazione, essendo per le mie necessità 
poco più di un giocattolo.
 

 accesso generico a un database su un MySQL condiviso non è così facile.
 
In tal caso, e molto IMHO, diventa più affidabile far scrivere su
due db diversi e gestirne le incongruenze mediante
$LinguaggioProgrammazione piuttosto che usare le repliche.


 Per quale motivo vuoi master/master?
 
Perchè attualmente oltre alle repliche gira anche Pacemaker con corosync 
su due nodi.
Se il nodo master muore, corosync sposta l'IP sullo slave che
incomincia a scrivere sul db slave.
A questo punto, quando mi torna su il master, devo stoppare mysql,
copiare dallo slave e ripristinare la replica.
Con una config Master/Master, in stage andava tutto bene ..
ma come dicevo, con le autoincrementali "pari" e "dispari".
 
-- Yena --

 mysql-mmm in attivo/passivo e vivi (più o meno) felice.
 
Si ok Attivo passivo così non rischio chiavi duplicate e ripristino 
velocemnte .. in teoria .. :-)
Un dettaglio, in questo modo setto
log_slave_updates   = 0
 
 
-- Yena --

 consigliati
 
Ho letto ma l'esempio si riferisce a tre nodi,
con due soli nodi direi che
log_slave_updates  va a 0 ...
no ?
 
-- Yena --