Cluster MySQL con bilanciamento del carico senza bilanciamento del carico

Sto cercando di creare un cluster MySQL con bilanciamento del carico, ma senza il bilanciamento del carico effettivo, al fine di non aggiungere un altro punto di errore o complessità.

Quello che stavo pensando era avere il seguente:

1. Avere una configurazione master-master per MySQL

2. Su ogni client, posizionare un semplice proxy round robin che ruoti le richieste tra i server.

È possibile? O ci sono modi migliori per raggiungere questo obiettivo?

Si prega di leggere la mia altra risposta a questa domanda prima di utilizzare effettivamente un proxy MySQL di qualsiasi tipo. Se hai 2 server master-master su cui sta scrivendo un CMS e 10 httpd che leggono solo da esso, starai bene, ma (come sottolineato nell'altra risposta) non è sempre il caso. Sei stato avvisato.

MySQL Proxy è un semplice programma che si trova tra il tuo client e i server MySQL in grado di monitorare, analizzare o trasformare la loro comunicazione. La sua flessibilità consente usi illimitati; quelli comuni includono: bilanciamento del carico; failover; analisi delle query; filtro e modifica delle query; e molti altri.

.

HAProxy è una soluzione gratuita, molto veloce e affidabile che offre elevata disponibilità, bilanciamento del carico e proxy per applicazioni basate su TCP e HTTP

Se lo avessi eseguito in modalità TCP, potrebbe essere persino migliore di Wackamole. Se dovessi scegliere tra loro, userei HAProxy. Anche HAProxy può avere molti backend, Waclamole può avere solo 2. Nota che HAProxy è "stupido", collega i socket senza guardare ciò che è all'interno dello stream - il proxy MySQL dedicato potrebbe avere un'opzione per indirizzare varie richieste a server specifici .

Probabilmente degno di nota, Galera Replication per MySQL per una vera configurazione MySQL multi-master. Galera è un protocollo di replica sincrona, quindi le applicazioni possono leggere e scrivere su qualsiasi server MySQL. Ecco un breve tutorial: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial

Per quanto riguarda i bilanciatori del carico di fronte ai server MySQL, utilizzare un connettore MySQL che supporti questa funzionalità (ad es. Connector / J per Java o Mysqlnd per php)

Se non si dispone di un connettore in grado di eseguire questa operazione, utilizzare qualcosa come un proxy HA. Questo script imposta automaticamente il proxy HA e mantiene l'elenco dei buoni server MySQL: https://github.com/severalnines/haproxy

I migliori saluti,

Vinay

www.severalnines.com

La replica master-master non è buona come si potrebbe pensare, lo stesso vale per il proxy round-robin e simili soluzioni "facili". Se si impegna la collisione dei dati su server separati abbastanza velocemente (più veloce del ritardo tra i server, che sui server di produzione potrebbe arrivare fino a un secondo intero *), entrambi accetteranno i dati. Se hai un server di aste, hai appena venduto la stessa auto due volte . Chi l'ha comprato? Dipende da quale DB chiederai!

L'applicazione deve essere consapevole che in realtà ci sono 2 database là fuori e deve conoscere entrambi i loro indirizzi IP. Se vuoi "vendere", dovresti fe

DB_number = `auction_number` % `number_of_databases`

( %è per modulo)

... e esegui il commit nel database DB_number. Se ricevi un errore di connessione, forse fallo con l'altro (ma nel caso di un server di aste, visualizzerei solo un errore).

Inoltre, gli indirizzi IP dovrebbero essere wackamole -d tra entrambi i server. In uno scenario di disastro, in cui un server di database si arresta per un paio d'ore nel periodo di massimo utilizzo, scoprirai che l'applicazione proverà a connettersi al server assente e si bloccherà fino a TIMEOUT, diciamo, 3s. All'improvviso, la metà delle tue query dura 3 secondi più a lungo (e alla fine vanno tutte allo stesso database, il che non lo rende più veloce di prima del disastro). Questo non rende felice il tuo httpd, poiché probabilmente ha un pool di connessioni limitato di thread di gestori di richieste simultanee ...

* il ritardo di replica sui server di produzione potrebbe arrivare fino a un secondo intero : l'ho verificato in una posizione remota e nel nostro data center e per circa il 99% delle volte è 0, ma a volte mysql mostra 1s. Su traffico intenso ho avuto molte collisioni a causa dell'applicazione client che ha fatto due richieste risultanti in due query, inserire e selezionare. Per alcuni casi, la riga proprio non c'era ancora , così abbiamo usato hash della userID e risolto il problema

Spero che imparerai dai miei errori ;-)

Un cluster di database MySQL (o qualche altro) con bilanciamento del carico è piuttosto inutile. Se si sta scrivendo su più di un server, si verificheranno problemi o si utilizza la replica sincrona (che MySQL non supporta comunque) e ciò compromette gravemente le prestazioni in quanto è necessario sincronizzare i blocchi.

Ti consiglio di dividere i carichi di lettura / scrittura e di bilanciare il carico delle letture tra gli slave mysql e di avere un unico master per le scritture o di utilizzare una coppia di failover attiva / passiva per il tuo master.

In sostanza, non è possibile ridimensionare le scritture inserendo più server in un database come slave, poiché ognuno deve ancora scrivere l'intero carico di scrittura della propria applicazione.

Per ridimensionare le scritture è necessario dividere i dati in modo logico su più server, partizionando o "partizionando" ecc. In genere ciò richiede modifiche non banali (si ritiene molto difficile testare) all'applicazione, quindi non si desidera farlo se non REALMENTE bisogno di essa.

Ovviamente puoi usare il cluster MySQL se vuoi davvero, ma è un motore completamente diverso con le sue caratteristiche e svantaggi: è un po 'complicato da configurare ma fornisce davvero un database con bilanciamento del carico HA sull'hardware delle materie prime. Soffre ancora di penalità in termini di prestazioni di scrittura derivanti dall'utilizzo della replica sincrona, ma consente di ridimensionare le scritture poiché ha incorporato il partizionamento tra server.

Un'altra grande guida su questo argomento che ho trovato ...

http://www.dancryer.com/2010/01/mysql-circular-replication

Questa è la parte 1 di una serie di tre post:

• MySQL Guida al cluster con bilanciamento del carico - Parte 1: impostazione dei server stessi e configurazione della replica di MySQL.

• MySQL Load-Balanced Cluster Guide - Part 2 - imposta uno script per monitorare lo stato dei tuoi nodi cluster MySQL, che useremo nella prossima guida per configurare il nostro proxy.

• MySQL Guida al cluster con bilanciamento del carico - Parte 3 - impostazione del bilanciamento del carico con HAProxy, utilizzando gli script di monitoraggio

Personalmente, il modo migliore sarebbe usare un bilanciamento del carico!

Sì, aggiunge un altro punto di errore, ma qualsiasi routine messa in atto, o installata su OGNI client, aggiunge molta più complessità di un bilanciamento del carico standard ....

Connector / J ha la capacità di bilanciare il carico delle query su più server. Questo è principalmente destinato al cluster NDB MySQL in cui tutti i nodi SQL avranno una visione coerente dei dati, ma se è possibile garantire che il database dei due master sia ragionevolmente coerente tra questi due master, potrebbe essere sicuro per la propria applicazione.

La stringa di connessione sarebbe simile a:

jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "random" e loadBalanceBlacklistTimeout = 5000

La divisione delle scritture non toglierà il carico dai server perché le scritture devono ancora essere replicate.

Se si utilizzano solo 2 server, utilizzare heartbeat con drbd e lasciare che drbd gestisca la replica. Se il primo server fallisce, subentrerà il secondo server. Se si desidera utilizzare il secondo server, è possibile utilizzare gfs su drbd e quindi eseguire il secondo server in sola lettura e utilizzarlo come server di lettura. Quando si verifica un failover, modificare il server in lettura / scrittura.

re: wackamole - wackamole non è limitato a 2 server

Sto lavorando a una serie di tutorial su questo, ma è davvero semplice da configurare.

Per dare una risposta più recente a questa domanda, con la versione 5.6 di MySQL, sono stati introdotti GTID (Global Transaction Identifieres) che mirano a rendere più robusta la replica asincrona e mettere MySQL in corsa per HA (High Availability).

Questa sezione spiega la replica basata sulle transazioni utilizzando gli identificativi di transazione globali (GTID). Quando si utilizzano i GTID, ogni transazione può essere identificata e tracciata quando viene impegnata sul server di origine e applicata da tutti gli slave; ciò significa che quando si utilizzano i GTID non è necessario fare riferimento a file di registro o posizioni all'interno di tali file quando si avvia un nuovo slave o si passa a un nuovo master, il che semplifica notevolmente queste attività. Poiché la replica basata su GTID è completamente basata su transazioni, è semplice determinare se i master e gli slave sono coerenti; fintanto che tutte le transazioni impegnate su un master sono impegnate anche su uno slave, la coerenza tra i due è garantita. È possibile utilizzare la replica basata su istruzioni o basata su righe con GTID (vedere Sezione 16.2.1, "Formati di replica"); tuttavia, per i migliori risultati,

Riferimento: 16.1.3 Replica con identificatori di transazioni globali (documentazione MySQL)

Ho pensato che l'uso di HAProxy per eseguire il bilanciamento delle query sta introducendo uno SPOF (Single Point Of Failure) e l'aggiunta del battito cardiaco rende questa soluzione ingombrante.

Una soluzione più semplice è quella di connettersi tramite il connettore Java JConnector che mira a caricare le query di bilanciamento attraverso un URL jdbc con tutti i nodi MySQL. Può gestire configurazioni master / slave o master / master .

Ciò consente di configurare una soluzione cluster HA pronta all'uso con MySQL.