Raft (algorithm): Difference between revisions

Revision as of 15:22, 27 August 2018

Revision as of 11:54, 29 August 2018

Line 52:

* ''electionTimeout'' is the same as described in the Leader Election section. It is something you must choose.

Typical number for these values can be 0.5ms to 20ms for ''broadcastTime'', which implies that you set the ''electionTimeout'' somewhere between 10ms and 500ms. It can take several weeks or months between single server failures, which means the values are all right for a stable cluster to work.

=== Database Use Cases ===

Below is a list of prominent databases implementing and utilizing the Raft consensus algorithm to maintain consistency with replication.

* [[ArangoDB]]<ref>{{cite web|url=https://docs.arangodb.com/3.0/Manual/Scalability/Architecture.html|title=Structure of an ArangoDB Cluster - ArangoDB|publisher=}}</ref>

* [[CockroachDB]]<ref>{{cite web|url=https://www.cockroachlabs.com/docs/stable/architecture/replication-layer.html#raft|title=Replication Layer - CockroachDB|publisher=}}</ref>

* [[Neo4j]]<ref>{{cite web|url=https://neo4j.com/docs/operations-manual/current/clustering/multi-data-center/design/|title=Multi-Data Center Design - Neo4j|publisher=}}</ref>

* [[SQLite]]<ref>{{cite web|url=https://github.com/rqlite/rqlite|title=Github SQLite Repository - Github|publisher=}}</ref>

* [[YugabyteDB]]<ref>{{cite web|url=https://docs.yugabyte.com/latest/architecture/concepts/replication/|title=Data Replication with Raft Consensus - Yugabyte|publisher=}}</ref>

== References ==