Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.219.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55CCE097-9D63-4E28-8873-698AB57822E8@van-cuijk.nl>
References: <55CCE097-9D63-4E28-8873-698AB57822E8@van-cuijk.nl>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Tue, 23 Apr 2013 15:06:20 -0500
Message-ID: 
 <CAJ_m3YAGELoGngqmqOacO+WTkSk-yXDC7afZBxwL2MxK=2Bi5g@mail.gmail.com>
Subject: Re: Questions on durability
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 23, 2013 at 2:37 PM, Mark van Cuijk <mark@van-cuijk.nl> 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