Newsgroup: it.comp.os.linux.sys
Titolo: MySQL in HA

Ho la necessitï¿œ di mettere in HA due server (due vps)
MySQL usate da circa 50 server.
Non fanno molto traffico, sono sostanzialmente dei database
con delle configurazioni, piccola roba insomma.
Dubito raggiungano dimensioni superiori ai 100MB.
L'ultima volta usai le repliche master-slave (le scritture sono
di svariati ordini di grandezza inferiori alle letture) ed il
non poter scrivere su db in caso di failure del master potrebbe
essere un fattore accettabile. (potrebbe, se si puï¿œ evitare perï¿œ
sarebbe meglio).
Se c'ï¿œ una cosa che odio sono appunto le repliche, mi fanno schifo.
Instabili ai massimi, le guardi e si smontano, aggiungi un record
al db e rischi di ritrovarti con una replica saltata per dato duplicato.
Secondo voi come si puï¿œ mettere in HA un server MySQL in un modo
abbastanza sicuro ed affidabile?
Usando MySQL cluster si risolverebbe? Essendo database di piccole
dimensioni la RAM non sarebbe un problema, ma non ho mai usato tale
sistema e non ho idea di come si comporti in fase di sincronia dei
dati. Rischia di saltare ugualmente come con le repliche?
Altre idee?
Tnx.

 Dubito raggiungano dimensioni superiori ai 100MB.
Mi correggo, i due database attuali sono inferiori
ai 20 mb (tutti e due insieme) ed hanno molti dati
che non mi dovrï¿œ portare dietro sul nuovo server.
Per cui, difficilmente supererï¿œ i 20MB quando sarï¿œ
a regime.
La soluzione con MySQL cluster potrebbe essere valida?

 al db e rischi di ritrovarti con una replica saltata per dato duplicato.
Se scrivi nello slave direttamente ovvio che succede (anche se si, la 
replicazione ha le sue belle pecche).
Io proverei con Mysql Cluster 6.3 visto il tipo di database.
-- 
Vide

 Io proverei con Mysql Cluster 6.3 visto il tipo di database.
Non lo conosco affatto, è possibile che ci sia una sorta di
corruzione tra i due server? Diciamo che vorrei evitare che un
errore umano su di un server o qualche strano problema metta
fuori uso tutto il cluster come avverrebbe per le repliche.
(per errore umano non intendo la rimozione di un record, ovviamente)

 (per errore umano non intendo la rimozione di un record, ovviamente)
il cluster in HA ti da la continuità del servizio, non la "coerenza" dei 
dati (prova anche a pensare ad un raidX X>0)
per avere sempre i dati coerenti devi fare i backup.. e ripristinare 
alla bisogna
S.

 alla bisogna
Sono configurazioni "leggere-leggere" come l'elenco degli utenti
che possono fare SMTP, l'elenco delle mailbox e così via.
Non so quanto possa essere conveniente far puntare 50 server (in futuro)
allo stesso database (che per forza di cose deve essere in HA altrimenti
se muore il db mi muoiono anche tutti gli altri server) oppure salvarsi
direttamente le mappe postfix, l'elenco utenti e così via sui singoli
server. In quest'ultimo caso, se muore il db, i server avrebbero
comunque una copia testuale dei dati e non sarebbero compromessi.
Fino a poco tempo fa avevo i server che leggevano direttamente su di
essi una replica dei dati mysql. (un master che replicava direttamente
sui server impostati come slave).
Un bagno di sangue. Le repliche saltavano ad ogni minimo problema.
Ora: conviene usare file statitici e sincronizzarli tramite crontab
magari ogni 10 minuti oppure conviene far accedere direttamente i
server al database e ridondare quest'ultimo?
Io sono più per la ridondanza del db. Così facendo non dovrei
portarmi dietro 200 script di dump su ogni server che in caso di
variazioni al database sarebbero da aggiornare tutti.
Si potrebbe studiare anche una sorta di API Client-Server, ovvero
sui singoli nodi metto un singolo script in crontab che interroga
tramite una API personalizzata il database e salva i file di testo.
Lo script sui nodi non avrà alcun tipo di "logica", interroga e salva
in base a quello che gli viene sparato fuori dal server API. Così
facendo le 5 righe di bash necessarie a interrogare e salvare saranno
sempre uguali ed io potrò modificare a piacere le API da una postazione
centralizzata, senza metter mano ai singoli script.
Ma mi sembra overkill

 Altre idee?
Cosa c'e' che non ti piace nella soluzione DRBD + Heartbeat?
In pratica:
Heartbeat configurato per lanciare MySQL-Server **SOLO** sul nodo attivo
(e sul quale la partizione DRBD e' primaria e montata).
Le richieste SQL vengono mandate dai Clients ad un IP "volante",
normalmente assegnato al primario.
L'altro nodo si gratta la pancia finche' il primario non schiatta.
A quel punto, Heartbeat effettua il FailOver, sul nodo "non schiantato"
DRBD diventa primario, da secondario che era, la partizione viene montata
al volo, l'IP "volante" viene assegnato al nodo e MySQL-Server lanciato.
E' una soluzione che funziona alla perfezione, non ha problemi di sorta
con repliche che non replicano, Master/Slave che non si sincronizzano,
MySQL-Cluster che vanno a fanciulle, etc.etc.etc.
L'unico "problema" e' che, in caso di FailOver, il sistema rimane
irraggiungibile qualche secondo (con "qualche" dipendente dal numero di
servizi da migrare).
Se hai **SOLO** MySQL (e una partizione DRBD e un IP), mi sa che te la
cavi con un secondo di Down, al massimo, ma e' solo una supposizione.
Nel mio caso (con MySQL, SpamAssassin, ClamAV, Apache, Exim (2 istanze!
Mailin + Mailout), Dovecot, demone per Greylist, 3 partizioni DRBD e
svariati IP, ci mette 3-5 secondi.
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Tnx.
Assolutamente MySQL Cluster secondo me,
oltretutto data la dimensione del tuo DB.
Con il Cluster hai una soluzione assolutamente scalabile
che eventualmente puoi mettere su anche su macchine virtualizzate.
( tipo l'admin del cluster .. per non dovergli dedicare una macchina )
-- Yena --

 al volo, l'IP "volante" viene assegnato al nodo e MySQL-Server lanciato.
Tutto questo abnorme casino per un database da 20M?
Preferivo trovare soluzioni pi� pulite, magari native di MySQL.
A sto punto, sincronizzo lo slave a colpi di mysqldump ogni 5 minuti.
Tanto, 20mb, ci mette 2 secondi a sincronizzarli.
Posso benissimo creare due VPS mysql, una master, con un crontab che
ogni 5 minuti mi fa un qualcosa tipo:
mysqldump <miodb> | mysql -h <slave>
comprensivo di drop database e create table.
Se il nodo master muore, mysql dump non si connette e lo slave resta
immutato (se non si connette, non pu� nemmeno generare una drop database).
E comunque, basterebbe un IF che monitora il campo "Update_time"
di "SHOW TABLES STATUS". Se non ci son modifiche, non fa il dump.

 ( tipo l'admin del cluster .. per non dovergli dedicare una macchina )
Hai esperienze in merito?
Quanto 'ciuccia' un cluster manager? 256MB di ram bastano?

 fuori uso tutto il cluster come avverrebbe per le repliche.
in soldoni: Mysql Cluster è una soluzione shared-nothing, in cui si "spezza" 
il table space in N parti (con N pari al numero di nodi del cluster) ed ogni 
nodo ha la sua parte più una copia di backup di quella di un altro. Il dato 
si considera scritto quando è stato replicato in tutte le varie partizioni.
http://www.mysql.com/products/database/cluster/
-- 
Vide

 degli slave, e poi rimetti su il vecchio master a mano.
Ho un server master con due repliche.
Mysql 4.
Ogni volta che mi crasha il master (vuoi per problemi hardware, vuoi per
altri problemi) le repliche si spaccano.
Riavvio il master, le repliche non ripartono vuoi per dati duplicati,
vuoi per log fuori posizione e così via.
1 settimana fa ho perso mezza giornata abbondante a ripristinare una
replica dopo un crash del server. (si è imbarcato ed ho dovuto spegnere
brutalmente la macchina)

 brutalmente la macchina)
Non so che dirti, a me è già morto qualche volta il mysql master e quando si 
ritira su il processo gl islave non battono ciglio.
I problemi più grossi che ho visto è quando si interrompono manualmente 
INSERT che pescano dati da SELECT, e questo rompe abbastanza il cazzo. Ma 
credo sia un bug della 5.0.x che ho installata nel master (devo aggiornarla)
-- 
Vide

 4? 4.0? 4.1? o è un typo e volevi dire 5?
Domanda di riserva?
E' una versione da museo, credo MySQL 4.0 sul master
e mysql 5 sugli slave.
(non fare commenti, il master è una slackware vecchissima, aggiornarla 
significa formattare :-) )

 Preferivo trovare soluzioni pi� pulite, magari native di MySQL.
Beh, e' una scelta tua...
Finora tutti quelli che ho visto che hanno usato soluzioni "piu' pulite,
magari native di MySQL" hanno sempre avuto problemi di tutti i tipi...
Io giochero' anche sporco, anche se i Cluster li han sempre fatti cosi',
ma almeno funziona tutto come un orologio svizzero...


 Secondo me, hai delle idee un po' strane... :)
Mi fa strano dover usare un fs replicato via rete quando a breve avr�
una san.
La ridondanza del server la ottengo migrando le VM da un nodo all'altro
tramite livemigration, ma questo non mi tutelerebbe da problemi lato
software del nodo. Anche migrandolo, mi sposterei i problemi dal server
A verso il server B.
Un database di 20mb si replica bene anche con mysqldump, non avendo
necessit� di avere i dati replicati in tempo reale.
Meno sbattimenti e pi� scalabilit�, dato che se un giorno volessi
avere un terzo nodo mi basterebbe copiare il dump anche li.
Soluzione strana, ma efficace, imho.

 Soluzione strana, ma efficace, imho.
E che? Heartbeat 2 gestisce solo due nodi? La limitazione dei due nodi, da
HA2 in poi, la hai solo ed esclusivamente se usi DRBD.
Hai detto che hai una SAN? Bene! Metti li i dati e configura HA2 con un IP
e MySQL. Quando aggiungi un nuovo Server verra' messo anche lui nella
lista dei Servers e se i primi si schiantano, prima o poi tocchera' anche
a lui!


 Tanto, 20mb, ci mette 2 secondi a sincronizzarli.
Nah.
Se googli c'è qualche howto su mettere due mysql in multi master.
Si tratta di sminchiettare un pò con le configurazioni, impostare 
l'incremento degli autoincrementanti in maniera opportuna e alla fine 
ottieni ciò che vuoi.
Non usare soluzioni pecorecce, che di pecorai nel campo ce ne sono già 
troppi
Max

 troppi
Lo so, ma come scritto sopra, son rimasto scottato in precedenza
con le stupide repliche. Le odio, mi fanno schifo, sono rivoltanti.
E vorrei evitare.
Però se voi mi dite che con mysql 5.0 (quello di debian) la situazione
è migliorata, potrei anche sparare un master-master, così già che ci
sono faccio un bel bilanciamento con keepalived.
Faccio puntare tutti i server all'ip virtuale di keepalived e son felice.
(Mi resta da capire se il dump da MySQL a file di testo per le config
mi serva realmente oppure no. Senza dump, ci metto poco ad implementare
il tutto. Con il dump la faccenda si complica non poco.)

 ottieni ciò che vuoi.
Sono d'accordo. Attualmente ho 4 coppie di macchine configurate in
multimaster e fin'ora (SGRAT) non ho mai avuto problemi. In fase di test
li abbiamo abbastanza massacrati (reboot, kill del pid, staccato i cavi
di rete) e non abbiamo mai avuto problemi.
Oltretutto la soluzione mysql cluster, dato che il db dell' OP è molto
piccolo, non so se conveniente, dato che occorrono almeno 3 macchine, 4
per la piena ridondanza.

 a lui!
Per� cos� facendo se mi schiatta un MySQL e mi corrompe i dati, l'altro
nodo parte e si trova i dati corrotti dal server precedente.

 Faccio puntare tutti i server all'ip virtuale di keepalived e son felice.
Ecco, questo è un test che non ho provato a fare. Noi lo usiamo con
HeartBeat, in failover. Però sarebbe un interessante esperimento, che a
priori dovrebbe funzionare.

 priori dovrebbe funzionare.
Sono le 16:28, se riesco ti faccio sapere tra una mezzora.
Installo una seconda vps, butto su la replica e keepalived poi
ti dico, così magari facciamo qualche test...

 nodo parte e si trova i dati corrotti dal server precedente.
Non solo.
Anche il filesystem � lo stesso..
-- 
http://bofhskull.wordpress.com/

 sono faccio un bel bilanciamento con keepalived.
A sto punto installati direttamente un 5.1 di dotdeb e fai prima, se è 
un'installazione nuova. Ha poco senso installare ora una 5.0 ex-novo.
-- 
Vide

 un'installazione nuova. Ha poco senso installare ora una 5.0 ex-novo.
No no, dotdeb resta dov'è.
Ha non pochi problemi (come l'upgrade di un pacchetto, dopo 2
ore il downgrade forzato che però non downgrade le librerie).
Direi che può restare dov'è. Sono due server piccoli ma vitali.
Van giù quelli van giù tutti.
Del 5.1 c'è comodo il partizionamento, ma partizionare 20mb
non ha senso.

 Anche il filesystem � lo stesso..
Quindi convieni con me che non � il massimo
fare heartbeat+mysql con i dati replicati via
drbd (o stessa lun sulla san) ?
Tu come ti porti dietro le tabelle di postfix?
Fai dei dump testuali?

 Tu come ti porti dietro le tabelle di postfix?
Ho una coppia di sistemi in heartbeat su storage condiviso.
Son su da 4 anni e non mi han mai dato problemi.
Dovendoli rifare, penso andr� sul multimaster, pi� che altro per poter 
distribuire il carico (che � poco, in termini computazionali, ma son 
parecchie query e prima o poi anche mysql inizia a ruttarmi dietro)...
-- 
http://bofhskull.wordpress.com/

 parecchie query e prima o poi anche mysql inizia a ruttarmi dietro)...
Carico solo in lettura, chiariamo, prima che qualcuno pensi che il MM serva 
per scalare in scrittura (errore comune).
-- 
Vide

 priori dovrebbe funzionare.
Sembra funzionare, ma in parte.
VRRP va su, ed il nodo master si prende l'IP virtuale.
il cluster va su correttamente con entrambi i nodi dentro:
# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  
1.2.3.100:3306
 wlc persistent 60
   -> 
1.2.3.101:3306
           Local   100    0          0
   -> 
1.2.3.102:3306
           Route   100    0          0
ed infatti riesco a connettermi a mysql tramite ip virtuale:
$ mysql -u root --password=<pass> -h 1.2.3.100 -e \
"SHOW VARIABLES WHERE Variable_name = 'Hostname';"
+---------------+---------------------+
| Variable_name | Value               |
+---------------+---------------------+
| hostname      | <mio_hostname1>     |
+---------------+---------------------+
Ma se uccido il mysql del nodo master, il nodo morto esce dal cluster,
come è giusto che sia:
# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  
1.2.3.100:3306
 wlc persistent 60
   -> 
1.2.3.102:3306
           Route   100    0          0
Ma non mi connetto più al server rimasto:
$ mysql -u root --password=<pass> -h 1.2.3.100 -e \
"SHOW VARIABLES WHERE Variable_name = 'Hostname';"
ERROR 2003 (HY000): Can't connect to MySQL server on '1.2.3.100' (111)
mentre riesco, ovviamente, a connettermi direttamente al server:
$ mysql -u root --password=<pass> -h 1.2.3.102 -e \
"SHOW VARIABLES WHERE Variable_name = 'Hostname';"
+---------------+------------------+
| Variable_name | Value            |
+---------------+------------------+
| hostname      | <mio_hostname2>  |
+---------------+------------------+
che diavolo può essere?

 Son su da 4 anni e non mi han mai dato problemi.
Quindi vai a leggere direttamente dentro il database con i
singoli servizi o ti dumpi le config?

 Si, so come si fa, ma ho il *terrore* delle repliche di mysql.
Io ho il terrore di mysql.
Ho avuto BRUTTISSIME esperienze dal 4 in poi.
Il 3.X era l'unico veramente roccioso.
Ora uso felicemente Postgres, fa il suo sporco lavoro e probabilmente lo fa 
più velocmente di mysql (sicuramente faccio query che mysql non osa nemmeno 
parsare...).
Non ha le repliche ma... st1c4tz1...
drbd + hartbeat + failover ed in 15 secondi ho il backup online.
Max

 Il 3.X era l'unico veramente roccioso.
Confermo, ma devo dire che le mie brutte esperienze con
le repliche si son verificate in configurazioni 'strane'
e molto particolari come un master del dopoguerra (4.0.X
e mai aggiornato) che replicava su due slave con versioni
differenti (una 4.0.X ed una 5.0.x o 4.1, non ricordo)
Se riesco a far funzionare ipvs, che a quanto pare mi
sta dando problemi con il routing e non capisco il perchè,
proverò a dare una seconda possibilità a mysql con una
replica master-master (che attualmente funziona, è il
bilanciatore che mi da noie)


A volte la prima e a volte la seconda. Dipende solo se il servizio 
supporta il lookup diretto su SQL o no.
Se posso, uso SQL.
-- 
http://bofhskull.wordpress.com/

 Non ha le repliche ma... st1c4tz1...
Non so niente tranne quello che ti scrivo qui: ho letto che c'era un 
progetto in lavorazione per fare un "cluster" postgres con replica master-
master online.
Prova a cercare sul sito di postgres.
Non so se fossero patch al motore o un'estensione installabile.
Bye.

 ERROR 2003 (HY000): Can't connect to MySQL server on '1.2.3.100' (111)
A 'sto punto è diventata una sfida personale.
*DEVO* far funzionare 'sto baraccone anche se in realtà mi
basterebbe implementare solo il multimaster mysql (che ho già
implementato). Almeno per imparare una cosa nuova. :-)
Allora, ho keepalived installato su entrambi i server mysql.
l'ip transita da un nodo all'altro in caso di failure.
keepalive gestisce correttamente anche i membri del cluster
rimuovendo il nodo con il mysql morto.
Problema:
se mi collego al mysql primario, ovvero quello attivo sul bilanciatore
attivo, tutto funziona (l'ip di mysql corrisponde con quello del 
bilanciatore).
Se invece mi collego al mysql secondario, passando dal bilanciatore
presente sull'altro server (come in caso di problemi a mysql e non
al server stesso), non funziona una cippa, non mi connetto proprio.
Eppure con tcpdump vedo correttamente il traffico in ingresso ed in
uscita dal nodo mysql secondario.
Vedo come sorgente il mio IP (quello del mio gateway) e come
destinazione l'ip del bilanciatore, il quale fa il redirect al
nodo mysql.
La risposta è analoga: sorgente = ip bilanciatore, destinazione =
mio gateway.
E' probabile però che il mio gateway/firewall faccia a cazzotti vedendo
una risposta per un pacchetto destinato a 1.2.3.100 (il bilanciatore)
proveniente da 1.2.3.102 (l'ip del mysql) e quindi blocca il traffico
non essendo "related" o "established".
Skull tempo fa postò una regola di nat per risolvere questa problematica.
Non funziona:
/sbin/iptables -A PREROUTING -t nat -d 1.2.3.100 -j DNAT 
--to-destination 1.2.3.102

 --to-destination 1.2.3.102
Questa ha senso solamente se il bilanciamento viene effettuato in 
*direct routing*.
Cosa stia facendo tu non l'ho capito.. :-P
-- 
http://bofhskull.wordpress.com/

 Cosa stia facendo tu non l'ho capito.. :-P
Direct Routing.
E' quello il problema, con nat dovrebbe essere più semplice ma non
voglio incasinarmi con le nic virtuali avendo due server 'diversi' e
non in un unico pool, non voglio incasinarmi.
Preferisco DirectRouting e capire come mai non
funziona il mio sistemino.
La richiesta la faccio verso l'ip virtuale, e tshar sul nodo mysql
mi mostra una risposta proveniente da ip virtuale ma a quanto pare
il mio firewall lo blocca e non so perchè:
   0.000000 <MIOIP> -> 1.2.3.100 TCP 37779 > mysql [SYN] Seq=0 Win=5840 
Len=0 MSS=1460 TSV=66281544 TSER=0 WS=7
   0.000006 1.2.3.100 -> <MIOIP> TCP mysql > 37779 [SYN, ACK] Seq=0 
Ack=1 Win=5792 Len=0 MSS=1460 TSV=887412 TSER=66281544 WS=5
il mio ip interroga 1.2.3.100 (ip virtuale del bilanciatore in DR), il
bilanciatore ruota sul nodo mysql (infatti il tshark di cui sopra è
preso direttamente dal realserver) il quale risponde con l'ip del
bilanciatore.
Non so quanto sia corretto.....

 bilanciatore.
In tal caso *deve* transitare, purchè il realserver stia correttamente 
trattando come locale la destinazione 1.2.3.100.
Quella regola di iptables che riporti è da mettere sul realserver 
proprio con quel senso.
Hai forse un qualcosa che si incazza se il MAC di 1.2.3.100 non 
corrisponde a quello annunciato via ARP-reply? (perchè, in tal caso, 
direct-routing non funzionerà mai...)
PS: Ovviamente, il bilanciamento fatto in quel modo puoi farlo solamente 
se su mysql fai solo SELECT e nessuna scrittura, ma ciò non toglie che 
il tutto dovrebbe funzionare: magari ti sfascia il DB alla seconda 
INSERT, ma funziona ;-).
-- 
http://bofhskull.wordpress.com/

 INSERT, ma funziona ;-).
Perchè? Con un multimaster posso bilanciare anche le insert, che saranno
replicate ugualmente su entrambi i nodi.
Dove becco becco, cambia poco se scrivo sul master 1 o sul master 2.
Comunque sia, il 99% delle query saranno SELECT per cui è un problema
che non si pone. Le insert saranno fatte o da un pannello su una VPS
esterna per cui posso selezionare il master a piacere.
Ma non ne vedo il problema, perchè non potrei bilanciare le insert?
(non tanto come performance, ma piuttosto come failover automatico)

 Dove becco becco, cambia poco se scrivo sul master 1 o sul master 2.
No. Perchè in multimaster non hai un meccanismo di locking globale tra i 
master. Se due insert arrivano su due nodi diversi in tempi 
sufficientemente stretti (la seconda INSERT arriva prima che il nodo che 
ha ricevuto la prima abbia avuto il tempo di aggiornare gli altri) puoi 
facilemente avere problemi di chiavi duplicate (se poi hai campi 
autoincrementali è sicuro).
-- 
http://bofhskull.wordpress.com/

 autoincrementali è sicuro).
ma gli incrementali sono sfalsati.
Il nodo due ha come autoincrement:
1,3,5,7...
il nodo due invece ha come autoincrement:
2,4,6,8...
Per cui, se due query si accavallano, quella che arriva nel primo nodo
imposterà un autoincrement dispari, quella che arriva sul secondo
imposterà una autoincrement pari.

 imposterà una autoincrement pari.
Il che non sposta il problema se hai tabelle con chiave diversa 
dall'incrementale...
Questo, comunque, lo sai tu...
Se il problema potenziale è reso impossibile a monte, meglio per te...
-- 
http://bofhskull.wordpress.com/

 aggiungere ugualmente il VIP alla loopback.
Allora c'è qualcos'altro che non va, fidati: uso 'sto metodo da anni sui 
miei sistemi (almeno dove è possibile usarlo)...
Controlla dmesg: sicuro non ci sia -per dire- rp_filter che si incazza?
-- 
http://bofhskull.wordpress.com/

 Questo, comunque, lo sai tu...
Dunque, supponendo di avere un indice univoco sulla colonna X (non auto
increment).
Server1 scrive "CIAO" nella colonna X contestualmente al server2.
Uno dei due server darà errore, ovvero quello che ha scritto un
nanosecondo dopo l'altro.
In tal caso, la query muore con un errore.
Supponiamo di avere un solo server:
server 1 scrive "CIAO".
tutto ok.
server 1 scrive di nuovo "CIAO"
la query muore.
Non cambia niente. In entrambi i casi, ovvero monoserver o multimaster
avrai una query in errore.
Il problema si potrebbe avere con gli autoincrement, ovvero io inserisco
un record sul server1, prendo l'ID 100, poi inserisco un nuovo record
non univoco sul server2, prendo sempre l'ID 100 ed in tal caso mi muore
una query che teoricametne sarebbe legittima. Il problema infatti è
della configurazione del server, non della query.
Questa problematica è risolta dagli indici con offset diverso.
L'altra problematica è un problema di query (ovvero un problema del
programmatore), il server ha poco a che fare, se gli arriva un dato
doppio sia che tu abbia un server o 157 in multimaster, il dato è
comunque errato.

 Controlla dmesg: sicuro non ci sia -per dire- rp_filter che si incazza?
No.
# dmesg | grep -ic rp_fi
0

 In tal caso, la query muore con un errore.
No.
La query di INSERT viene accettata, perchè il server su cui la stai 
eseguendo non ha nessun "CIAO", ancora.
Quando l'altro master glielo invierà, insieme ai dati che fanno parte 
del record relativo a quella INSERT, *quella* query morirà, e da quel 
momento in avanti i due master avranno la base dati disallineata.
-- 
http://bofhskull.wordpress.com/

 Nei realserver hai impostato solo e soltanto tale regola?
Sostanzialmente, sì.
-- 
http://bofhskull.wordpress.com/

 momento in avanti i due master avranno la base dati disallineata.
Non se metto INSERT IGNORE però.
In tal caso dovrebbe starsene zitto zitto anche in caso di replica
proprio come se fosse una insert fatta su singolo server.
Non fa la query e bon, però non so che effetto abbia una INSERT IGNORE
su un database replicato.
(e nel 99% dei casi i miei script son tutti INSERT IGNORE)

 Sostanzialmente, sì.
Porco mondo, a me non va.

 Non se metto INSERT IGNORE però.
Non cambia una fava...
-- 
http://bofhskull.wordpress.com/

 Non cambia una fava...
Si in effetti non cambierebbe niente.
Allora a questo punto conviene usare mysqlproxy e HB.
Non ci saranno query duplicate, ma alla notte non vorrei
essere svegliato.
Ma *prima* devo far funzionare il directrouting, o almeno
capire cosa c'è che non va.

 Controlla dmesg: sicuro non ci sia -per dire- rp_filter che si incazza?
Non c'è verso di far funzionare un bilanciatore in Direct Routing.
Anche sul sito di LVS ho letto una soluzione analoga con redirect
e non parlando di nessuna configurazione particolare, si fare il routing
con iptables e via........ *NON VA*
Ne con il VIP in locale e arp_filter ne con il redirect.
Se invece interrogo direttamente il server senza passare dall'ip
virtuale tutto funziona.
(eppure le risposte le vedo uscire, per cui il bilanciatore inoltre
il traffico al worker correttamente, è il worker che non sa come
rispondere)

 Quanto 'ciuccia' un cluster manager? 256MB di ram bastano?
Io l'ho messo su con 300 e rotti ma direi che bastano anche 256..
dipende dai servizi attivi nella distro che lo ospita naturalmente.
-- Yena --

 dipende dai servizi attivi nella distro che lo ospita naturalmente.
Ci sarebbe solo MySQL ed eventualmente keepalived.
Ma adesso ho un altro problema che *devo* risolvere: far funzionare
il directrouting, non capisco cosa possa essere, ï¿œ da questa mattina
che ci son dietro.

 Non so se fossero patch al motore o un'estensione installabile.
Ho preso cybercluster (postgres patchato),ho portato la patch sull'8.3, ho 
creto i .debs.
Lo ho in test da circa 4 mesi e ci rimarrà altrettanti se non trovo il tempo 
di provarlo a fondo :-D
Max

 con iptables e via........ *NON VA*
Allora, loggando sul mio firewall con tshark ho notato che:
a) non mettendo la regola di nat, il mio PC invia un SYN però la
risposta non torna mai indietro, giustamente.
b) mettendo la regola di nat, il mio PC invia un SYN, il realserver
risponde con un bel SYN,ACK, al quale il mio PC cerca di rispondere
con un ulteriore ACK.
Quest'ultimo ACK però non viene visto dal realserver tant'è che il
mio PC continua ad inviare ACK su ACK e tshark li segnala come Dup.
Da quì in poi, buio totale.
Per cui il problema dovrebbe essere sul realserver ma:
1) iptables -I INPUT -j LOG non indica nulla.
2) io non filtro sugli stati, per cui se passa il primo SYN dovrebbe
passare anche l'ACK.
3) ho provato anche mettendo tutte le catene in ACCEPT.
Non cambia niente.

 Per cui il problema dovrebbe essere sul realserver ma:
Invece a me fa pensare che il director vada in pappa perchè non vede la 
sessione completa...
-- 
http://bofhskull.wordpress.com/

 sessione completa...
A che punto il traffico viene ruotato verso il realserver?
Alla fine dell'handshake? Quindi il mio l'ACK potrebbe essere
massacrato dal director?

 massacrato dal director?
'fanculo.
fanculo al "--syn" sul director.
L'unico punto che non ho mai controllato.

 sessione completa...
Yeah! Grazie della dritta!

 massacrato dal director?
Syn:
  Client -> Director (L2)
  Director -> Realserver (L2)
Syn/Ack:
  Realserver -> Client (L2)
Ack:
  Client -> Director (L2)
A questo punto il Director dovrebbe correlare questo Ack con il Syn di 
sopra, e fargli fare la stessa strada.
Se non è in grado di farlo (es1: non ha tenuto traccia; es2: un 
conntrack a caso lo sega, perchè non avendo visto passare il Syn/ack 
considera la sessione "rotta"), accade quel che vedi...
-- 
http://bofhskull.wordpress.com/

 fanculo al "--syn" sul director.
Eh...
-- 
http://bofhskull.wordpress.com/

 considera la sessione "rotta"), accade quel che vedi...
Chiarissimo. Tnx.

 Non ha le repliche ma... st1c4tz1...
Slony-I ?
Comunque, l'unico che trovo comodo da questo punto di vista e` Firebird,
in cui le repliche shadow sono native e per le repliche master/slave hai
a disposizione un bel po' di tool (almeno da quello che mi ricordo)
Enrico

 significa formattare :-) )
La replicazione Mysql 5.x -> 4.x notoriamente fa casino. Il contrario non 
saprei, ma non escluderei che i tuoi guai derivino da questo. 
Personalmente (5.1 -> 5.1) non ho mai avuto problemi in caso di 
spegnimento del master. 
Nella peggiore delle ipotesi però ti basta avere un dump ragionevolmente 
recente del master realizzato con l'opzione --master-data=1 . Pialli lo 
slave, ci butti dentro il dump, riattivi la replicazione ed attendi che 
lo slave si ri-allinei.
M

 lo slave si ri-allinei.
Uhm, non conoscevo l'opzione "--master-data".
Proverò a vedere cosa succede.