alihan/rqlite-distributed-sql
1
0
Fork 0
mirror of https://github.com/rqlite/rqlite.git synced 2022-10-30 02:37:32 +03:00
Code Issues Packages Projects Releases Wiki Activity

Update CONSISTENCY.md

Browse Source
This commit is contained in:
Philip O'Toole
2022-10-24 09:52:40 -04:00
committed by GitHub
parent 27b8409da9
commit 1c082b1269
1 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
DOC/CONSISTENCY.md
View File

@@ -29,7 +29,9 @@ If a query request is sent to a follower, and _strong_ consistency is specified,
To avoid even the issues associated with _weak_ consistency, rqlite also offers _strong_. In this mode, the Leader sends the query through the Raft consensus system, ensuring that the Leader **remains** the Leader at all times during query processing. When using _strong_ you can be sure that the database reflects every change sent to it prior to the query. However, this will involve the Leader contacting at least a quorum of nodes, and will therefore increase query response times.
# Which should I use?
_Weak_ is probably sufficient for most applications, and is the default read consistency level. To explicitly select consistency, set the query param `level` to the desired level. However, you should use _none_ with read-only nodes, unless you want those nodes to actually forward the query to the Leader.
_Weak_ is probably sufficient for most applications, and is the default read consistency level. Unless the leader on your cluster is continually changing there will be no difference between _weak_ and _strong_ -- but using _strong_ will result in more Raft traffic, which is not what most people want.
To explicitly select consistency, set the query param `level` to the desired level. However, you should use _none_ with read-only nodes, unless you want those nodes to actually forward the query to the Leader.
## Example queries
Examples of enabling each read consistency level for a simple query is shown below.