couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
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 <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.
>

Exactly.

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

Mime
View raw message