I wonder if there could be something between None and Weak...
Don't check if it's the leader, but rather check (ideally locally, via some sort of flag that is updated on writes - when it's going to be communicating with the cluster anyway) if it's still part of the cluster/quorum. If so, then read locally. If not... reject the request since it might be stale?
The idea is that it is stronger than None, but weaker than doing reads (or any communication at all at read-time) from the Leader.
Comments
I wonder if there could be something between None and Weak...
Don't check if it's the leader, but rather check (ideally locally, via some sort of flag that is updated on writes - when it's going to be communicating with the cluster anyway) if it's still part of the cluster/quorum. If so, then read locally. If not... reject the request since it might be stale?
The idea is that it is stronger than None, but weaker than doing reads (or any communication at all at read-time) from the Leader.
rqlite creator here.
What you're describing sounds like "none", but adding the "limit read staleness" requirement. That is described in the docs.
https://rqlite.io/docs/api/read-consistency/#limiting-read-s...
Thanks! Yes that sounds more or less what I was thinking
I'm sure there's a reason but I would expect a system like this to use leader leases for local reads
rqlite creator here -- it's on my list to examine, not clear to me if it would add much beyond what is offered today. But it might.