On 10/17/2004 6:55 AM, hannu at skype.net wrote:
>> 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)

Are you sure the slave went through the cleanup procedure since?

> 
> 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);

This problem was fixed in release 1.0.2 ... do you mind upgrading?

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

No, slonik 1.0.1 has a development hack constant "true" in there instead 
of using the value provided in the option :-)

> 
> Can I do it manually without breaking things ?

Sure, on the subscriber you can do

     select _userdb_cluster.subscribeSet(1, 2, 1, 'f');

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

The above will do that. Just be aware that if you turn forwarding off, 
the slave not only cannot be used for cascading any more, it will also 
refuse to take ownership of the set in a switchover or failover.


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 #