These are chat archives for atomix/atomix

14th
Sep 2016
terrytan
@txm119161336_twitter
Sep 14 2016 02:06
I have a question about commit , i have seen ,for commit ,you did not persist the index to disk , every time flush , you record the commit index , and flush all the entries to the disk , is there any reason for you to do so ?
Jordan Halterman
@kuujo
Sep 14 2016 05:43
Refreshing my memory...
Jordan Halterman
@kuujo
Sep 14 2016 05:50
@txm119161336_twitter if you're referring to persisting the commit index, that index is never persisted to disk. That's just part of the Raft specification. The commitIndex is held only in memory since it can always be rebuilt from the log. The leader election algorithm ensures that any node that's elected leader will have all committed entries, so there's no risk of losing commits by losing the commit index. As for flushing entries to disk, they're only flushed when a node increases its commit index to reduce the frequency of flushes to disk. This is more for the leader and really should only be done on the leader since followers should be flushing to disk after writing a batch. Will have to change that.
But it's safe for the leader to flush to disk last since no nodes will have committed or applied their entries prior to the leader doing so, so flushing on the leader when it commits entries is fine. That shouldn't really be done on followers though.
terrytan
@txm119161336_twitter
Sep 14 2016 06:38
thank you for your reply , every time after the leader append entries or flush the entries to the disk ,it is actully being persisted to the disk ,but the followers will only flush the entries which leader has committed , so whenever leader crashed , the successor leader will only have the entries which has been committed
Jordan Halterman
@kuujo
Sep 14 2016 16:47
@txm119161336_twitter that's right, but that's technically incorrect. Followers should be flushing every batch to disk. Whether the leader committed it should have no bearing on whether a follower flushes writes to disk because when the leader does determine an entry committed it should be able to assume that entry has already been stored on disk on quorum -1 nodes, such that once the leader flushes the entry to disk it knows the entry will have been stored on disk on quorum nodes. The order in which the leader flushes to disk with respect to followers doesn't matter, just that once the leader says an entry is committed it's on disk on a majority of the cluster. This is a bug that needs to be fixed AFAICT.
Basically, all that does matter is that followers have written an entry to disk before the leader increases the commitIndex and tells any node that an entry has been committed. That's likely happening the majority of the time now, but I can see a case where it wouldn't happen during low load.
flushed
Mauricio Santiago de Castro
@mauricioscastro
Sep 14 2016 18:41
newbie question: haven't cloned yet, but I am curious how "resources" are persisted. is there a db involved?
Jordan Halterman
@kuujo
Sep 14 2016 21:40
So, "resources" are persisted by the Raft consensus algorithm. A resource is just an object backed by a replicated state machine which is backed by Raft. That is, Atomix is the database. You can configure the Storage object to write to disk or hold state in memory, and the state for a resource is simply replicated among the nodes in the cluster. An AtomixReplica will store the state of resources locally and replicate them to other nodes. An AtomixClient will connect to replicas remotely to access resource state.