Alain Peyrat <aljeux at free.fr> writes:
> Hi,
>
> I'm running a simple replication between a master and a slave. The
> slave is planned as a switchover host in case of big troubles on
> the server (ie: slave can be stopped but not the master).
>
> My environnment:
>
> Postgres: 7.4
> Slony: 1.2.6
>
> It seems that my replication is no more active and the tables
> sl_log_1/2 are now very big (sl_log_1 is around 6GB and 3.3e+06
> tuples). Value st_lag_time is very important.
>
> I have tried to restart the slon (master and slave) but the
> st_last_received_event_ts is not changing (or only once for 3 sec).
>
> On the master slon log, I have (1 is master, 2 is slave).
>
> 2007-05-04 15:54:31 CEST DEBUG2 remoteListenThread_2: queue event 2,712628 SYNC
> 2007-05-04 15:54:31 CEST DEBUG2 remoteListenThread_2: UNLISTEN
> 2007-05-04 15:54:31 CEST DEBUG2 remoteWorkerThread_2: Received event 2,712628
> SYNC
> 2007-05-04 15:54:31 CEST DEBUG3 calc sync size - last time: 1 last length: 10166
> ideal: 5 proposed size: 3
> 2007-05-04 15:54:31 CEST DEBUG2 remoteWorkerThread_2: SYNC 712628 processing
> 2007-05-04 15:54:31 CEST DEBUG2 remoteWorkerThread_2: no sets need syncing for
> this event
> 2007-05-04 15:54:32 CEST DEBUG2 localListenThread: Received event 1,1553949 SYNC
> 2007-05-04 15:54:32 CEST DEBUG2 syncThread: new sl_action_seq 6356493 - SYNC
> 1553950
>
> So, I'm seeing line with 'no sets need syncing for this event'.
>
> Can someone help me understanding what's wrong ?

You may find it useful to look at the following page for explanations for log entries:

<http://slony.info/adminguide/slony1-1.2.6/doc/adminguide/loganalysis.html>

The interesting log is not the one for the origin node; you can expect
it to be mighty sparse, and when that node receives events from other
nodes, it is very much to be expected that it will indicate "no sets
need syncing for this event."

More interesting will be the contents of the log file for the
subscriber node; THAT will show a lot more action, and show log
entries describing the work being done to pull and apply updates from
the origin.

But none of this is showing off anything that would be considered a
"problem," and you won't see anything in the logs that will make it
evident why you can't get the lag time down.

The relevant slon option is "sync_interval_timeout", which is either
controlled via that name in a "slon.conf" file, or via the command
line "-s" option, which determines how long the slon sleeps between
checking to see if there have been updates made that would warrant
generating a SYNC event.

I believe that the default for that is 10000, which represents 10s.
If you reduced the value, that would cause SYNC events to be generated
more frequently, which I would expect to reduce st_lag_time for you.
-- 
"cbbrowne","@","ca.afilias.info"
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)