Zookeeper/Chubby -confrontarli- MySql NDB

Question

Ho letto la carta Paxos, la FLP teorema ecc recente e valutare Apache Zookeeper per un progetto. Ho visitato anche Chubby (il servizio di blocco distribuito di Google) e le varie pubblicazioni su di esso disponibili online. La mia base fondamentale per Zookeeper è implementare la replica e il coordinamento generale per un sistema distribuito.

Mi chiedevo però, qual è il vantaggio specifico che Zookeeper o un Chubby come sistema di bloccaggio distribuito porta in tavola. Fondamentalmente mi sto chiedendo perché non posso semplicemente usare un cluster NDB MySQL. Continuo a sentire che MySQL ha molti problemi di replica. Speravo che qualcuno con più esperienza sull'argomento potesse far luce su di esso.

Grazie in anticipo ..

un elenco semplicistica delle mie esigenze:

• ho un sistema distribuito omogeneo.
• Ho bisogno di alcuni mezzi per mantenere uno stato coerente su tutti i miei nodi.
• Il mio sistema espone un servizio, e l'interazione con i clienti porterà ad alcuni cambiamenti nello stato collettivo del mio sistema.
• L'alta disponibilità è un obiettivo, quindi un nodo che scende non deve influire sul servizio.
• Mi aspetto che il sistema funzioni almeno un paio di 1000 req/sec.
• mi aspetto 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 dalla scala e tolleranza di errore che si sta andando.

Posso rispondere dal punto di vista di ZooKeeper. Prima di iniziare dovrei menzionare che ZooKeeper non è un clone Chubby. Nello specifico, non blocca direttamente. È inoltre progettato tenendo conto delle diverse esigenze di ordine e prestazioni.

In ZooKeeper l'intera copia dello stato del sistema è residente in memoria. Le modifiche vengono replicate utilizzando un protocollo di trasmissione atomica e sincronizzate su disco (utilizzando un journal delle modifiche) dalla maggior parte dei server ZooKeeper prima di essere elaborate. A causa di questo ZooKeeper ha prestazioni deterministiche in grado di tollerare guasti fino a quando la maggior parte dei server è attiva. Anche con un'interruzione grave, come un'interruzione dell'alimentazione, finché la maggior parte dei server torna in linea, lo stato del sistema verrà mantenuto. Le informazioni memorizzate sono generalmente considerate come la verità fondamentale del sistema, pertanto tali garanzie di consistenza e durata sono molto importanti.

Le altre cose che ZooKeeper ti dà hanno a che fare con il monitoraggio dello stato di coordinamento dinamico. I nodi effimeri consentono di eseguire facilmente il rilevamento degli errori e l'appartenenza ai gruppi. Le garanzie di ordinazione ti consentono di effettuare l'elezione del leader e il blocco del lato client. Infine, gli orologi consentono di monitorare lo stato del sistema e rispondere rapidamente ai cambiamenti nello stato del sistema.

Quindi, se è necessario gestire e rispondere alla configurazione dinamica, rilevare errori, eleggere leader, ecc. ZooKeeper è ciò che si sta cercando. Se hai bisogno di memorizzare molti dati o hai bisogno di un modello relazionale per quei dati, MySQL è un'opzione molto migliore.

Answer 2

MySQL con InnoDB fornisce una buona soluzione generica, e probabilmente manterrà abbastanza facilmente le vostre esigenze in termini di prestazioni con hardware non troppo costoso. Può gestire facilmente molte migliaia di aggiornamenti al secondo su una doppia scatola quad-core con dischi decenti. La replica asincrona integrata ti offre la maggior parte del modo per i tuoi requisiti di disponibilità, ma potresti perdere alcuni secondi di dati se il primario fallisce. Alcuni di questi dati persi potrebbero essere recuperabili quando il primario viene riparato, o potrebbe essere recuperato dai registri delle applicazioni: se si può tollerare ciò dipende dal modo in cui funziona il sistema. Un'alternativa meno lenta - ma più lenta - è usare MySQL Innodb con disco condiviso tra unità Primaria e Failover: in questo caso, l'unità Failover prenderà il controllo del disco quando il Primario fallisce senza perdita di dati - purché il Primario non ha avuto alcun tipo di catastrofe su disco. Se il disco condiviso non è disponibile, è possibile utilizzare DRBD per simulare ciò copiando in modo sincrono i blocchi del disco sull'unità Failover mentre vengono scritti: ciò potrebbe avere un impatto sulle prestazioni.

L'utilizzo di Innodb e una delle soluzioni di replica sopra riportate consente di copiare i dati nell'unità Failover, che risolve gran parte del problema di ripristino, ma è necessaria una colla extra per riconfigurare il sistema per portare l'unità Failover su linea. Questo di solito viene eseguito con un sistema cluster come RHCS o Pacemaker o Heartbeat (su Linux) o il materiale MS Cluster per Windows. Questi sistemi sono toolkit, e sei lasciato a sporcarti le mani costruendoli in una soluzione adatta al tuo ambiente. Tuttavia, per tutti questi sistemi c'è un breve periodo di interruzione mentre il sistema rileva che il Primario non è riuscito e riconfigura il sistema per utilizzare l'unità Failover. Questo potrebbe richiedere decine di secondi: provare a ridurlo può rendere il sistema di rilevamento degli errori troppo sensibile e il sistema potrebbe non funzionare 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 di applicabilità piuttosto limitata.Il sistema associa un database relazionale a una tabella hash distribuita, quindi per le query complesse che coinvolgono più join tra tabelle, c'è un po 'di traffico tra il componente MySQL e i componenti di archiviazione (i nodi NDB) che rallentano le query complesse. Tuttavia, le query che si adattano bene funzionano davvero molto velocemente. Ho esaminato questo prodotto alcune volte, ma i miei database esistenti sono stati troppo complicati per adattarsi bene e richiederebbero molte modifiche per ottenere buone prestazioni. Tuttavia, se sei nella fase di progettazione di un nuovo sistema, NDB funzionerebbe bene se riuscirai a tenere a mente i suoi limiti mentre procedi. Inoltre, è possibile che siano necessarie diverse 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 esigenze di prestazioni non sono eccessive.

Anche MySQL NDB non è in grado di gestire la perdita totale del sito: incendi nel data center, errore di amministrazione, ecc. In questo caso, in genere è necessario un altro flusso di replica in esecuzione su un sito DR. Normalmente ciò avverrà in modo asincrono, in modo tale che i collegamenti di connettività sul collegamento tra siti non interrompano l'intero database. Questo è fornito con l'opzione di replica geografica di NDB (nella versione per telco a pagamento), ma penso che MySQL 5.1 e versioni successive possano fornire questo in modo nativo.

Sfortunatamente, conosco poco su Zookeeper e Chubby. Speriamo che qualcun altro possa cogliere questi aspetti.