Hi, They are not votes. we are simply waiting to hear the first two of the total of three expected responses before returning a response to the client. No node will revert its write if another node fails its write. each of the three nodes might return a different status code due to ordering (e.g, one node might return 201 for a write and another node might return 409, which ends up adding a conflict into the document).
couchdb uses the shard map to know which nodes should host the document (based solely on its id) and directs reads and writes to those nodes only, correct. If no node that hosts the range is available you will get an error trying to read or write a document in that range and no write happens; there is no "hinted handoff" in our variant of dynamo. If the above happens for all ranges then, yes, all reads and writes for that database will fail. B. > On 14 Jun 2023, at 09:22, Luca Morandini <[email protected]> wrote: > > On Wed, 14 Jun 2023 at 17:23, Robert Newson <[email protected]> wrote: > >> >> There are no votes, no elections and there are no leader nodes. >> > > As I see it, when there is a quorum to reach there is an implicit voting, > but never mind. > > > When couchdb believes nodes to be down, the quorum is implicitly lowered to >> avoid the latency penalty. >> > > So, it is kind of a "soft quorum". > > Going back to my original question: only the nodes that host the shards are > queried, but when there are not enough surviving nodes the quorum is > lowered. > > As a corollary, I assume that when at least one shard is no > longer reachable (no one of the surviving nodes hosts it) the cluster stops > accepting requests on that database: is that so? > > Thanks for the answer, > > Luca Morandini
