Problem solved with the following procedure : (slony 1.2.10)

when node M2 is lost :

- reshape subscription from S2 to M1 -> all the nodes except S2 is updated
- update manually sl_subscribe on S2 : update "_CLUSTER1".sl_subscribe 
set sub_provider=1 where sub_receiver=4;
- reshape subscription from S2 to M1 (in case of much more need to be 
done on S2 ?) + drop node M1

and everything works :-)

So, when S2 is receiveing events (done on M1) from M2, it's not updated 
if M2 is lost although paths between M1 and S2 exist.

Regards

Cyril SCETBON wrote:
> Sorry to reply one more time, but I need help :-(
> A little precision, these tests have been done on the same host, maybe 
> the problem is known ...
>
> Any idea to fix the issue ?
>
> thanks.
>
> Cyril SCETBON wrote:
>>
>>
>> Cyril SCETBON wrote:
>>>
>>>
>>> Jan Wieck wrote:
>>>> On 8/31/2007 10:08 AM, Cyril SCETBON wrote:
>>>>>
>>>>> Jan Wieck wrote:
>>>>>> On 8/31/2007 4:43 AM, Cyril SCETBON wrote:
>>>>>>>
>>>>>>> Cyril SCETBON wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrew Sullivan wrote:
>>>>>>>>> On Wed, Aug 29, 2007 at 07:51:18PM +0200, Cyril SCETBON wrote:
>>>>>>>>>  
>>>>>>>>>> So, How can I do if M2 is lost ? Cause I don't want S2 to 
>>>>>>>>>> resync with M1 from scratch
>>>>>>>>>>     
>>>>>>>>>
>>>>>>>>> You can't.  If you can't co-ordinate a switchover, then you 
>>>>>>>>> lose the
>>>>>>>>> node.  This is discussed at length in the manual.
>>>>>>>>>   
>>>>>>>> Really ????
>>>>>>>> Are you really saying that losing M2 make me lose S2 ?????
>>>>>>>> If it's true I'm really disappointed by slony :-(
>>>>>>>>
>>>>>>>> My config is as follows (just to remember) :
>>>>>>>>
>>>>>>>> psql db1 -c 'select * from "_CLUSTER1".sl_subscribe'
>>>>>>>> sub_set | sub_provider | sub_receiver | sub_forward | sub_active
>>>>>>>> ---------+--------------+--------------+-------------+------------
>>>>>>>>      1 |            1 (M1)|            3 (M2)| t           | t
>>>>>>>>      1 |            1 (M1)|            2 (S1) | t           | t
>>>>>>>>      1 |            3 (M2)|            4 (S2) | t           | t
>>>>>>
>>>>>> Since all nodes in your scenario are forwarders, you won't lose 
>>>>>> anything other than the failed node ever. In your configuration 
>>>>>> if you lose node M2 (which is a subscriber), simply issuing a new 
>>>>>> SUBSCRIBE SET for node S2 to use M1 or S1 as data provider will 
>>>>>> do. It will catch up from there without the need to sync from 
>>>>>> scratch.
>>>>> I tried reshaping subscription. The subscription works. But no 
>>>>> more updates go to S2.
>>>>
>>>> Check the sl_path configuration. S2 might not have the necessary 
>>>> (or correct) information to connect to its new data provider.
>>> The problem is that S2 does not know that it must now connect to a 
>>> new provider :
>>>
>>> On node S2 I have the following subscribe information :
>>>
>>> sub_set | sub_provider | sub_receiver | sub_forward | sub_active
>>> ---------+--------------+--------------+-------------+------------
>>>       1 |            1 |            2 | t           | t
>>>       1 |            1 |            3 | t           | t
>>>       1 |            3 |            4 | t           | t
>> why node 4 wasn't updated ? weird , no ?
>>>
>>> But, on other nodes I have :
>>>
>>> sub_set | sub_provider | sub_receiver | sub_forward | sub_active
>>> ---------+--------------+--------------+-------------+------------
>>>       1 |            1 |            2 | t           | t
>>>       1 |            1 |            4 | t           | t
>>>
>>> I've used SUBSCRIBE SET (ID=1,PROVIDER=1,RECEIVER=4,FORWARD=YES); to 
>>> reshape subscription from node 4 to node 1.
>>>
>>> Since node 3 was lost, node 4 does not know that it has to change 
>>> subscription even if I instruct slonik to make this change and that 
>>> the script has the correct node informations and path on node 4 :
>>>
>>>         2 |         1 | dbname=db2 host=xx user=postgres port=5432 
>>> |           10
>>>         1 |         2 | dbname=db1 host=yy user=postgres port=5432 
>>> |           10
>>>         3 |         4 | dbname=db3 host=zz user=postgres port=5432 
>>> |           10
>>>         1 |         3 | dbname=db1 host=yy user=postgres port=5432 
>>> |           10
>>>         4 |         3 | dbname=db4 host=ww user=postgres port=5432 
>>> |           10
>>>         3 |         1 | dbname=db3 host=zz user=postgres port=5432 
>>> |           10
>>>         1 |         4 | dbname=db1 host=yy user=postgres port=5432 
>>> |           10
>>>         4 |         1 | dbname=db4 host=ww user=postgres port=5432 
>>> |           10
>>>
>>> This time, I've added path between node 4 and node 1 before dropping 
>>> node 3, but node 4 continues to connect to node 3 and get the 
>>> following error  slon_connectdb: PQconnectdb("dbname=db3 host=zz 
>>> user=postgres port=5432") failed - FATAL:  database "db3" does not 
>>> exist.
>>>
>>> Why it did not delete entry for node 3 on node 4 ???
>>>
>>> any idea ?
>>>
>>>>
>>>>
>>>> Jan
>>>>
>>>
>>
>

-- 
Cyril SCETBON