<div class="gmail_quote">On Wed, Apr 13, 2011 at 11:01 AM, Vick Khera <span dir="ltr"><<a href="mailto:vivek@khera.org">vivek@khera.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><div class="gmail_quote">On Wed, Apr 13, 2011 at 1:42 PM, Richard Yen <span dir="ltr"><<a href="mailto:richyen@iparadigms.com" target="_blank">richyen@iparadigms.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Well, I noticed that when the log gets large and it's in the middle of a logswitch, load on the origin node will increase and subsequent to that, all subscriber nodes will lag up to 900sec. This seems troublesome, considering that nodes in my cluster typically don't lag for more than 10sec--it's only during these logswitch events that they lag by so much.</div>
<div></div></blockquote></div><br></div><div>I never noticed that, even when I had my db's on spinning media. It was never correlated with log switch. The only times I got lag was when I had a *lot* of update/insert activity in a very very short period.</div>
<div><br></div><div>Might I suggest that the cause/effect is the other way around? Perhaps you are just hitting your I/O throughput limit for your hardware.</div><div><br></div>
</blockquote></div>That sounds like a possibility to me, but as far as I understand it, when a subscriber is lagging, events in sl_event (and therefore sl_log_*) are not being processed. Wouldn't the slave lag block a logswitch from finishing? Or perhaps I don't fully understand the way SYNCs are processed and purged...<div>
<br></div><div>--Richard</div>