On Sun, 2007-09-09 at 17:27 -0400, Jan Wieck wrote:
> 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.
> 

Ah yes, this would simplify things.  Thanks.

> 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.
> 
> 

I want to avoid communications between outlying nodes.  If my
understanding is correct, this is what would lead to the exponential
growth in comms that has been flagged as a problem with so many nodes.
Each outlying node also has no need of data collected at any other node.
In this case, it's very much location specific (geometries and
associated attribute data in a postgis database).  If each outlying node
replicates only with the central node, does this problem become
manageable?  Is it possible (or needed) to "hide" the existence of
multiple outlying "master" nodes from each other?

> Jan
> 
Regards,
Tim Bowden