Re: Slony-I for circular replication

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

In response to

Browse pgsql-general by date

  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' ?