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:
On Feb 7, 2009, at 11:22 AM, Damien Katz wrote:
On Feb 7, 2009, at 11:02 AM, Geir Magnusson Jr. wrote:
Thanks for the info. Is there a third mode possible? Namely
all or nothing with conflict check, with the understanimg that
the conflict guarantee is only at commit, and all bets are off
after that when replicated?
That's what we currently have. It's possible to keep supporting
it, but it doesn't work with any of CouchDB's distributed
features. It's only appropriate for a single node instance, even
a hot standby slave will have inconsistent states.
Sure... Assuming we're defining things the same way, I think that
the existing mode still might be useful - I could consider a node
to be the "reference master" for my data (or a subset) and vector
all writes there with whatever consistency promises I get from a
single node, and then everyone else will be eventually consistent,
and I'd know that the eventually consistent nodes have a
transactionally consistent data set?
I realize I may not attach the same meaning to concepts, but can
you get a sense of what I'm saying?
So a single master node that always in a valid state, inter-
document wise, but slaves nodes are in an unknown inter-document
state (could be a valid state, could be a inconsistent,
transitional state). Unfortunately it can't be used for failover
purposes as the slaves nodes might be in inconsistent inter-
document states. And if the readers need to read dbs in a
consistent state, then it doesn't work for read-only slaves either.
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.
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.
An example where this is useful in the case where you want rename, or
move, a document. This involves deleting one document and creating
another. It may be acceptable that temporarily there are 2 or 0 copies
of the document as the replication works out, but we know that
eventually we'll have the documents in the correct final states.
-Damien
geir
-Damien
