couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <>
Subject Could CouchDB 2.0 fix actual read quorum?
Date Tue, 24 Mar 2015 21:06:44 GMT
Sorry, I have not been following CouchDB 2.0 roadmap but I was extending my fermata-couchdb
plugin today and realized that perhaps the Apache release of BigCouch as CouchDB 2.0 might
provide an opportunity to fix a serious issue I had using Cloudant's implementation.

See for some additional
background/explanation, but my understanding is that Cloudant for all practical purposes ignores
the read durability parameter. So you can write with ?w=N to attempt some level of quorum,
and get a 202 back if that quorum is unment. _However_ when you ?r=N it really doesn't matter
if only <N nodes are available…if even just a single available node has some version
of the requested document you will get a successful response (!).

So in practice, there's no way to actually use the quasi-Dynamo features to dynamically _choose_
between consistency or availability — when it comes time to read back a consistent result,
BigCouch instead just always gives you availability* regardless of what a given request actually
needs. (In my usage I ended up treating a 202 write as a 500, rather than proceeding with
no way of ever knowing whether a write did NOT ACTUALLY conflict or just hadn't YET because
$who_knows_how_many nodes were still down…)

IIRC, this was both confirmed and acknowledged as a serious bug by a Cloudant engineer (or
support personnel at least) but could not be quickly fixed as it could introduce backwards-compatibility
concerns. So…

Is CouchDB 2.0 already breaking backwards compatibility with BigCouch? If true, could this
read durability issue now be fixed during the merge?


* DISCLAIMER: this statement has not been endorsed by actual uptime of *any* Couch fork…
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message