<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 14, 2015 at 7:05 PM, Steve Singer <span dir="ltr"><<a href="mailto:steve@ssinger.info" target="_blank">steve@ssinger.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 14 Aug 2015, Tory M Blue wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
Now I'm wondering how to best setup the replication.<br>
<br>
If Site A has <br>
<br>
(Nodes 1-5)<br>
MASTER - Replicates to the 4 servers below<br>
SLAVE<br>
QUERYSLAVE1,2,3<br>
<br>
Site B has similar<br>
<br>
(Nodes 11-15)<br>
DRMASTER - Replicates to the 4 servers below.<br>
DRSLAVE<br>
DRQUERYSLAVE1,2,3<br>
<br>
I was just thinking I would add DRMASTER as a slave off of SLAVE. Since SLAVE has forward = yes, it could easily<br>
forward the data on to DRMASTER and DRMASTER could in turn send all that DATA down it's pipe to DRSLAVE/DRQUERYS*<br>
<br>
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<br>
site B, and not sure I want that and/or if it's possible to get around that. <br>
</blockquote>
<br>
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.<br>
<br></blockquote><div>There is no doubt, and I appreciate you attempting :) </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
Is what you really mean something like this<br>
<br>
Site 1<br>
Node 11: Master for set 1. Replica for set 2<br>
Node 12: replica for set 1<br>
Node 1[3,4,5]: Query slave replicas for set 1<br>
<br>
Site 2:<br>
Node 21: Master for set 2, replica for set 1<br>
Node 22: Replica for set 2<br>
Node 2[3,4,5]: Query slave replicas for set 2<br>
<br>
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.<br>
<br>
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.<br>
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></blockquote><div><br></div><div>Thanks again Steve. I am not trying to establish a 10+ node cluster. What I am trying to do is establish a relationship between 2 clusters. </div><div><br></div><div>Set 1-3 are unique sets tied to a single Origin yes, but they are available to read from the slaves.</div><div><br></div><div>What i'm trying to do , figure out (without the required vocabulary obviously), is to in fact create a fail over scenario</div><div><br></div><div>There is a slon document that uses this image.</div><div><br></div><div><a href="http://slony.info/documentation/concepts.html">http://slony.info/documentation/concepts.html</a><br></div><div><br></div><div><img src="http://slony.info/documentation/complexenv.png"><br></div></div><br></div><div class="gmail_extra">However in my failed description, I was trying to free up the origin from having to talk to all 10 nodes, but instead offload some of that chatter from the Slave to site B's "would be Master and let site B's ("Master) handle the replication to nodes 12-15 (there would never be a need to switchover from site A to any other node in Site B (but node 11).</div><div class="gmail_extra"><br></div><div class="gmail_extra">So Site A would be aware of Nodes 1-5 (1 being the insert origin) and node 11 (which is in Site B configured as a slave). Site B nodes would only know that they are talking to node 11 as their origin, other than node 11, node 12-15 would only know about Node 11-15 and nothing about Nodes 1-5.</div><div class="gmail_extra"><br></div><div class="gmail_extra">UUGH improper terminology I'm sure.. It's probably more frustrating trying to decipher more than it is me trying to explain.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If I had 2 circles the only box that would touch both circles would be node 11, where node 1-5 are in their own bubble, and nodes 12-15 in their own. with the exception of node 11 being in both circles.</div><div class="gmail_extra"><br></div><div class="gmail_extra">man.. hopefully I'm doing somewhat of a better job explaining.</div><div class="gmail_extra">Tory</div></div>