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:48:58 GMT
On Tue, Apr 23, 2013 at 3:42 PM, 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?

Off the top of my head "proper config" for you would just require
disabling delayed commits and not disabling the fsync defaults. Beyond
that you should be good to go.

>>> 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.

Bob and I were discussing this on IRC and realized our answers were a
bit conflicting. It sounds like you got it, but for posterity the
important bits are this:

A client submitting a batch=ok write request will get an Accepted
response before the doc is durably written to disk.

A client reading the _changes feed won't see a write until after it
was written durably to disk.

> Thanks,
> Mark

View raw message