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

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

Slony doesn't have any direct support for relationships between two slony 
clusters.  The failover command requires that all nodes be part of the same 
cluster.   A slony cluster can span as many networks and data centers as you 
want (at some point you will start to hit performance limitations).

> Set 1-3 are unique sets tied to a single Origin yes, but they are available to read from the slaves.
> 
> What i'm trying to do , figure out (without the required vocabulary obviously), is to in fact create a fail over
> scenario
> 
> There is a slon document that uses this image.
> 
> http://slony.info/documentation/concepts.html
> 
> [complexenv.png]
> 
> 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).
> 
> 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.
> 
> UUGH improper terminology I'm sure.. It's probably more frustrating trying to decipher more than it is me trying to
> explain.
> 
> 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.
>

You can have 1 slony cluster with a configuration like

  11--->12
  |
  ----->13
  |
  ------>14
  |
  ------>15
  |
  |
  |
  V
  21---->22
  |
  ------>23
  |
  ------>24
  |
  ------>25


What I describe above is a common slony configuration for cascading sets 
from a single origin to replicas in a different data center.




  > man.. hopefully I'm doing somewhat of a better job explaining.



> Tory
> 
>