I had a similar situation recently, and had to get it caught up on a 
slow connection.

I increased the group size to allow more events be processed at a time, 
it did help catch up a bit faster.

Normally I have all daemons running on one box, so I also killed the 
daemon for this slave and ran it on the actual slave that was behind. It 
sped the sync times up by about 4X.

- Brian F

On 03/07/2012 03:29 PM, Steve Singer wrote:
> On 12-03-07 05:57 AM, Laura Passigni wrote:
>> Hi,
>> I have a big database (about 1350GB) with Slony replica (1 master and 1
>> slave).
>> Last week I have had a network crash between master and slave server.
>> Unfortunately there was a bulk import in progress in the master
>> database. As result the slave server was not in sync with the master for
>> few days.
>> There are now about 80.000 records in the sl_event table and the sync is
>> very slow. I have seen in the log file that the sync of each event
>> requires about 1500/2000 seconds. It is a very huge time.
>> Is there something that I can do? Is there some faster way to sync the
>> databases?
>> Thank you,
>> Laura
>>
> It is possible that your issue is what we have been referring to as bug
> 167.  This has been fixed in slony 2.1.0.  What happens is that when
> sl_log_1 or sl_log_2 grows beyond a certain size the query turns into a
> sequential scan.
>
> Other than upgrading,  you need to push the sync interval up so you
> generate fewer syncs, and increase the sync_groupsize so it processes
> more syncs together.  This might allow slony to catch up.  Once it is
> caught up your sl_log tables will get truncated and you can go back to
> normal settings/operations.
>
>
>>
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-general
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general