On 9/8/2007 9:07 PM, Tim Bowden wrote:
> Hi,
> 
> I'm looking at using slony for the first time.  I'd like to know if it's
> possible to have different tables in a slave db replicated from
> different master db's.

It was part of the initial concept and the initial implementation. If it 
doesn't work now, that'd be a bug.

> Just to outline the setup I'm looking at, I have (proposed) master db's
> that are distributed in various geographical areas for performance
> reasons that need to be replicated back to a central slave.  The
> critical table in each master db (the only table needing to be
> replicated) would have an identical data structure and RI model (except
> for a constraint limiting the pk to that properly belonging to that
> particular master db).
> 
> If possible the slave tables would actually be partitions of a "whole of
> system" slave db (ie, children in a table inheritance relationship) in
> order to provide a view of all the data in one slave table, though from
> a first reading of the docs I suspect this is not possible as the table
> schemas would be different from master to slave.

As of right now, slon itself cannot change the table or namespace on the 
fly during replication. So every table that is actually replicated 
inside of your cluster must have a unique fully qualified name. This 
could in your case be achieved by creating a partition structure where 
even on the different origin servers, the table in question has an 
(always empty) master and just the one, location specific child 
partition. The central slave then would have all those partitions and 
replicate into them. That way, the application would see the same table 
name everywhere, containing the site specific data.

As another idea, if any site only ever updates its own key range, 
nothing would prevent you from having all partitions everywhere. Each 
location would be origin of one partition while every other location 
would subscribe to it. That way, the "local" data is read/write and all 
remote data is available readonly. Slony doesn't distinguish between 
master and slave nodes. Since every table can have a different "origin", 
each node can actually be master and slave at the same time, with 
respect to different tables, that is.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #