In che modo MySQL Cluster 7.3 può raggiungere una disponibilità del 99,999%? Teorema CAP in antitesi

Question

In base allo "Guide to Scaling Web Databases with MySQL Cluster", MySQL Cluster 7.3 può ottenere una disponibilità del 99,999% utilizzando la replica di aggiornamento sincrono. Questa sarebbe un'antitesi allo CAP Theorem poiché afferma che la perfetta disponibilità (99,999% può essere visto come questo, no?) E la coerenza non è accettabile nei sistemi distribuiti.

Come reagisce il cluster per un aggiornamento, se il datanode responsabile della replica non è raggiungibile? Per una replica di aggiornamento sincrono deve bloccarsi, il che influirebbe sulla disponibilità.

La Guida afferma:

• I dati all'interno di un nodo di dati viene replicata in modo sincrono a tutti i nodi all'interno del gruppo di nodi. Se un nodo dati non funziona, allora c'è sempre un altro nodo dati che memorizza le stesse informazioni su .
• In caso di errore del nodo dati, il server MySQL o il nodo applicazione possono utilizzare qualsiasi altro nodo di dati nel gruppo di nodi per eseguire le transazioni . L'applicazione riprova semplicemente la transazione e i nodi di dati rimanenti soddisfano correttamente la richiesta.

Ma come può questo lavoro se un gruppo di nodi è costituito da due nodi e uno va in crash (esempio here)? Non ci sarebbe alcun nodo per replicare un aggiornamento a ciò che, a quanto ho capito, farebbe fallire l'aggiornamento mentre si utilizza la replica di aggiornamento sincrono ?! La replica è appena sospesa per il tempo in cui non esiste un nodo in cui scrivere una replica?

Answer 1

Nella domanda di esempio, il problema non include partizione. Partizione significa che metà dei dati rimarranno in un nodo e un'altra metà nell'altro nodo (non è necessario che sia metà del 50%, ma i dati devono essere suddivisi in più nodi).

---

anche nel tuo esempio domanda, se uno dei nodi si blocca, l'altro sta ancora lavorando; quindi disponi della disponibilità . E poiché uno dei nodi è una replica dell'altro, non dovresti avere problemi con la consistenza .

Solo perché l'aggiornamento ha esito negativo, non significa che i dati non siano coerenti. Se si tenta di accedere ai dati dal cluster, si avranno dati coerenti, poiché non è possibile recuperare i dati incoerenti dal nodo morto.

In altre parole, si hanno dati incoerenti solo se si esegue una query sul cluster e i dati riprovati non sono coerenti.