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
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
