Christopher Browne cbbrowne at ca.afilias.info
Mon Sep 21 13:15:51 PDT 2009
Vignesh Mohan wrote:
>
> Glyn Astill wrote:
>   
>>> From: Vignesh Mohan <vignesh.m at i10n.com>
>>>
>>> Hi All
>>>
>>> I need to know some facts of Slony 's Behaviour in this use
>>> case
>>>
>>> * Slony running in slave and master.
>>> * Stop slony in master and Slave
>>> * Delete few data in tables in master
>>> * Restart Slony in master and slave
>>>
>>> My Question is 
>>>
>>> Will the deletion be replicated in slave now?
>>>
>>>       
>> Yes.
>>
>>
>>
>>
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-general
>>
>>
>>     
>
>
> Thanks a load for your prompt response.
>
> This is raising another doubt. 
>
> >From your answer i come to a conclusion that whenever the slony is restarted
> entire db in slave is re written irrespective of changes done or not done.
> Am i right ?
>   
You are incorrect.
> If i m not right .. How does slony take into consideration of the deletion
> of few rows in master activity when slony is stopped.? And when started
> again how does it come to know that the rows are deleted 
>   
Slony-I captures changes to individual tuples via the log triggers.

If you want to take a peek at what it's doing, then note:
 a) Each replicated table has a trigger added to it called "logtrigger" 
(more or less; names vary a bit by Slony-I version)
 b) When updates take place to a table, tuples are recorded in sl_log_1 
or sl_log_2.

You could exercise this by looking at the contents of sl_log_1/2, then 
forcing in an update, and seeing what tuples were added.
> Also tell me the way in which we can restart the slony 
>
> I do the this
> /usr/bin/slon start
>   
You need to restart the slon process; it connects to the various 
databases, and figures out based on their state what to do next.  
Nothing too much more is necessary.
> What does sloni_restart_node do ?
>   
"restart_node" was some tooling that was important in earlier versions 
of Slony-I, where slon processes had a tendancy to get a little bit 
deranged if anything went wrong with network connectivity, and you'd 
need to "reset" things by hand.


More information about the Slony1-general mailing list