On 5/29/2008 1:26 PM, Tory M Blue wrote:
> Okay
> 
> Per a few emails back I asked about full mesh and it was determined or
> re certified to not be a great idea, especially when one scales, and
> it's apparently not needed at any point.
> 
> So I've tried to get my 4 box system to drop some of this activity.
> 
> Master
> Slave
> QSLAVE1
> QSLAVE2
> 
> I've tried to remove any events from taking place from 3 to 4 and vice
> versa. I still want the master and slave to talk to both QSlaves (a
> bit nervous I guess about removing Slave to Qslave communications)
> (since there will be occasions for switchover).
> 
> I'm still seeing on Slave1 the following (slave 1 is node 3, slave 2 is node 4)
> 
> 2008-05-29 10:22:02 PDT DEBUG2 remoteWorkerThread_1: SYNC 5318 done in
> 0.011 seconds
> 2008-05-29 10:22:02 PDT DEBUG2 remoteWorkerThread_1: forward confirm
> 4,4775 received by 1
> 2008-05-29 10:22:02 PDT DEBUG2 remoteWorkerThread_1: forward confirm
> 4,4775 received by 2
> 2008-05-29 10:22:02 PDT DEBUG2 remoteWorkerThread_1: forward confirm
> 3,6219 received by 4
> 2008-05-29 10:22:02 PDT DEBUG2 remoteWorkerThread_1: forward confirm
> 2,4937 received by 4
> 2008-05-29 10:22:02 PDT DEBUG2 remoteWorkerThread_1: forward confirm
> 3,6219 received by 2
> 2008-05-29 10:22:02 PDT DEBUG2 remoteWorkerThread_1: forward confirm
> 3,6219 received by 1
> 2008-05-29 10:22:02 PDT DEBUG2 remoteWorkerThread_1: forward confirm
> 1,5318 received by 2
> 2008-05-29 10:22:02 PDT DEBUG2 remoteWorkerThread_1: forward confirm
> 2,4937 received by 1
> 
> So it appears even though I show : sl_path=10, sl_listen=26
> 
> That I've not correctly or successfully removed some of the chatter
> between the nodes.
> 
> So, where would I have assigned these paths? We have looked thru our
> scripts and cannot locate where we may be setting this and thus need
> to remove it.  sl_path seems right, sl_listen not so sure about.

Configuring your path network to match your designed flow of data does 
not affect the necessity that all nodes need to confirm the events of 
all other nodes. Those messages are simply propagated through the 
existing paths from node to node.

The major point of keeping your path network the same as your data flow 
is to make sure events are not sent ahead of available data on the data 
providers. Slon does handle this, but it involves timeouts and retries.

Slonik does handle reshaping the path network at failover/switchover 
time just fine, so there is no need to worry about not being able to 
switch/fail if the network isn't configured ahead of time.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin