MySQL Cluster

[guest]

Sapevate di questo?
L'avete mai usato in modalità disco?

As of version 5.1, MySQL Cluster supports data storage not only in main memory (RAM), but also on
disk. This arrangement allows applications to leverage the benefits of in-memory data storage, which not
only increases the performance of the application, but also limits I/O bottlenecks by asynchronously
writing transaction logs to disk. But, with the introduction of disk-data support, ever larger data sets that
do not require the performance characteristics granted to in-memory data, can be leveraged within the
cluster.

[Valeriano Manassero]

Sapevate di questo?
L'avete mai usato in modalità disco?

Sì, e provo pena per MySQL.
Non ho dati alla mano, ma su una richiesta specifica, il cliente ha abbandonato perché le prestazioni erano orride già ad occhio.

[guest]

Il problema è che ad oggi non esiste un metodo affidabile per scalare mysql, quando devi usare obbligatoriamente questo database.

Idee?

[Valeriano Manassero]

Il problema è che ad oggi non esiste un metodo affidabile per scalare mysql, quando devi usare obbligatoriamente questo database.

Purtroppo MySQL ha dei limiti abominevoli, ma spesso non si vedono perchè non si arriva a metterli alla prova. Scalare su questo DB senza utilizzare una versione commerciale è come giocare alla roulette russa...

Idee?

Ti direi PostgreSQL ma se nei prerequisiti mi metti MySQL non vale
Se proprio non ne esci, una soluzione potrebbe essere, per l'appunto, la versione commerciale Enterprise con tanto di consulenza da parte loro. Ah, dimenticavo, prepara il portafoglio...

[guest]

Ma, ti dirò che la soluzione più rapida è composta da almeno 3 server.
Due master in active/failover replicati con drbd e ridondati con heartbeat, più almeno 1 slave.

O addirittura un master che replica su un tot di slave di cui uno candidato master.

Il problema di 1master Xslave è che se ti muore la replica, i dati diventano subito inconsistenti, ti si attiva il master e vai nella cacca con effetti in stile splitbrain (il master originale è morto, lo slave candidato si elegge master, inizia a scrivere, senza considerare che la base dati dalla quale parte non è più sincronizzata da un pezzo perchè la replica era morta magari 40 insert prima).

Con drbd questo non accade, perchè il server candidato è un clone a livello di disco del primario, se muore il mysql master, l'altro diventa subito un clone con gli stessi dati sotto.

MySQL proxy lo si fa girare su entrambi e keepalive (o chi per lui) lo tiene attivo su uno soltanto.
mySQL proxy avrà come backend in scrittura sempre e solo se stesso, mentre in lettura tutto il cluster di slave.
così facendo, mysql proxy sul master1 scriverà su 127.0.0.1, muore il master, parte l'altro master, mysql proxy è già li pronto ad intervenire e salverà sempre su 127.0.0.1

di meglio non mi viene in mente nulla.

EDIT: mysql proxy può duplicare le query? Ad esempio ne intercetto una e ne faccio uscire due, una per server. Bypasso le repliche così...

[Valeriano Manassero]

Ma, ti dirò che la soluzione più rapida è composta da almeno 3 server.
Due master in active/failover replicati con drbd e ridondati con heartbeat, più almeno 1 slave.

O addirittura un master che replica su un tot di slave di cui uno candidato master.

Il problema di 1master Xslave è che se ti muore la replica, i dati diventano subito inconsistenti, ti si attiva il master e vai nella cacca con effetti in stile splitbrain (il master originale è morto, lo slave candidato si elegge master, inizia a scrivere, senza considerare che la base dati dalla quale parte non è più sincronizzata da un pezzo perchè la replica era morta magari 40 insert prima).

Con drbd questo non accade, perchè il server candidato è un clone a livello di disco del primario, se muore il mysql master, l'altro diventa subito un clone con gli stessi dati sotto.

MySQL proxy lo si fa girare su entrambi e keepalive (o chi per lui) lo tiene attivo su uno soltanto.
mySQL proxy avrà come backend in scrittura sempre e solo se stesso, mentre in lettura tutto il cluster di slave.
così facendo, mysql proxy sul master1 scriverà su 127.0.0.1, muore il master, parte l'altro master, mysql proxy è già li pronto ad intervenire e salverà sempre su 127.0.0.1

di meglio non mi viene in mente nulla.

Non ho la minima voglia di ragionare di nuovo su sto DB che mi fa venire l'orticaria
Comunque, complimenti per l'inventiva Hai praticamente fatto una mega struttura workaround (del resto non si poteva far altro), però rendiamoci conto che stai cercando, grazie a modifiche strutturali pesanti, di limitare tutti i casini che può dare sto db vergognoso ed ancora c'è chi non crede che PGSQL sia, nel complesso, una spanna sopra.

EDIT: mysql proxy può duplicare le query? Ad esempio ne intercetto una e ne faccio uscire due, una per server. Bypasso le repliche così...

A memoria mi pare possibile, ma anche qui sono tutti workaround tramite LUA.
Prova a guardare al code di questo item:
Tools :: Code Snippet :: Duplicate Queries

Oh, io non l'ho provato ne tantomeno studiato eh, potrebbe essere inutile.

[guest]

Purtroppo forzare al cambio di un db non è mai una soluzione e non sempre è possibile.

Però ci dovrà pur essere il modo di avere un sistema stabile, grossi player usano mysql con successo.

Anche la versione enterprise da questo punto di vista non avrebbe vantaggi. Le repliche son le stesse con entrambi i sistemi.

[Valeriano Manassero]

Purtroppo forzare al cambio di un db non è mai una soluzione e non sempre è possibile.

Però ci dovrà pur essere il modo di avere un sistema stabile, grossi player usano mysql con successo.

Anche la versione enterprise da questo punto di vista non avrebbe vantaggi. Le repliche son le stesse con entrambi i sistemi.

I grossi player, di solito, usano la Enterprise. E' vero che, sulla carta non porta grossi vantaggi, ma grazie alla consulenza di chi conosce il prodotto a fondo (e con tutta una miriade di tool Enterprise only), potresti ottenere la soluzione.
Diversamente te la giochi "a tentativi" e rabbrividisco al solo pensiero, mi rendo conto, però, che il mercato continua a richiedere MySQL ed allora MySQL sia.

[guest]

Si, però mysql ha dalla sua parte un vantaggio/svantaggio.
E' estremamente semplice.
Non si tratta di Oracle in cui un supporto tecnico sicuramente è utile, su mysql la replica si attiva con una singola query in cui metti 4 parametri, non uno di più, non uno di meno. ed è finita li.
O va o non va. Non può andare male.

Il problema è che sono 'fragili' magari funzionano bene per 34 anni, poi ti arriva UNA query che ti smonta tutto il cluster ed in tal caso iniziano i dolori perchè mancano sistemi automatici di recovery e cose simili.

E non ci sono nemmeno su Enterprise.

[Valeriano Manassero]

Si, però mysql ha dalla sua parte un vantaggio/svantaggio.
E' estremamente semplice.

Come giustamente lo hai definito è uno svantaggio/vantaggio. Lo sai che io ho una visione molto di parte e quindi non faccio testo, però, la sua semplicità non va a braccetto con un buon motore db e tutti giocano (i programmatori php soprattutto) al piccolo db admin con risultati che sono spesso catastrofici. Le stored procedure (o chiamiamole come vogliamo), in MySQL sono arrivate ultimamente, PG e M$ le hanno da un bel po' e su DB di un certo peso influenzano moltissimo l'andamento prestazionale. Quanti CMS open le utilizzano?

Non si tratta di Oracle in cui un supporto tecnico sicuramente è utile, su mysql la replica si attiva con una singola query in cui metti 4 parametri, non uno di più, non uno di meno. ed è finita li.
O va o non va. Non può andare male.

Beh, "non può andare male" è un'affermazione piuttosto forte . Il fatto è che, la replica MySQL, per come è fatta, è, a sua volta, un sistema per dire "anche noi possiamo", ma ha un impatto notevole quando sarebbe stato molto più opportuno sviluppare un demone ad hoc per gestire questi scenari.

Il problema è che sono 'fragili' magari funzionano bene per 34 anni, poi ti arriva UNA query che ti smonta tutto il cluster ed in tal caso iniziano i dolori perchè mancano sistemi automatici di recovery e cose simili.

Hai detto niente. *una* query che ti fa esplodere un cluster è un fail di proporzioni immani, sarà per questo che sulle mie macchine mysql è in drop di default.
Prima delle prestazioni e prima della semplicità, per un DB, il *must* assoluto sono:

• stabilità
• consistenza dei dati
• affidabilità delle procedure di backup/restore

MySQL non ha nulla di queste tre, o per lo meno non garantisce sufficiente margine su questi aspetti quando i db cominciano ad essere di un certo spessore.
Insomma, è uno step tra SQLite ed i veri DB di alto livello.

E non ci sono nemmeno su Enterprise.

E questo mi pare ancora più grave.anche se, nelle features decantate vedo un sacco di belle cose, se è solo marketing non lo so, come ti dicevo io e quel coso lì non siamo molto amici

[guest]

Mr. Mela, non sto difendendo MySQL, io non lo sopporto (ma ammetto di non saper usare PG!). Spesso ci si ritrova a dover gestire carichi complessi che difficilmente potranno stare su un singolo server e quando arrivi a quel punto hai due scelte:

a) butti via tutto, riprogetti il software e cambi RDBMS
b) trovi una cacchio di soluzione, stile Jenga (http://putxitonkaiola.files.wordpres...sbro-jenga.jpg), che ti permetta di scalare.

Considerato che la soluzione A quasi mai è applicabile, la soluzione B lo è quasi sempre.
L'aspetto negativo (molto, molto negativo) e che devi strutturare te dei demoni che stiano sempre li a monitorare lo status del cluster e che prendano provvedimenti, rendendo la soluzione estremamente complessa.

Però, se non ci sono alternative, che devo fare?

EDIT: mettiti nei panni di chi fa hosting (come noi ad esempio, anche se l'hosting in questo mio caso specifico non ha niente a che fare). Non puoi forzare gli utenti ad usare PG o Oracle o altri sistemi solo perchè MySQL non è 'gestibile'. La totalità del software web supporta MySQL, mentre sono una rarità i sistemi che supportano anche altri DB. In tal caso, o mandi via i clienti, o trovi un workaround. Per questo la soluzione A quasi mai è applicabile, anche se è sicuramente la migliore.

[Valeriano Manassero]

Però, se non ci sono alternative, che devo fare?

Nulla, si chiama "situazione senza via d'uscita con volatile padulo in fase d'atterraggio" (se non sapete cos'è il padulo, beh, non posso esprimermi oltre ).
Mi rendo conto che non puoi sbattere via tutto e non hai alternative valide, quindi vai di olio di gomito e mettici anche qualche preghiera, tanto per stare tranquilli.

[guest]

Sai che se implementassi un demone che tenga 'a bada' le repliche di MySQL potrei diventare ricco?

[Valeriano Manassero]

Sai che se implementassi un demone che tenga 'a bada' le repliche di MySQL potrei diventare ricco?

Io ne avrei un'altra, pensa ad implementare un demone tipo mysql-proxy che accetti tutto il SQL di MySQL (che non è tutto SQL standard se ben ricordo) ma che "traduca" il tutto avendo dietro PG. In un solo secondo potresti buttare via tutto e dare all'utente finale la "sensazione" di trovarsi su un MySQL.
Ovviamente è un sogno (ed anche poco applicabile), ma pensa se invece si potessero usare degli ORM seri e cambiare il db sotto l'applicativo senza manco accorgertene (ops, esiste già, è Rails.. ma vado OT ).

[guest]

Ma rackspace secondo te come scala? Usa MySQL sulla cloud. (per i motivi che ho esposto sopra)