From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Bojidar Mihajlov <bmihajlov(at)yahoo(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Slony-I for circular replication |
Date: | 2006-03-30 14:15:40 |
Message-ID: | 442BE80C.4070105@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-03-30 14:34:46 | Re: Chasing "signal 11" issues |
Previous Message | Kai Hessing | 2006-03-30 14:09:38 | Performance Killer 'IN' ? |