Call me maybe: etcd and Consul
aphyr.com
aphyr.com
It is also great to see etcd showing up in lots of interesting projects like skydns and kubernetes. I think we have built something that is not just a great building block for CoreOS but the OSS community at large.
Thanks to everyone who has helped get the project to where it is today; there is a bright future ahead.
Other then that, it's great that we are getting some good results after serious vetting for more modern replacements to ZK. I may not like ZK's crufty-ness, but I could always trust it. Now with these results, I am seriously going to consider Consul as a replacement.
The ideal project would be something used within Comcast that doesn't otherwise have a corporate sponsor.
If the authors were aware of these issues then the documentation was dangerously misleading[1] and they should be docked points for that.
[1] As reported by aphyr, haven't read through it all myself. I'm thinking primarily of the labeling of "read from leader without going through log" as "consistent" bit.
In one of this products (etcd if I remember correctly) there was a clear statement in the documentation about this semantics, and anyway, who implements Raft knows that for reads to be consistent they need to go the same path as writes. In the Raft paper you can find a whole section about this.
If you check the paper there are the following clearly stated informations:
Leaders can't reply to read queries without doing additional checks otherwise the reads are not linearizable.
For the reads to be linearizable, the following two things must be performed by leaders.
1) Commit a NOP at the start of its term, which is not a problem from a performance point of view. The problem is "2".
2) A leader needs to check if it is still the leader before every read, and this requires to contact a majority. That's the performance problem of linearizable reads, because you need to pay a latency equal to the latency of the slowest reply of the N/2+1 acks you need.
However note that even linearizable reads don't require fsync() to be called, so they are still better than writes.
https://github.com/coreos/etcd/blob/master/Documentation/api...
What you found is not a bug, but a design decision.
Maybe the coreos people just should not assume that linearizability means the same thing to all people. And they should document it clearly.
> etcd does provide linearizability with regard to the
> logical clock index.
> No, it really doesn't. Reads are not monotonic w.r.t
> indexes. its invocations and responses can be reordered to yield a sequential history
that sequential history is correct according to the sequential definition of the object
if a response preceded an invocation in the original history, it must still precede it in the sequential reordering.
It is also possible for a leader to be demoted during a split, where the log of that partial transaction will not be counted as final. The new leader at this point can then force a truncation of a follower's log, or ignore it entirely.
The entry you have read from a node that was thought to still be a master without first consulting a majority is therefore possibly a bad write that won't be part of history as far as consensus goes.
This is explained later in the original Raft paper, and this is why you need to read from the quorum to be able to guarantee consistency under all circumstances, among other problem cases.
That's not fact, please don't state it as such. That's your opinion on modern day vernacular influencing an unrelated field/topic.
Perhaps you didn't actually read what I wrote, but I said I'm aware of how good their content is/can be. My issue is that a blog of that caliber is using something in our modern vernacular that has been beat to death and adds no actual value.
It'd probably do you best to read what people write instead of putting words in their text or assuming things outside of the scope of what they said...
On the actual critique: if you have had worked with eventually consistent database, a 'Call' record's presence is really a great pun on the 'call me maybe' phrase. I'm really sorry if you don't appreciate that part either.