Andrew Sullivan ajs at crankycanuck.ca
Fri Feb 5 16:52:30 PST 2010
On Fri, Feb 05, 2010 at 04:33:49PM -0800, Tory M Blue wrote:

> However if I lose a Slave node which is a provider to a Query node, I
> don't only lose the Slave, but in all reality I lose the Slave and the
> Qslave (since it's getting it's data from the Slave node). Unless you
> are citing that I would actually do a switchover/failover against the
> Slave nodes which are talking to the Qnodes.. I may need to change the
> subject or create another thread. But I'm close, but I continue to
> have to rebuild my QSLAVE host after failing the SLAVE host (it's
> provider).

In general, your life will be better if you stop thinking of nodes as
having particular roles, and think of them as having one or more
functions:

 - replica
 - forwarder
 - origin

A replica can receive data in a given set from some source, which can
either be the data origin strictly conceived (i.e. where the data
comes from, the active data-write source of that set), or it can be
some forwarder of that set.

In your graph, you have a single data origin for all sets (1), and you
have two forwarders; those forwarders are also replicas (you're
calling them "slaves": 2,3).  They become data providers for other
replicas (which you're calling qslaves, 4,5).

Every node in this graph _knows_ about the data flow.  So, if 4
receives from 2 and 5 receives from 3 and 2 dies, 4 can be told, "Go
get this from 3" and it will pick up where it left off last from 2.

This is why Slony overhead is so great: you get the benefit of
resilience, but it comes at the cost of nodes knowing about things
they're not actively using.

Does that help make sense of some of this?

A

-- 
Andrew Sullivan
ajs at crankycanuck.ca


More information about the Slony1-general mailing list