Ho battuto il Teorema CAP con questo sistema distribuito master-slave (con immagine)?

Question

Ho battuto il Teorema CAP con questo sistema distribuito master-slave (con immagine)?

#1 da (9 voti)
#2 da (0 voti)

0

Stavo guardando questo video sul teorema CAP, in cui l'autore spiega bene i trade-off di sistemi. Tuttavia non sono d'accordo con il teorema CAP nel seguente aspetto. Data l'immagine qui sotto:

Ogni volta che c'è una partizione, in altre parole, ogni volta che uno slave perde la connessione al master, questo slave diventa immediatamente non disponibile . Quindi dirai: stai scegliendo la coerenza rispetto alla disponibilità . E dirò NO! . Il mio sistema distribuito è ancora altamente disponibile perché ci sono molti altri nodi slave di backup / ridondanti a cui il client può eseguire il failover. Quindi sto mantenendo la mia coerenza e sto mantenendo la mia disponibilità nel sistema. Un nodo slave in errore viene immediatamente (e automaticamente) disattivato e il client viene reindirizzato a un altro nodo slave per le letture .

Quindi potresti dire: ora cosa succede se il master master muore o se hai una partizione in cui due nodi master sono attivi? E la risposta è semplice: Il tuo sistema non deve MAI consentire a due nodi principali di essere attivi. Il tuo sistema deve sempre avere uno e un solo nodo master con tutti i nodi master di backup che vuoi, ma tutto il backup i nodi master saranno inattivi (ovvero non accettano scritture e non fanno altro che creare uno stato ridondante).

L'unico compromesso di un tale sistema, perché nulla è perfetto: Avrà bisogno dell'intervento umano per il caso di un maestro di morte / cattivo stato , in modo che il master attivo possa essere arrestato da un essere umano e garantito essere morto mentre l'operatore attiva (manualmente) uno dei master di backup per prendere in carico le richieste di scrittura.

Ho riflettuto a lungo su come eliminare questo intervento umano, ma non penso che sia possibile a causa del fatto che una macchina non può determinare in modo affidabile lo stato di un'altra macchina in una distribuzione sistema . Un umano ha bisogno di prendere questa decisione e tirare manualmente la spina per ucciderlo.

Questo semplice compromesso (operatore umano per i rari casi in cui il master sta morendo) non ha battuto il teorema CAP?

distributed-computing distributed-system data-replication

posta Pika Sucar 22.08.2016 - 15:31

fonte

2 risposte

Leggi altre domande sui tag distributed-computing distributed-system data-replication

Per quale tipo di C ++ incorporato è la legge del mezzo escluso violata? Come posso spiegare il valore del refactoring agli stakeholder? [duplicare]

score 9 · Answer 1

whenever a slave loses its connection to the master, this slave immediately becomes unavailable

Questo non è necessariamente vero. L'argomento CAP presuppone che quando la rete è partizionata, ci possono essere client su entrambi lati della partizione.

...So I'm keeping my consistency and I'm keeping my availability in the system.

Anche l'argomento CAP presuppone che i client su entrambi i lati della partizione vogliano aggiornare il database. Se non si consente loro di farlo mentre la partizione esiste, il database non è disponibile per tutti i client per la scrittura. Se fai permetti loro di farlo mentre la rete è partizionata, allora il database non è coerente perché i nodi sui lati opposti della partizione ora hanno dati diversi.

Non è scienza missilistica.

Your system must NEVER allow two master nodes to be active.

In che modo i nodi che non possono comunicare tra loro sono d'accordo su quale è il padrone?

Se non consenti aggiornamenti a un nodo che non può parlare con un master, hai di nuovo dato la disponibilità.

It will need human intervention for the case of a dying / bad state master

Sarebbe inaccettabile in molti dei sistemi aziendali su larga scala di oggi.

A human needs to make this decision and manually pull the plug to kill it.

Nel caso generale, forse così, ma se ci sono delle regole che dovresti scrivere per guidare un nuovo dipendente su come prendere questa decisione, allora potresti scrivere quelle stesse regole in un programma per computer che reagirebbe molto più veloce di quanto possa mai fare un operatore umano.

score 0 · Answer 2

Hai ragione. In un sistema distribuito in modo dispersivo un umano deve prendere le decisioni, a causa della latenza della rete.

Ma in un'architettura più semplice, in cui i nodi sono vicini tra loro, è possibile utilizzare un'interfaccia di rete dedicata con un cavo point-to-point per controllare l'heartbeat l'un l'altro.

Quindi un layer ad alta disponibilità in ciascun nodo può controllarsi a vicenda.

Gestisco questa configurazione con i backend PostgreSQL e un Pgpool II in ogni nodo controllandoci a vicenda con uno script di failover che decide chi sarà il master. Lo script di failover decide anche a quale nodo viene assegnato l'indirizzo IP mobile che gli utenti finali conoscono.