Bojidar Mihajlov wrote:
Hi All;
Can Slony-I be used for circular replication (A
<replicates> B <replicates> A)
or there is some kind of problem with locking or
anything else?
No - Slony is an asynchronous single-master replication scheme. As such
changes are only allowed at a "master" node.
You might want to look at pgpool which I believe can send queries to two
systems at the same time and sort of do this.
If I avoid insert conflicts will the following
scenario succeed for the updates :
A: X.balance-= 5
B: X.balance-= 3
A receives the update from B (X.balance -= 3)
B receives the update from A (X.balance -= 5)
or it will lead to deadlock ?
No - see above.
Nodes A and B will reside at different geografical
locations.
I'll use only node A to service both locations in the
most time and B for redundancy.
Hmm - OK. So that's A=>B, simple enough.
But the case of broken connection between node A and B
could lead to scenarios
like latter because then A and B will service their
own location.
Don't do that (unless you have no choice). It's much simpler (and
probably cheaper) to have a separate network connection to "A".
> Could such a scenarios
be detected and logged ?
>
What happen in case of a conflict (dublicated primary
key/update deleted) ?
No replication system in existence handles conflicts like this
automatically. The "meaning" of a conflict is something that depends on
the application and its context. You would need to handle conflicts
yourself.
What I would do is have replication A=>B with a failover should "A"
become unavailable. If the link between A/B is broken, you'll need your
own system for failover since you'll need to decide whether it's because
one of the databases failed or a more general network problem. If it's
the network, then you'll just have to live without updates for clients
that can only see "B".
HTH
--
Richard Huxton
Archonet Ltd
