Zookeeper / Chubby -confrontarli- MySql NDB

Question

Ho letto la carta Paxos, la FLP teorema ecc recente e valutare Apache Zookeeper per un progetto. Ho anche intenzione attraverso Chubby (servizio di blocco distribuito di Google) e le varie letteratura su di esso che è disponibile online. Il mio caso d'uso fondamentale per Zookeeper è quello di implementare la replica e il coordinamento generale per un sistema distribuito.

Mi stavo chiedendo, però, qual è il vantaggio specifico che Zookeeper o un Chubby come sistema di bloccaggio distribuito porta in tavola. Fondamentalmente Mi chiedo solo perché non posso semplicemente utilizzare un MySQL Cluster NDB. Continuo a sentire che MySQL ha un sacco di problemi di replica. Speravo alcuni con più esperienza su questo argomento potrebbe far luce su di esso.

Grazie in anticipo ..

Un elenco semplicistica delle mie esigenze:

• Ho un sistema distribuito omogeneo.
• Ho bisogno di alcuni mezzi di mantenimento dello stato coerente in tutti i miei nodi.
• Il mio sistema espone un servizio, e l'interazione con i clienti porterà a qualche cambiamento in stato collettivo del mio sistema.
• L'alta disponibilità è un obiettivo, in tal modo un nodo che va verso il basso non deve pregiudicare il servizio.
• mi aspetto il sistema al servizio atleast un paio di 1000 req / sec.
• Mi aspetto che lo stato collettiva del sistema di essere limitato in termini di dimensioni (inserti in pratica / eliminazioni saranno transitoria ... ma in stato stazionario, mi aspetto un sacco di aggiornamenti e legge)

Answer 1

Dipende dal tipo di dati che si sta gestendo e la tolleranza scala e la colpa si sta andando per.

posso rispondere dal punto di vista ZooKeeper. Prima di iniziare devo dire che ZooKeeper non è un clone Chubby. Specificamente non fa direttamente serrature. Inoltre è stato progettato con diverse esigenze di ordinazione e di prestazioni in mente.

Nel ZooKeeper l'intera copia di stato del sistema è la memoria residente. Le modifiche vengono replicate utilizzando un protocollo di trasmissione atomica e sincronizzati su disco (usando un diario cambiamento) dalla maggioranza dei server Zookeeper prima di essere processati. A causa di questo ZooKeeper ha prestazioni deterministiche in grado di tollerare gli errori finché la maggioranza dei server sono in su. Anche con una grande interruzione, come ad esempio una mancanza di corrente, a patto che la maggioranza dei server torna in linea, stato del sistema viene preservata. Le informazioni memorizzate è ZooKeeper è di solito considerata la verità a terra del sistema in modo tale consistenza e durata garanzie sono molto importanti.

Le altre cose che ZooKeeper dà avete a che fare con il monitoraggio dello stato di coordinamento dinamico. nodi effimere consentono di fare per facile individuazione di guasti e l'appartenenza al gruppo. Le garanzie di ordinazione ti permettono di fare elezione leader e bloccaggio lato client. Infine, orologi permettono di monitorare lo stato del sistema e rispondere rapidamente ai cambiamenti nello stato del sistema.

Quindi, se è necessario gestire e rispondere agli configurazione dinamica, rilevare gli errori, i leader eletti, ecc ZooKeeper è quello che stai cercando. Se avete bisogno di memorizzare grandi quantità di dati o avete bisogno di un modello relazionale per i dati, MySQL è una scelta molto migliore.

Answer 2

MySQL con InnoDB fornisce una buona soluzione general purpose, e probabilmente tenere il passo con le vostre esigenze di prestazioni abbastanza facilmente su hardware non troppo costoso. Si può facilmente gestire molte migliaia di aggiornamenti al secondo su un doppio scatola quad-core con i dischi decenti. La replica asincrona incorporato ti porterà la maggior parte del tragitto per le vostre esigenze di disponibilità - ma si potrebbe perdere valore dei dati di pochi secondi se il primario non riesce. Alcuni di questi dati persi potrebbero essere recuperabili quando il primario viene riparato, o potrebbero essere recuperabili dai registri di applicazione: se è possibile tollerare questo dipende da come funziona il sistema. A meno perdita di dati - ma più lento - alternativa è quella di utilizzare MySQL InnoDB con disco condiviso tra le unità primarie e di failover: in questo caso, l'unità di failover sarà prendere in consegna il disco quando fallisce il primario senza alcuna perdita di dati - fino a quando il primario non ha avuto un qualche tipo di catastrofi disco. Se disco condiviso non è disponibile, DRBD può essere utilizzato per simulare questo copiando in modo sincrono blocchi del disco per l'unità di failover come sono scritte:. Questo potrebbe avere un impatto sulle prestazioni

Utilizzando InnoDB e una delle soluzioni di replica di cui sopra saranno ottenere i dati copiati alla vostra unità di failover, che è una grande parte del problema di recupero risolto, ma la colla in più è necessario per riconfigurare il sistema per portare l'unità di failover on-line . Questo è di solito eseguita con un sistema di cluster come RHCS o pacemaker o Heartbeat (su Linux) o la roba MS Cluster per Windows. Questi sistemi sono toolkit, e si sono lasciati a sporcarsi le mani la loro costruzione in una soluzione che si adatta al proprio ambiente. Tuttavia, per tutti questi sistemi v'è un breve periodo di interruzione, mentre il sistema si accorge che il primario ha fallito, e riconfigura al sistema di utilizzare l'unità di failover. Questo potrebbe essere decine di secondi:. Cercando di ridurre questo può rendere il vostro sistema di rilevamento guasti troppo sensibile, e si potrebbe trovare il sistema che è impossibile oltre inutilmente

Muoversi, MySQL NDB ha lo scopo di ridurre i tempi di recupero, e in qualche misura di aiuto scala il backup del database per migliorare le prestazioni. Tuttavia, MySQL NDB ha una gamma abbastanza stretta di applicabilità. Il sistema associa un database relazionale a una tabella hash distribuita, e così per le query complesse che coinvolgono più join tra tabelle, c'è un po 'di traffico tra la componente MySQL e le componenti di storage (i nodi NDB) rendendo query complesse corsa lenta. Tuttavia, le query che si adattano bene correre molto velocemente. Ho guardato questo prodotto un paio di volte, ma le mie basi di dati esistenti sono stati troppo complicato per adattarsi bene e richiederebbe un sacco di riprogettazione per ottenere buone prestazioni. Tuttavia, se si è in fase di progettazione di un nuovo sistema, NDB avrebbe funzionato bene se riesci a sopportare i suoi vincoli in mente come si va. Inoltre, si potrebbe scoprire che avete bisogno di un bel paio di macchine per fornire una buona soluzione NDB: un paio di nodi MySQL più 3 o più nodi NDB - anche se i nodi MySQL e NDB possono coesistere se le vostre esigenze di prestazioni non sono troppo estreme.

Anche MySQL NDB non può far fronte con la perdita totale del sito - il fuoco al centro dati, errori di amministrazione, ecc In questo caso, di solito bisogno di un altro flusso di replica in esecuzione ad un sito di DR. Questo sarà normalmente essere fatto in modo asincrono in modo che i puntini di connettività sul collegamento tra siti non stalla l'intero database. Questo è dotato di opzione di replica geografica di NDB (nella versione telco versato per), ma credo che MySQL 5.1 e, soprattutto, in grado di fornire in modo nativo.

Purtroppo, io so poco di Zookeeper e Chubby. Speriamo che qualcun altro può prendere questi aspetti.