MySQL 5.4

[ceccus]

Salve,
Con Near Real Time si intende un qualcosa che non è aggiornato in sincrono (quindi in transazione), ma differito, dove il "differimento" è praticamente trascurabile ... MQ descrive bene questo concetto ...
Ovviamente, nel caso descritto, o chi controlla, si accorge quasi in tempo reale del tentativo, oppure, già se il controllo lo faccio 5 minuti dopo, potrebbe già essere tardi ...
Sia Oracle che DB2, poi, mettono a disposizione una serie di API che consentono di accorgersi se la replica ha dei problemi e che tipo di problemi per porre gli opportuni interventi del caso ... mi immagino che anche MySQL ...

Ciao !!

[guest]

Ma se ti accorgi del tentativo cosa fai blocchi la transazione e notifichi l'utente?
Se si, in che modo puoi bloccare una transazione che è già stata scritta sul master, se te controlli sullo slave? Anche se hai 1 millisecondo di differenza, prima di arrivare sullo slave la transazione è già stata effettuata sul master.

Per i meccanismi di controllo delle repliche, mysql è veramente stupido da questo punto di vista.
Se una query sul master va a buon fine e sullo slave no, lo slave ti muore ed il master non si accorge di niente e continua imperterrito a scrivere. In pratica o ti accorgi in fretta che gli slave son morti o ti ritrovi in men che non si dica con una replica fuori sincrono anche di parecchio.
Tra l'altro, un ulteriore aspetto negativo è che se lo slave dovesse morire, mysql non lo "isola" ma continua a rispondere.

Esempio:

pippo = "pluto" e repliche sincronizzate.
sul master faccio un update di pippo = "paperino", il master va OK, lo slave da errore per qualche motivo, la query fallisce, la replica muore.

le interrogazioni successive, sullo slave riporteranno "pippo" anzichè "pluto".
Sarebbe fondamentale, secondo me, implementare un meccanismo di protezione. Se la replica sullo slave muore, lo slave dovrebbe morire, piuttosto che rispondere con dati quasi certamente errati.

lato software è più facile gestire un nodo morto, che un nodo con dati fuori sincrono. è insensato, prima di ogni query, verificare lo status della replica, mentre invece fare il fallback sul master è veramente semplice a livello di php. (tipo 3 righe di codice)

giusto per rendere l'idea....

[ceccus]

Salve,
NO ... non hai capito l' esempio ... evidentemente l'ho spiegato male ... riprovo ...
Allora, lo scenario è questo ... base dati relativa all' Home Banking ... per esempio ... il DB principale è quello dove gli utenti fanno quello che devono fare ... la replica è il DB dove agisce il sistema di Fraud Detenction ... Qaundo la transazione è terminata sul DB principale ... è terminata ... punto.
L' utente si è già "sganciato" ... qualche millisecondo dopo, quello che ha fatto l' utente è registrato anche sul DB replica ... a disposizione del software specialistico ... quindi, se la replica si ferma, quello che ne risente è il sistema di Fraud Detenction ... e non assolutamente l' operatività ordinaria ... ecco perchè si agisce solitamente in questo modo ... puoi mettere tutti i cluster che vuoi (Oracle ha RAC), ma se un instanza di DB non ti risponde, non ti risponde e magari si è piantato perchè il sistema di rilevazioni frodi esegue query pesanti ... In quest'altro modo ... il sistema principale non si pianta (Home Banking) , a meno di altre problematiche, ma sicuramente non si appesantisce con il carico dovuto all'altro software ... ecco che le repliche di DB in near real time, stanno diventando sempre più una problematica sentita, almeno in certi ambiti.

Ciao !!

[ceccus]

Salve,
Per il discorso blocchi ... posso fare tante cose ... posso bloccare l' IP ... posso bloccare il suo account, posso bloccare gli eventuali conti che vengono movimentati ... NON sempre , dietro alle frodi, c'è un umano ... anzi, quasi mai ... c'è sempre altro software ... per cui, accorgersi che è in atto una truffa, magari ti fa perdere i primi "eurini" ... ma se blocchi in tempo, ti fa risprmiare tutti gli altri ...

Ciao !!

[guest]

L' utente si è già "sganciato" ... qualche millisecondo dopo, quello che ha fatto l' utente è registrato anche sul DB replica ... a disposizione del software specialistico ... quindi, se la replica si ferma, quello che ne risente è il sistema di Fraud Detenction ... e non assolutamente l' operatività ordinaria ... ecco perchè si agisce solitamente in questo modo ... puoi mettere tutti i cluster che vuoi (Oracle ha RAC), ma se un instanza di DB non ti risponde, non ti risponde e magari si è piantato perchè il sistema di rilevazioni frodi esegue query pesanti ... In quest'altro modo ... il sistema principale non si pianta (Home Banking) , a meno di altre problematiche, ma sicuramente non si appesantisce con il carico dovuto all'altro software ... ecco che le repliche di DB in near real time, stanno diventando sempre più una problematica sentita, almeno in certi ambiti.

Ciao !!

Ora ho capito.
per il cui il sistema antifrode non ha alcuna comunicazione con l'utente, l'utente fa quello che deve fare, poi voi controllate per i fatti vostri le frodi ed eventualmente prendente provvedimenti, ma l'antifrode non comunica con l'utente. mi sfuggiva questo passaggio.

[DonChisciotte]

uhm... non capisco bene: se su uno dei nodi slave in replica "real time" avviene una query pesante, dovrebbe essere solo il singolo nodo a risentirne e non tutto il pool, altrimenti viene meno la necessita' di suddividere il carico su piu' macchine. o sbaglio?

in ogni caso la replica asincrona serve solo in situazioni particolari, tipo appunto quando c'e' da fare un'analisi sulle transazioni effettuate.

@guest:
tornando a postgresql, ci sono vari tipi di fare le repliche, sincrone ed asincrone e non si rompono cosi' facilmente come quelle di mysql, dove una duplicate entry fa morire la replica (senza, come hai detto tu, far morire lo slave stesso). inoltre ci sono dei metodi per effettuare le repliche in cascata: ipotizziamo di avere 5 server dislocati in 2 server farm;
- master e slave1 connessi tra di loro in lan
- master e slave2 connessi via wan/vpn
- slave2 e slave2.1/2.2 connessi tra di loro in lan

master replica su slave1 e slave2, mentre slave2 replica su slave2.1 e slave2.2, minimizzando cosi' il traffico tra farm1 e farm2 (invii i dati solo per una replica e non per tre repliche).

due tool importanti per le repliche su pgsql sono slony e pgpool.

my 2 cents.

[guest]

uhm... non capisco bene: se su uno dei nodi slave in replica "real time" avviene una query pesante, dovrebbe essere solo il singolo nodo a risentirne e non tutto il pool, altrimenti viene meno la necessita' di suddividere il carico su piu' macchine. o sbaglio?

Se non erro Ceccus stava parlando del singolo nodo, non di tutto il pool.
Facendo una query pesante, al massimo ti muore lo slave e gli utenti non si accorgerebbero di niente, dato che interrogano direttamente il master.

tornando a postgresql, ci sono vari tipi di fare le repliche, sincrone ed asincrone

Ho letto bene? Sincrone? Ovvero repliche atomiche?
Dammi un link, ti prego

e non si rompono cosi' facilmente come quelle di mysql, dove una duplicate entry fa morire la replica (senza, come hai detto tu, far morire lo slave stesso).

Non so a voi, ma a me sembra una lacuna la non possibilità di far morire lo slave in caso di replica persa.
Sarebbe un utile flag di configurazione, secondo me, anche perchè nel 99% dei casi si fanno repliche per bilanciare il carico ed avere ridondanza, se la replica muore e va fuori sincrono, il carico ovviamente non lo puoi più bilanciare altrimenti risponderesti con dati errati e la ridondanza non servirebbe più a nulla, dato che se morisse il master, tu avresti i dati sballati. Tanto vale far morire il nodo per intero e di certo non rispondi male alle query.

[DonChisciotte]

Ho letto bene? Sincrone? Ovvero repliche atomiche?
Dammi un link, ti prego

pgpoolII, al contrario di Slony-I, offre la possibilita' (tra le altre cose, come il load balancing o le query parallele) di effettuare una replica realtime.
ora non so tu cosa intenda per replica atomica - che tu accomuni a replica sincrona - ma per me sincrona e realtime hanno lo stesso significato (e puo' darsi che mi stia sbagliando di grosso, ma ammetto la mia lacuna a riguardo).

Non so a voi, ma a me sembra una lacuna la non possibilità di far morire lo slave in caso di replica persa.
Sarebbe un utile flag di configurazione, secondo me, anche perchè nel 99% dei casi si fanno repliche per bilanciare il carico ed avere ridondanza, se la replica muore e va fuori sincrono, il carico ovviamente non lo puoi più bilanciare altrimenti risponderesti con dati errati e la ridondanza non servirebbe più a nulla, dato che se morisse il master, tu avresti i dati sballati. Tanto vale far morire il nodo per intero e di certo non rispondi male alle query.

indubbiamente e' una cosa sfavorevole e forse non si era capito dalla mia frase; la mia esperienza con le repliche di mysql e' stata abbastanza brutta e un po' perche' mysql e' una scelta aziendale, un po' perche' la maggior parte dei software sviluppati sono pensati per funzionare con mysql, non c'e' verso di far cambiare rotta, nemmeno per i nuovi progetti.
ti porto la mia esperienza piu' calzante: presso un cliente ci sono delle macchine con mysql che fanno da db per un'applicazione (in php) per la gestione dei risultati e delle classifiche di vari campionati sportivi.
ovviamente le repliche si rompono di domenica, essendo il cliente in questione un'agenzia di stampa (fanno i tabellini per vari quotidiani), e spesso mi chiamano (nagios manda le mail oltre che a me anche a chi tra i miei colleghi e' li' a fare l'assistenza) per riparare il db: cio' vuol dire farli fermare per una 20ina di minuti, il che vuol dire soldi (se le pagine con i tabellini arrivano in ritardo, in teoria ci sono le penali da pagare).
i log mi dicevano sempre la stessa cosa: duplicate entry. la cosa e' stata risolta (non so come, ma sono felice) da uno dei nuovi sviluppatori, correggendo delle funzioni nell'applicazione.

purtroppo mi rendo conto che mysql e' la piattaforma piu' utilizzata dai vari CMS - sebbene ormai i piu' diffusi siano in grado di usare tranquillamente pgsql - e quindi si e' un po' costretti ad usarlo, e non resta altro che monitorare costantemente il tutto e iniziare a proporre ai clienti l'utilizzo di postgresql (magari le soluzioni di hosting tipo plesk o cpanel hanno delle opzioni per farlo gia' in modo trasparente).

ciao

[guest]

pgpoolII, al contrario di Slony-I, offre la possibilita' (tra le altre cose, come il load balancing o le query parallele) di effettuare una replica realtime.
ora non so tu cosa intenda per replica atomica - che tu accomuni a replica sincrona - ma per me sincrona e realtime hanno lo stesso significato (e puo' darsi che mi stia sbagliando di grosso, ma ammetto la mia lacuna a riguardo).

Per atomica intendo una replica in cui la query sul master termina solo quando tutti gli slave hanno terminato con successo la query. In pratica, l'operazione sul master si considera terminata solo quando son terminate tutte le operazioni sullo slave, senza possibilità che qualche d'uno si "infili" in mezzo e spacchi l'operazione. Diventa in sostanza "un blocco unico" master-slave.

E per forza di cose, una replica atomica è anche realtime.
In pratica atomico comporta il realtime dato che l'operazione non può terminare finchè gli slave non han terminato, il realtime però non comporta l'atomico.

Confermo, come te, la rottura delle repliche di domenica.

[guest]

ok per pgpool2, ma sarebbe una sorta di mysql-proxy.
Se lo installo sul master e muore il master, io non mi connetto più agli slave.
Se lo installo su due o più server, devo avere sicuramente un servizio esterno che mi attiva pgpool nel caso il master muoia, come ad esempio keepalived. In pratica l'HA va comunque configurato sui nodi con pgpool installato.

Pensavo invece fosse una configurazione integrata di postgresql che una volta attivata la replica tra due nodi, pensava lui a tutto come se avesse una sorta di heartbeat integrato.

[DonChisciotte]

ok per pgpool2, ma sarebbe una sorta di mysql-proxy.
Se lo installo sul master e muore il master, io non mi connetto più agli slave.
Se lo installo su due o più server, devo avere sicuramente un servizio esterno che mi attiva pgpool nel caso il master muoia, come ad esempio keepalived. In pratica l'HA va comunque configurato sui nodi con pgpool installato.

Pensavo invece fosse una configurazione integrata di postgresql che una volta attivata la replica tra due nodi, pensava lui a tutto come se avesse una sorta di heartbeat integrato.

no, purtroppo non e' integrato in postgresql, ma un framework sviluppato appositamente per aggiungere determinate funzionalita' (simili ma non uguali a quelle di mysql-proxy); attualmente non credo esista una soluzione integrata per il failover dei db che sia software libero (mi pare che oracle faccia una cosa simile con rac), quindi bisogna pensare a come mettere in failover pgpool-II.
per quanto riguarda le repliche atomiche la documentazione di pgpool-II non ne parla affatto, in effetti la documentazione a riguardo non e' granche'. bisognerebbe scrivere in una loro mailing list (se esiste) o agli sviluppatori per avere notizie piu' dettagliate a riguardo.

ciao e buonanotte

[ceccus]

Salve,
Attenzione comunque a non confondere fra Cluster di DB e Replica ... sono 2 cose completamente differenti ... anche se , a prima vista possono sembrare molto simili ...
Per esempio, per il Clustering , Oracle ha RAC (Real Application Clusters), per la Replica, Oracle ha Stream ...

Ciao !!

[guest]

Che cosa intendi te per clustering di DB?

[ceccus]

Salve,
Allora, la risposta non è semplice ... anche perchè i maggiori produttori di DB , hanno implementazioni molto diverse fra loro della tecnologia "cluster" ...
Direi di concentrarsi sul Discorso Oracle , per tanti motivi, non ultimo il fatto che MySQL sembra sia finito sotto le "grinfie" della Oracle stessa ... con tutte le acquisizioni che ha fatto e che devono ancora essere perfezionate ...
Cominciamo a dare alcune precisazioni : quando parlo di DB , non intendo il Database come dati ... intendo il motore che li governa ...
Questo vuol dire che per un Cluster di DB ,a uno o più nodi, solitamente si intende che una o più istanze di DB (inteso come motore) girano in Server collegati fra loro in LAN , ad alta velocità, in alta affidabilità e le quali istanze, sono in grado di condividere gli stessi files (alias Dati) ... ovviamente, la memoria è indipendente per ciascuna macchina ... poi Oracle, per esempio, con la sua Tecnologia RAC, ha introddotto una "cache orizzontale" che ne massimizza le performances e riduce al minimo (bada bene, non elimina, riduce al minimo) la "non consistenza" del dato ... cosa che per una transazione va ad intaccare quelle che sono le regole ACID ... il tutto , ovvimaente, è "regolato" all' interno del "motore" del DB ...
Quello che posso dire è che, nonostante tutta questa "tecnologia" , a volte, il DB si pianta lo stesso e occorre l' intervento "umano" per ripristinare delle transazioni che sono rimaste "InDoubt" (in dubbio) e che necessitano, quindi o di un rollback o di un consolidamento manuale.
Questo molto "in soldoni" ...

Ciao !!

[DonChisciotte]

immagino che per cluster si intenda un sistema distribuito in cui non c'e' un master ed uno slave, ma i nodi sono allo stesso livello, condividendo i dati.
lo scopo e' quello di avere delle risorse scalabili (aggiungi un nodo al pool ed hai altre risorse da poter occupare) in modo da sopperire ad un numero di richieste che un unico server difficilmente riuscirebbe a soddisfare senza rallentamenti.

forse mi sono spiegato come un libro stracciato ma mi son appena svegliato...