couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
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"'

B.

On 23 April 2013 21:42, Mark van Cuijk <mark@van-cuijk.nl> wrote:
> Thank you both for your answers!
>
> On Apr 23, 2013, at 22:06 , Paul Davis <paul.joseph.davis@gmail.com> 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

Mime
View raw message