5 ms·

This is up for debate but this[0], IMHO, is pretty much the gold standard of explaining distributed algorithms. [0] - http://thesecretlivesofdata.com/raft/ htt

This is up for debate but this[0], IMHO, is pretty much the gold standard of explaining distributed algorithms. [0] - http://thesecretlivesofdata.com/raft/ http://thesecretlivesofdata.com/raft/

atmosx 12y ago
That's impressive, thanks for sharing.
jackmaney 12y ago
Neat. Thanks!
DAddYE 12y ago
I agree, I would also add that Paxos seems exceptionally hard to get it right or at least this was what I saw so far in popular projects (i.e. Cassandra) that use it.
deleted 12y ago
[deleted]
nacs 12y ago
Thanks the presentation, helps a lot. Quick question though. On this slide ( http://i.imgur.com/m02CMxx.png http://i.imgur.com/m02CMxx.png ) it shows a network split condition and shows how the 2 split networks will eventually negotiate and the 3 node split wins because it had a majority while the 2 node side's uncommitted changes are thrown out. What happens if the split happens right down the middle (3 active nodes on each side instead of the 2 and 3)? Wouldn't both sides elect leaders that both have majorities with committed data?
- deleted 12y ago
  [deleted]
  - nacs 12y ago
    Ah, thanks for the response. I didn't realize the majority encompassed the entire cluster and not just a majority within the split.
    - Retr0spectrum 12y ago
      Surely that means that none of the nodes will reach a concensus, so the cluster cannot be updated?
      - nacs 12y ago
        I assumed the same thing from that response. Does the cluster just remain in a read-only mode during that time? Maybe someone else knows.
      - matchu 12y ago
        My first thought for solving that problem would be to always have an odd number of nodes, but I'm interested in how Raft actually handles it, too.
        deathanatos 12y ago
        > My first thought for solving that problem would be to always have an odd number of nodes, but I'm interested in how Raft actually handles it, too. You don't need an odd number of nodes. Raft requires that a majority of the cluster be able to communicate in order to make forward progress. In the event that a majority can't communicate, no changes to the cluster can be made. This isn't particularly unique to Raft; any distributed consensus algorithm that wishes to maintain consistency has this: if your cluster is split in such a way that a majority can't communicate, you can't both accept writes and prevent the cluster from becoming "split-brained", i.e., having two states, one on each side of the split. If a majority of nodes can communicate, you know that your side of the split is unique in this regard, and can thus keep going. All other splits, not having a majority, will not be able to accept writes. A note about majorities: The definition of majority is "_More than half_ (50%) of some group"; in a cluster of size 5, this is at least 3. In a cluster of size 6, this is at least _4_. Because it is more than half (and not just half), even sized clusters are just fine in Raft: in a 3/3 split in a size 6 cluster, neither side has majority by definition.

This is up for debate but this[0], IMHO, is pretty much the gold standard of explaining distributed algorithms. [0] - http://thesecretlivesofdata.com/raft/ http://thesecretlivesofdata.com/raft/

atmosx 12y ago

That's impressive, thanks for sharing.

jackmaney 12y ago

Neat. Thanks!

DAddYE 12y ago

I agree, I would also add that Paxos seems exceptionally hard to get it right or at least this was what I saw so far in popular projects (i.e. Cassandra) that use it.

deleted 12y ago

[deleted]

nacs 12y ago

Thanks the presentation, helps a lot. Quick question though. On this slide ( http://i.imgur.com/m02CMxx.png http://i.imgur.com/m02CMxx.png ) it shows a network split condition and shows how the 2 split networks will eventually negotiate and the 3 node split wins because it had a majority while the 2 node side's uncommitted changes are thrown out. What happens if the split happens right down the middle (3 active nodes on each side instead of the 2 and 3)? Wouldn't both sides elect leaders that both have majorities with committed data?

deleted 12y ago
[deleted]
- nacs 12y ago
  Ah, thanks for the response. I didn't realize the majority encompassed the entire cluster and not just a majority within the split.
  - Retr0spectrum 12y ago
    Surely that means that none of the nodes will reach a concensus, so the cluster cannot be updated?
    - nacs 12y ago
      I assumed the same thing from that response. Does the cluster just remain in a read-only mode during that time? Maybe someone else knows.
    - matchu 12y ago
      My first thought for solving that problem would be to always have an odd number of nodes, but I'm interested in how Raft actually handles it, too.
      - deathanatos 12y ago
        > My first thought for solving that problem would be to always have an odd number of nodes, but I'm interested in how Raft actually handles it, too. You don't need an odd number of nodes. Raft requires that a majority of the cluster be able to communicate in order to make forward progress. In the event that a majority can't communicate, no changes to the cluster can be made. This isn't particularly unique to Raft; any distributed consensus algorithm that wishes to maintain consistency has this: if your cluster is split in such a way that a majority can't communicate, you can't both accept writes and prevent the cluster from becoming "split-brained", i.e., having two states, one on each side of the split. If a majority of nodes can communicate, you know that your side of the split is unique in this regard, and can thus keep going. All other splits, not having a majority, will not be able to accept writes. A note about majorities: The definition of majority is "_More than half_ (50%) of some group"; in a cluster of size 5, this is at least 3. In a cluster of size 6, this is at least _4_. Because it is more than half (and not just half), even sized clusters are just fine in Raft: in a 3/3 split in a size 6 cluster, neither side has majority by definition.