On 08/02/2009, at 12:05 PM, Damien Katz wrote:
But if the replication doesn't complete, like in the middle you lose
your connection, then the downstream db is in an inconsistent state
and will be until you regain the connection and complete the
replication.
Sure, that's OK. In my case there are potentially millions of
'downstreams'.
And its not just the downstream dbs that can't be used during active
or interrupted replication, it's the central db as well. If you want
to update it, you'll have to shut down access while waiting for any
in progress replications to complete, then perform the update then
reopen replication access.
I can't see why this needs to be the case. The fact that there are
peers that have an incomplete replication doesn't stop the master
taking updates - iff the updates to the master are multi-document ACID.
In my case, replication can occur from any peer that isn't itself
replicating, and has completed a valid replication cycle.
The key thing being, even with multiple writers i.e. symmetric peers,
that replication occurs between nodes that are themselves consistent
e.g. conflicts are never replicated, they are only the result of
replication, and the node is locked until a replication cycle
completes (or is abandoned, which is a separate issue that I have to
address).
Am I missing something?
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B
will do it very easily and for a very reasonable price, but I don't
want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and
$CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas on
how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct tape,
an iPod, and hours and hours of my precious time.
-- Slashdot response to an enquiry
