Chris,

Thanks for the detailed response and descriptions, but I think you  
addressed the ramifications for setting "forward=yes" while my  
question addressed why anyone would set "forward=no"

Based on your descriptions, it seems like there is absolutely no  
reason to set "forward=no," except for better performance.  Is the  
increase in performance significant if I set "forward=no"?  Are there  
other justifications for setting "forward=no"?

Thanks for the help!
--Richard




On Jun 30, 2006, at 7:36 PM, cbbrowne at ca.afilias.info wrote:

>> Hi all,
>>
>> I'm not sure what the "forward" flag really does in the SUBSCRIBE SET
>> slonik function.  Theoretically, you could always set "forward=yes"
>> and then never subscribe anything to it--then there would be no
>> reason to ever set it to "forward=no"
>>
>> Any insights?
>
> It controls whether or not the subscriber records changes in its own
> sl_log_1/sl_log_2 tables...
>
> If forward=N, then you can't use that node as a source for another  
> node.
>
> In order to have the feeding...
>
> A --> B --> C --> D
>
> B needs to subscribe to A, with forwarding on;
> C needs to subscribe to be, again, with forwarding on;
> that allows D to subscribe to C; in that case, forwarding is optional.
>
> If B had forwarding turned off, you couldn't set up a subscription  
> from B
> to C...
>
> Does that help answer the question?
>
> There's another detail, too, that comes up if you do a failover.   
> This may
> seems obscure...
>
> Suppose you have nodes A, B, C.
>
> A begins as the origin.
>
> B subscribes to A; forwarding turned on.
>
> C subscribes to A; forwarding turned OFF.
>
> Suppose A falls over.  The only failover option is to go to node B;  
> you
> can only failover to a forwarding node.
>
> There is a risk to having forwarding turned off on C; suppose B was  
> only
> up to date to event # 8901, whereas C was a bit ahead of that; it  
> was up
> to event 8904.  (Apparently node B wasn't replicating for a few  
> seconds,
> or something...)
>
> Alas, you cannot keep node C.  There is no way to bring B up to event
> #8904, as no remaining node has the data for SYNCs 8902, 8903, and  
> 8904.
>
> Resulting "rule of thumb":  Never have a node that is directly  
> connected
> to the origin have forwarding turned off...
>
> If you have a single node at a remote site, and you know you'd never
> consider failing over there, that node would be good to have  
> forwarding
> turned off on, as it saves a bunch of work populating sl_log_1.
>
>> Also, if I'm setting up a master->relay->offsite_backup architecture,
>> would I subscribe them all to the same set, having the relay node
>> forward to the offsite_backup node?  That's the way I got it to work,
>> but I'm not sure if there's another way, like, say, building a second
>> set on the relay machine, and have the offsite_backup subscribe to
>> that set (I'm under the impression that such a setup isn't possible).
>
> I'm not sure quite what you mean by the "another way"; what you've  
> done
> seems appropriate as how to handle cascaded subscribers...
>
>
>