Content deleted Content added
Citation bot (talk | contribs) Alter: title, last2. Add: date, authors 2-2. | Use this bot. Report bugs. | Suggested by Dominic3203 | Category:Distributed algorithms | #UCB_Category 16/41 |
m v2.05b - Bot T20 CW#61 - Fix errors for CW project (Reference before punctuation) |
||
| (2 intermediate revisions by one other user not shown) | |||
Line 66:
* ''electionTimeout'' is the same as described in the Leader Election section. It is something the programmer must choose.
Typical numbers for these values can be 0.5 ms to 20 ms for ''broadcastTime'', which implies that the programmer sets the ''electionTimeout'' somewhere between 10 ms and 500 ms. It can take several weeks or months between single server failures, which means the values are sufficient for a stable cluster.
== Extensions ==
The dissertation “Consensus: Bridging Theory and Practice” by one of the co-authors of the original paper describes extensions to the original algorithm:<ref>{{Cite web |title=CONSENSUS: BRIDGING THEORY AND PRACTICE|url=https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf}}</ref>
* Pre-Vote: when a member rejoins the cluster, it can depending on timing trigger an election although there is already a leader. To avoid this, pre-vote will first check in with the other members. Avoiding the unnecessary election improves the availability of cluster, therefore this extension is usually present in production implementations.
* Leadership transfer: a leader that is shutting down orderly can explicitly transfer the leadership to another member. This can be faster than waiting for a timeout. Also, a leader can step down when another member would be a better leader, for example when that member is on a faster machine.
== Production use of Raft ==
| |||