On 6/24/2008 4:39 PM, Troy Wolf wrote:
> I have had what I'd consider to be the most common replication setup:
> 2 database servers, 1 origin, 1 subscriber, 1 replication set. Slony
> replication has been working well for months. The situation is
> changing. See Node 3 below.
> 
> Node 1 - the origin and main application database
> Node 2 - the subscriber and main application backup database
> Node 3 - a special database that only needs a subset of the main
> application tables
> 
> I configured Node 2 to allow it to forward.

That's a bit difficult at first (until you get the picture). Since every 
table can only be a member of one set, in order to have "shared" as well 
as "individual" subscription sets, one has to create more sets.

Let's say you have tables A, B and C. There are nodes X, Y and Z with X 
being the origin. Now you want A and C replicated to Y and B and C 
replicated to Z. So A goes into set 1, B into set 2, C into set 3 and 
then Y subscribes to 1+3 and Z subscribes 2+3.

There is a lot of special logic inside of slon that ensures that tables 
in different sets, that origin on the same node, are sync'd together. So 
this setup will not break integrity on the subscribers.


Jan

> 
> My thought was that I'd create a second replication set containing
> only the subset of tables needed for Node 3 and use Node 2 as the
> origin.
> 
> When I try to create the set, I get a PGRES_FATAL_ERROR:  duplicate
> key violates unique constraint "sl_table_tab_reloid_key"
> 
> So it appears I can't have a single table in more than one replication
> set? How do I accomplish what I want?
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general


-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin