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.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <09121212-0E75-4E82-A121-3DD8DBA2D2AB@van-cuijk.nl>
References: <55CCE097-9D63-4E28-8873-698AB57822E8@van-cuijk.nl>
 <CAJ_m3YAGELoGngqmqOacO+WTkSk-yXDC7afZBxwL2MxK=2Bi5g@mail.gmail.com>
 <09121212-0E75-4E82-A121-3DD8DBA2D2AB@van-cuijk.nl>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Tue, 23 Apr 2013 15:48:58 -0500
Message-ID: 
 <CAJ_m3YAQD=MTyD3hxaggFzk9ARLZmVv5F_KVqN5set_8tm_JzQ@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
Content-Transfer-Encoding: quoted-printable

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> wrot=
e:
>
>>> 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. Th=
ere's no need to check this, we just shouldn't assume equal ordering when m=
onitoring 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 a=
ny particular configuration options you are referring to with the phrase "g=
iven 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=3Dok parameter influences the response to the writing clie=
nt, but does it have any influence regarding the answer to the previous que=
stion?
>>>
>>
>> No. batch=3Dok 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=3Dok, because we'll on=
ly rely on the changes feed to decide what documents are durably stored. Ou=
r architecture will be capable of recovering from server failures in the cr=
itical 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=3Dok 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