Architettura del database master-master vs master-slave?

Ho sentito parlare di due tipi di architetture di database.

• master-master

• master-slave

Il master-master non è più adatto per il web di oggi perché è come Git, ogni unità ha l'intero set di dati e se uno va giù, non importa.

Master-slave mi ricorda SVN (che non mi piace) dove hai un'unità centrale che gestisce le cose.

Domande:

1. Quali sono i pro ed i contro di ognuno?

2. Se vuoi avere un database locale nel tuo cellulare come iPhone, qual è il più appropriato?

3. La scelta di uno di questi è un fattore critico da considerare a fondo?

Stiamo scambiando disponibilità, coerenza e complessità. Per affrontare prima l'ultima domanda: è importante? Sì, molto! Le scelte relative a come devono essere gestiti i dati sono assolutamente fondamentali e non esiste una "Best Practice" che sfugga alle decisioni. Devi capire le tue esigenze particolari.

C'è una tensione fondamentale:

Una copia: la coerenza è facile, ma se capita di essere a terra tutti sono fuori dall'acqua, e se le persone sono lontane allora potrebbero pagare orribili costi di comunicazione. Porta i dispositivi portatili, che potrebbero dover funzionare scollegati, nell'immagine e una copia non la taglierà.

Master Slave: la coerenza non è troppo difficile perché ogni dato ha esattamente un master proprietario. Ma allora cosa fai se non riesci a vedere quel maestro, è necessaria una sorta di lavoro rimandato.

Master-Master: beh, se riesci a farlo funzionare, sembra che offra tutto, nessun singolo punto di fallimento, tutti possono lavorare tutto il tempo. Il problema con questo è che è molto difficile preservare la coerenza assoluta. Vedere l' articolo di wikipedia per ulteriori informazioni.

Wikipedia sembra avere un bel riassunto dei vantaggi e degli svantaggi

vantaggi

• Se un master si guasta, gli altri master continueranno ad aggiornare il database.

• I master possono essere situati in diversi siti fisici, ovvero distribuiti sulla rete.

svantaggi

• La maggior parte dei sistemi di replica multi-master sono solo vagamente coerenti, ovvero pigri e asincroni, violando le proprietà ACID.

• I sistemi di replica desiderosi sono complessi e introducono una certa latenza di comunicazione.

• Problemi come la risoluzione dei conflitti possono diventare intrattabili quando il numero di nodi coinvolti aumenta e la latenza richiesta diminuisce.

Durante la ricerca anche delle varie architetture di database. Ho compilato un bel po 'di informazioni che potrebbero essere rilevanti per qualcun altro che ricerca in futuro. Mi sono imbattuto

1. Replica master-slave
2. Replica master-master
3. MySQL Cluster

Ho deciso di accontentarmi di utilizzare MySQL Cluster per il mio caso d'uso. Tuttavia, vedi sotto per i vari pro e contro che ho compilato

1. Replica master-slave

Professionisti

• Le applicazioni analitiche possono leggere dagli slave senza influire sul master
• Backup dell'intero database di relativamente nessun impatto sul master
• Gli slave possono essere portati offline e sincronizzati di nuovo con il master senza tempi di inattività

Contro

• In caso di fallimento, uno schiavo deve essere promosso a padrone per prendere il suo posto. Nessun failover automatico
• Tempo di inattività e possibile perdita di dati in caso di guasto di un master
• Tutte le scritture devono essere eseguite anche sul master in un design master-slave
• Ogni slave aggiuntivo aggiunge un po 'di carico al master poiché il log binario deve essere letto e i dati copiati su ciascuno slave
• Potrebbe essere necessario riavviare l'applicazione

2. Replica master-master

Professionisti

• Le applicazioni possono leggere da entrambi i master
• Distribuisce il carico di scrittura su entrambi i nodi master
• Failover semplice, automatico e veloce

Contro

• Vagamente coerente
• Non semplice come master-slave da configurare e distribuire

3. MySQL Cluster

Il nuovo ragazzo in città basato sul design del cluster MySQL. Il cluster MySQL è stato sviluppato pensando all'alta disponibilità e scalabilità ed è la soluzione ideale da utilizzare per ambienti che non richiedono tempi di inattività, alta disponibilità e scalabilità orizzontale.

Vedere MySQL Cluster 101 per ulteriori informazioni

Professionisti

• (Alta disponibilità) Nessun singolo punto di guasto
• Produttività molto elevata
• Tempo di attività del 99,99%
• Auto-Sharding
• Reattività in tempo reale
• Operazioni in linea (modifiche allo schema, ecc.)
• Scritture distribuite

Contro

• Vedi limitazioni note

Puoi visitare la ripartizione completa del mio blog , inclusi i diagrammi di architettura che vanno in ulteriori dettagli sulle 3 architetture menzionate.