These are chat archives for atomix/atomix

27th
Oct 2017
Jordan Halterman
@kuujo
Oct 27 2017 01:23

@adagys there's no reason Raft in general can't handle large logs. Atomix's log is designed for fast sequential reading and writing and multiple pointers in a file (RaftLigReader and RaftLogWriter). There's not much overhead aside from the actual disk access.

Scaling like Kafka is then just a matter of sharding the cluster. We do this in ONOS and it will soon be done in Atomix as well. Just create multiple Raft clusters and partition the writes among them by a key or round robin.

Maybe I can find some time to hack together a Raft session that writes/reads the Raft log. It would be really straightforward.

Jordan Halterman
@kuujo
Oct 27 2017 01:30
@zheilbron you're right. The usage of fencing tokens is the ideal solution, but usually isn't possible in a lot of distributed systems. It requires interacting with some system that supports a fairly complex atomic operation to be done safely. Epochs are much more useful in replication protocols. So using session timeouts is the next best solution. It's imperfect but not much in distributed systems is. The SUSPENDED state change is almost always going to be a reliable indicator that a leader change may occur in the future and should always occur before the leader change actually does happen, assuming clocks are progressing at a fairly consistent rateZ
rate*