Re: why set "forward" flag in SUBSCRIBE SET?
Richard Yen <dba@...
2006-07-05 16:35:31 GMT
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!
On Jun 30, 2006, at 7:36 PM, cbbrowne@... 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
> 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;
> can only failover to a forwarding node.
> There is a risk to having forwarding turned off on C; suppose B was
> 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
> 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
> Resulting "rule of thumb": Never have a node that is directly
> 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
> 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
> seems appropriate as how to handle cascaded subscribers...