On Feb 8, 2009, at 9:10 AM, Geir Magnusson Jr. wrote:
>
> On Feb 7, 2009, at 7:45 PM, Damien Katz wrote:
>
>>
>> On Feb 7, 2009, at 6:49 PM, Geir Magnusson Jr. wrote:
>>
>>>
>>> On Feb 7, 2009, at 6:05 PM, Damien Katz wrote:
>>>
>>>>
>>>> On Feb 7, 2009, at 5:08 PM, Geir Magnusson Jr. wrote:
>
> [snip]
>
>>> I understand - my POV is that they'd eventually get into a
>>> consistent state assuming the master doesn't go down.
>>>
>>> If the master goes down, they could, but that's what I think I'd
>>> get with what you are proposing nayway.
>>
>> When the master goes down and the slaves aren't in a consistent
>> state at the time, then they will never be until the master comes
>> up. Also the slaves won't know if they are in an consistent state
>> or not. If the master fails hard (disk failure), then slaves will
>> never regain consistency.
>
> But this remains possible in the change you are proposing?
>
Nope, because we don't make interdocument consistency guarantees. So
the database is never in an unacceptably inconsistent state.
>>
>>>
>>>
>>>>
>>>>
>>>> I think this works in situations where you have only a single
>>>> machine (no replication, no failover), or your app can have read
>>>> only slaves nodes where readers don't care about db consistency
>>>> (but still no failover). I'm not sure that fits many real world
>>>> use cases.
>>>
>>> But how is the end result different from what you are proposing to
>>> change to?and-fro
>>
>> The difference is the guarantee that is made about inter-document
>> consistency. The new model is to only guarantees that multi-
>> documents are safely saved to stable storage and won't be lost.
>> There may be conflicts, but the documents are still there,
>> completely intact individually.
>
> Which is what it does now too, right?
>
> I won't belabor this - I'm following the other thread - but I just
> have trouble understanding why the mode I'm thinking of has any
> bigger downside than what is being proposed, and why the benefit -
> the ability to do consistent writes on a single node (be it alone or
> a part of a cloud/cluster) is a bad thing.
Because that node must be bullet proof, if it goes down you may lose
all your inter-document consistency. No hot backup or failover can
save you. Any number of other databases can do this better than CouchDB
Couch stands for Cluster Of Unreliable Community Hardware. A single
node that cannot fail without violating application consistency is not
very Couch-y.
>
>
> I understand that there's no magic bullet here - that the non-
> transactional replication means that slaves can be momentarily
> inconsistent (or persistently in the case of catastrophic failure of
> the master) but assuming the master lives or can be brought back,
> the data will be eventually consistent. However, it seems valuable
> to have the option for system designers of multi-node system (and
> single-node users as well) to be able to do consistent writes.
>
> Also, to be clear, I'm not arguing against adding new modes - just
> advocating the protection of what I see an existing and useful mode.
And the existing mode can simulated easily from a front end server ,
so if you are willing to put up will all the downsides and things that
don't work (or maybe ignorant of its downsides, which is why I don't
want to make it a real feature), then you can have transactions will
full conflict checking. You just don't get to use those other features
and maintain consistency.
-Damien
>
>
> geir
>
>
>
|