incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Questions on durability
Date Tue, 23 Apr 2013 20:06:20 GMT
On Tue, Apr 23, 2013 at 2:37 PM, Mark van Cuijk <> wrote:
> Hi,
> For a new project, we're considering CouchDB as an interesting candidate for storage,
mainly because of the good durability properties, support for replication and the continuous
changes feed.
> Regarding durability I have three questions. I found the durability matrix on the wiki,
but the page isn't finished yet. Our setup will be a single client writing to a single CouchDB
server, which is replicated to several other CouchDB servers.
> 1. Can I access the continuous changes feed on each of the servers and will those feeds
serve the same events in the same order?

Yes to the first half. Individual nodes will have their own changes
feeds which you can listen to. To the second half, you shouldn't rely
on that. While its possible that it appears to work in some
circumstances its not at all guaranteed. I'd have to go back and look
but I think even if you had a read-only slave, the worker pools in
replication don't guarantee the exact ordering of updates.

> 2. Will each server only send events to the changes feed after the data is durably persisted
to hardware storage?

Assuming you turn of delayed_commits and don't disable the fsyncs
before and after header writes, then yes you're guaranteed to be
reading changes from an MVCC snapshot which (given a proper config)
would be guaranteed to be on disk.

> 3. The batch=ok parameter influences the response to the writing client, but does it
have any influence regarding the answer to the previous question?

No. batch=ok is more or less a fire-and-forget approach to writing
documents. The client basically gets a notification that the document
parsed ok but has not yet been written. The changes feed still won't
see it till it gets through the database updater process which is
exactly the same process as above.

Although it is important to note that batch=ok means the client could
see a 202 (IIRC) "successful" response and that write may never make
it to the _changes feed if CouchDB crashes at just the right time.

> Thanks,
> Mark

View raw message