diff --git a/doc/CONSISTENCY.md b/doc/CONSISTENCY.md index a9fbc5da..d1bc138b 100644 --- a/doc/CONSISTENCY.md +++ b/doc/CONSISTENCY.md @@ -9,10 +9,13 @@ This is why rqlite offers read consistency levels of _none_, _weak_, and _strong With _none_, the node simply queries its local SQLite file, and does not even check if it is leader. This offers the fastest query response, but suffers from the problems listed above. _Weak_ instructs the node to check that it is the leader, before querying the local SQLite file. Checking leader state only involves checking local state, so is still very fast. There is, however, a very small window of time (milliseconds by default) during which the node may return stale data. This is because after the leader check, but before the local SQLite file is read, another node could be elected leader. As result the node may not be up-to-date with the rest of cluster. To avoid even this possibility, rqlite also offers _strong_. In this mode, rqlite sends the query through Raft consensus system, ensuring that the node remains the leader throughout query processing. However, this will involve the leader contacting at least a quorum of nodes, and will therefore increase query response times. -_Weak_ is probably sufficient for most applications, and is the default read consistency level. To explicitly select consistency, set the query param `level`. Examples of enabling each read consistency level for a simple query is shown below. +_Weak_ is probably sufficient for most applications, and is the default read consistency level. To explicitly select consistency, set the query param `level`. + +## Example queries +Examples of enabling each read consistency level for a simple query is shown below. ```bash curl -G 'localhost:4001/db/query?level=none' --data-urlencode 'q=SELECT * FROM foo' curl -G 'localhost:4001/db/query?level=weak' --data-urlencode 'q=SELECT * FROM foo' curl -G 'localhost:4001/db/query?level=strong' --data-urlencode 'q=SELECT * FROM foo' -``` \ No newline at end of file +```