On Fri, 14 Aug 2015, Tory M Blue wrote:

> Okay so someone pinged me off list and stated yes NODE ID's have to be unique, okay figured but that's good to know.
> 
> Now I'm wondering how to best setup the replication.
> 
> If Site A has 
> 
> (Nodes 1-5)
> MASTER - Replicates to the 4 servers below
> SLAVE
> QUERYSLAVE1,2,3
> 
> Site B has similar
> 
> (Nodes 11-15)
> DRMASTER - Replicates to the 4 servers below.
> DRSLAVE
> DRQUERYSLAVE1,2,3
> 
> I was just thinking I would add DRMASTER as a slave off of SLAVE. Since SLAVE has forward = yes, it could easily
> forward the data on to DRMASTER and DRMASTER could in turn send all that DATA down it's pipe to DRSLAVE/DRQUERYS*
> 
> I've run into a couple of issues and that is that it seems that all nodes in site A become aware of DRMASTER from
> site B, and not sure I want that and/or if it's possible to get around that.  

I think you need to be a bit more careful about your terminology and set + 
node numbering, I am not exactly sure what your describing.

All nodes in a cluster need to be aware of all other nodes.  If your going 
to have 1 slony cluster that spans both sites you need to have unique node 
numbers and all nodes need to be 'aware' of other nodes.  All nodes in your 
cluster need to confirm all events from all other nodes, even if the node 
isn't subscribed to anything from some other node.  It's a bit chatty but I 
don't think this is going to be a problem for 12 nodes.

What I don't understand though is what you mean below by '2 separate 
clusters' and that your re-using 'set 1', 'set 1' can only have 1 node of an 
origin.

Is what you really mean something like this

Site 1
Node 11: Master for set 1.  Replica for set 2
Node 12: replica for set 1
Node 1[3,4,5]: Query slave replicas for set 1

Site 2:
Node 21: Master for set 2, replica for set 1
Node 22: Replica for set 2
Node 2[3,4,5]: Query slave replicas for set 2

In the above setup there can't be any overlap between the tables in set 1 
and the tables in set 2.  What I describe above is a single slony cluster.

If what you really means is having 2 slony clusters that are somehow 
connected then we aren't talking about the same thing.  If you can make 
that work (and I think some people on the list have done that type of thing) 
then you would need some nodes to be part of both clusters.


> 
> The paths should be in site A
> 
> Master <-> Slave (set 1-3)
> Master <-> Queryslave* (set 1)
> Slave <-> Queryslave* (set 1) (due to switchover possibility).
> 
> paths in site B
> 
> DrMaster <-> DRSlave (set 1-3)
> DrMaster <-> DRQueryslave* (set 1)
> DrSlave <-> DRQueryslave* (set 1) (due to switchover possibility).
> 
> 
> Then I would add a new path
> 
> Slave <-> DrMaster (set 1-3)
> 
> I'm wondering if I'm looking at this right. These are 2 separate clusters but the data has to be in sync and I'm
> looking to use this as a site migration tool.
> 
> BTW we have been using slony for over 9 years ,so I'm not totally new to it, but it's always been isolated into it's
> own cluster (prod, staging, Qa, Dev etc), now I'm looking to use it as a migration mechanism between 2 clusters at
> differing locations.
> 
> Thanks and sorry for being dense
> Tory
> 
> 
> 
>