On 10/12/2004 12:38 PM, hannu at skype.net wrote:

>> On 10/12/2004 10:35 AM, hannu at skype.net wrote:
>>
>>> Ok Now I was at leas able to convince slony to drop node5 , but I still
>>> have
>>> sl_log_1 file of 3.3M rows.
>>>
>>> This manifests itself as periods of tens of seconds when the system
>>> halts
>>> to a crawl as slony vacuums that big table and clients timeout. The
>>> selects form sl_log_1 are slow as well, but at least they do not affect
>>> other operations ;(
>>>
>>> My current solution is to stop slony on slaves during peak periods, but
>>> what I really would like is that the sl_log_1 could be trimmed down.
>>
>> We have to work on log switching ... yes.
> 
> Currently I would be happy if I got some advice how to do it manually

They are only supposed to live until every node has confirmed the SYNC 
events that cover them. It all seems very much like one of the problems 
we once had here on a test server, where dropping a node overlapped with 
the slon process storing another "sl_confirm" row for it.

> 
> Where can I find out what slon is waiting for and which entries are safe
> to delete.

Look in sl_confirm if there are any orphaned rows (referencing a dropped 
node in either con_origin or con_received) and delete them.

Make sure that every node that is configured in the cluster does run 
every now and then and catches up. Even if it is not subscribed to any 
set, it must replicate the events.

Drop nodes that you cannot get back online. Better rebuild them from 
scratch than to accumulate billions of log rows.

> 
> I assume that it must be waiting for something that will never happen as
> currently I runit with only one master and one slave and replica being
> up-to-date.

Looks like.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #