<div dir="ltr">Actually I think it is because a pg_dump of the db is going on.<div><br></div><div>Can you dump a slave ? </div><div><br></div><div>Do you have to exclude the slony clusters (which would make sense)?</div><div><br></div><div>Thanks,</div><div><br></div><div>Dave</div></div><div class="gmail_extra"><br clear="all"><div>Dave Cramer</div>
<br><div class="gmail_quote">On 16 October 2014 10:34, Glyn Astill <span dir="ltr"><<a href="mailto:glynastill@yahoo.co.uk" target="_blank">glynastill@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: Dave Cramer <<a href="mailto:davecramer@gmail.com">davecramer@gmail.com</a>><br>
>To: slony <<a href="mailto:slony1-general@lists.slony.info">slony1-general@lists.slony.info</a>><br>
>Sent: Thursday, 16 October 2014, 11:19<br>
>Subject: [Slony1-general] Lag time increasing but there are no events<br>
<span class="">><br>
><br>
><br>
>I have a situation I can't explain.<br>
><br>
><br>
>sl_status shows lag time increasing. num events is 0, and the data is being replicated.<br>
><br>
><br>
>What exactly does lag_time represent ?<br>
><br>
><br>
<br>
</span>My considerably fuzzy understanding is that it's essentially the time difference between the timestamp for the last received event in sl_confirm and the current timestamp so (current_timestmp-st_last_received_event_ts)<br>
<br>
I guess you've made sure the time is synchronized on all the nodes? That's the first thing I'd be checking as I'd expect to see a positive value in st_lag_num_events too if st_lag_time were going up.<br>
<br>
Is there anything out of place in the slon logs and have you tried restarting the slon daemons? There's also the lag_interval parameter to look at, I've no idea how sl_status would look if that were set, but any chance it is?<br>
<br>
<br>
Personally I'd be digging into the sl_confirm and sl_event tables to look for some sort of clue if none of the above were fruitful. Something like the below, which more likely than not isn't completely correct:<br>
<br>
select e.ev_origin, c.con_received, e.ev_seqno, (c.con_timestamp-e.ev_timestamp)<br>
from sl_event e inner join sl_confirm c on e.ev_seqno = con_seqno and e.ev_origin = c.con_origin<br>
order by (c.con_timestamp-e.ev_timestamp) desc;<br>
</blockquote></div><br></div>