couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark van Cuijk <>
Subject Re: Questions on durability
Date Tue, 23 Apr 2013 20:42:58 GMT
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.

View raw message