4 ms·
What if you added a rule that if 2 nodes lose communication then after some period T the lowest ID node kills itself? And you add a delay of 2T to all client/se
by mcintyre1994 8y ago
What if you added a rule that if 2 nodes lose communication then after some period T the lowest ID node kills itself? And you add a delay of 2T to all client/server communication to give that a chance to happen.
Then in the example, client writes to V1, V1 waits T time to communicate with V2, it doesn't manage to so it returns failure to the client and kills itself. Then the client writes + reads to V2 instead.
Does this break availability because returning an error that you can't act on a client request counts as ignoring it in this informal definition?
- sobani 8y agoReturning an error is basically saying "I'm not available", because there is no guarantee there is an alternative. Your example can't deal with there being no path at all between V1 and V2. So even the client can't reach V2. In that case the entire system V is unavailable to the client. Availability in CAP is about being able to reach a node, but not all of them and because of that the system doesn't function. I guess killing a node when a problem occurs can be argued to defeat CAP (all the nodes that are up can reach each other), but it definitely doesn't improve the situation. Also what does you system do when V5 out of a 5 node cluster crashes? Do the nodes V1-V4 kill themselves, because they can no longer reach a higher ID node?
- mcintyre1994 8y agoAh I see what you mean, fair point - I'd agree that doesn't really work! TBH my 2-node system was a simplified version of Corosync which I've worked with a bit, in that you allow quorum if you have half+1 of nodes up - so 4/5 up will maintain quorum. The highest-node lives rule is just a tie breaker in the case of a half/half split which the 2 node system always has when one node goes down. Good point though, that rule alone is definitely not a good idea.