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