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
