incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: delayed_commits false
Date Wed, 07 Jul 2010 12:29:54 GMT

On 7 Jul 2010, at 14:20, Benoit Chesneau wrote:

> On Wed, Jul 7, 2010 at 1:40 PM, Jan Lehnardt <jan@apache.org> wrote:
>> 
>> On 7 Jul 2010, at 08:31, Benoit Chesneau wrote:
>> 
>> I dislike to have too much options though.
>>> 
>>> @damien
>>> I don't understand this "keep it for 1.0" mantra. Since it's more a
>>> "philosophical" change than a technical one, I would prefer that
>>> change on 1.0 whatever this number means. How do people  use CouchDB
>>> in production ? Is delayed_commit turned off most of the time ?
>> 
>> I am with Damien, all other releases ship with the current default setting.
>> Changing it *a day* before 1.0 does not sound like the way to go.
>> 
>> 
> 
> right, it may be too late to do that now.
> 
> Anyway rereading the doc we provide, I think delayed_commit don't
> break the promise since db is always in consistent state.

"consistent state" means CouchDB can start up and use that db
without andy fixup phase (c.f myisamchk, or InnoDB log-replay).


> But we may need like you said, to clarify some docs imo and maybe give
> to users some tricks to help them to flush to disk before any machine
> shutdown or such ?
> 
>>> About the use on laptop and co, laptops are likely less stable than
>>> server machines, and we tend to shutdown them more often too. With
>>> delayed_commit=True, when someone shutdown his laptop and forget to
>>> apply delayed commit (and most of the time, if we don't automatize
>>> that, I bet he will), data in memory will be lost.
>> 
>> I remember two instances of data loss with CouchDB 0.7 on Mac OS X
>> when Erlang wasn't using the fully reliable FULLFSYNC option to flush
>> data to disk (which is btw more reliable than on any other system). After
>> we patched Erlang to do the right thing on Mac OS X, I haven't heard
>> of a single instance of data loss on a laptop or anywhere else.
>> 
>> 
> 
> There was a recent discussion about couchdb shutdown that was raised
> by this default settings. In my case I never lost data but just
> because I set couchdb as the last to shutdown.

Are you referring to the init script (ours?) that should send a 
POST /_ensure_full_commit before killing CouchDB?

If it is our script, we need to fix it (not a blocker, I'd say).
If it is somebody else's script, we should get in touch and help
getting it fixed.


>>> As a user of openbsd, one of the reasons I use this system (except
>>> its simplicity) is that it is secured by default on the contrary most
>>> linuxes/bsds aren't. Most of the openbsd users know that security will
>>> impact performances. I think I would prefer to have a completly safe
>>> couchdb even if performances decreased.
>> 
>> This brings up an interesting point: we ship the CouchDB source.
>> Most users use CouchDB through some distribution (apt-get, rpm,
>> CouchDBX etc.). The distributors should decide for their users which
>> setting is best.
>> 
> 
> That's indeed a way to handle that, this is again a doc problem I guess.
> 
>> Again, I'd like to keep the default we had forever and commence
>> with the release of 1.0.
> 
> for both reasons here, you have my +1 :)

Hooray :)

Cheers
Jan
-- 


Mime
View raw message