incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Questions on durability
Date Tue, 23 Apr 2013 20:45:18 GMT
Great, then the only setting you need to change is this;

curl host:5984/_config/couchdb/delayed_commits -X PUT -d '"false"'


On 23 April 2013 21:42, Mark van Cuijk <> wrote:
> Thank you both for your answers!
> On Apr 23, 2013, at 22:06 , Paul Davis <> wrote:
>>> 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.
> The first part is actually a requirement, the second part is optional. There's no need
to check this, we just shouldn't assume equal ordering when monitoring those feeds.
>>> 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.
> I've read up on delayed_commits and this makes perfect sense. Are there any particular
configuration options you are referring to with the phrase "given a proper config" or will
it be enough to read up on documentation and use common sense?
>>> 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.
> That's exactly what we're looking for. In fact, this behaviour allows us to accept the
relaxed durability guarantees of batch=ok, because we'll only rely on the changes feed to
decide what documents are durably stored. Our architecture will be capable of recovering from
server failures in the critical components.
> Thanks,
> Mark

View raw message