> 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.
. . .
>>>> 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.

removing sl_confirm entries for already dropped nodes (on both master and
slave) fixed the problem for master - the size sl_log_1 is reasonable.

unfortunately it did not help on slave (sl_log_1 is 5.5M rows)

I am also unable to set subscription on slave (node 1) to forward=no using
slonik command :
subscribe set ( id = 1, provider = 2, receiver = 1, forward = no);

could it be that slonik has some builtin prohibition for doing it on node 1 ?

Can I do it manually without breaking things ?

Using some sl function or maybe just "delete from _userdb_cluster.sl_log_1
where ???" and "update _userdb_cluster.sl_subscribe set sub_forward =
false where sub_set=1 and sub_provider=2 and sub_receiver=1"

Must the master node also be aware of slave's state change from
forward=yes to forward=no.

-----------------
Hannu