[linux-elitists] etcd: A highly-available key value store

Andrew Cowie andrew at operationaldynamics.com
Tue Aug 13 17:58:13 PDT 2013


On Tue, 2013-08-13 at 12:03 -0700, Greg KH wrote:

> Although, in skimming this, it might just be a limitation that the
> go-raft implementation that is in etcd, as I couldn't find any size
> limitations in the raft paper, but I could have missed them.

There aren't limitations in the raft protocol, as such (modulo time for
clients to actually transmit information, but you'd think that volume is
going to be << available bandwidth over time), but you do have to pay
attention to the log compaction issue; it's non-trivial to know when a
consensus node can safely discard an entry in its log. So log size, over
time, might be a limitation for you. There's an interesting PDF hanging
off this page (which I found out because it was basically extracted from
the original paper):
https://ramcloud.stanford.edu/wiki/display/logcabin/Compaction 

There are a quite a few people working on raft implementations:
https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin

AfC
Sydney




More information about the linux-elitists mailing list