Slony-1 and nodes to node sync

[Christopher Browne]

On 4/12/06, Jamon Camisso <jamon.camisso-H217xnMUJC0sA/PxXw9srA at public.gmane.org> wrote:
> Chris:
>
>  From what I heard tonight, it is not possible to sync a node with the
> last complete transaction common to all other nodes? I'm imagining an
> origin server that is nearly maxed out for some reason and a node or
> nodes that needs to be caught up asap.

That wouldn't happen because the origin is the only place where
updates take place.

Something sort of like what you're talking about can be the case at
failover time; if the master fails, you might find that different
subscribers are "differently up to date," and, notably, the node you
want to take over might not be as up to date as other nodes.

If *that* happens, the node that is to take over will catch up based
on the data on the other available nodes until it has the latest SYNC
available.  But that's a failover thing, not the "usual" activity.

> Perhaps this is too much of a hypothetical what if... Regardless, how
> hard would it be to poll other nodes and use them to sync a lagging node
> up to a point where it wouldn't be so much of a drain on the master?

In a way that's the point of the notion of "cascading" subscribers. 
You might have a subscriber list like...

Node   Feeds From
------------------------------------------------
  A         Nowhere - I'm the origin!
  B          A
  C          B
  D          B
  E          B

Thus, A directly feeds node B, which then feeds a bunch more nodes,
which means that node B "takes the heat" rather than node A.

The idea of dynamically switching around the subscriptions to try to
diminish loading is interesting, in principle.  No one has done it in
practice as far as I know; the trouble with it isn't so much
theoretical as the "practical" matter of having some "objective"
measure of how heavily loaded the nodes are.  What with computers
having a whole bunch of different kinds of resources (consider CPUs,
memory, disk I/O, memory bandwidth, network bandwidth), making up a
metric to use seems more trouble than it's worth.

In practice, if you really need High Availability, you need to fairly
seriously overprovision enough of the systems that you expect them NOT
to be challenged, which means that what we might call "static routing"
is normally good enough.
--
http://www3.sympatico.ca/cbbrowne/linux.html
"The true  measure of a  man is how he treats  someone who can  do him
absolutely no good." -- Samuel Johnson, lexicographer (1709-1784)
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml