[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slony1-general
Subject:    Re: [Slony1-general] 'subscribe set'
From:       Jan Wieck <JanWieck () Yahoo ! com>
Date:       2004-11-21 2:52:42
Message-ID: 41A002FA.3000809 () Yahoo ! com
[Download RAW message or body]

On 11/20/2004 3:44 PM, Darcy Buskermolen wrote:
> On November 20, 2004 12:30 pm, Marc G. Fournier wrote:
>> 'k, thanks to Darcy's help, I think I've got it all worked out ... and
>> I've finally clued into why everyone refers to it as a subscriber, instead
>> of slave ...
>>
>> But, next step I'm not sure about, not so much from the initial setup side
>> of things, since that is fairly straightforward, but on a reboot ...
>>
>> According to how I'm reading the README file, both the subscriber and
>> master servers need to be running before I can issue the subscribe set
>> command ... at least, assuming I'm reading it right ...
>>
>> Basically, according to the README, I need to start 'slon' up on the
>> master, and 'slon' up on the subscriber, and then on the master I need to
>> run run the 'subscribe set' command, which, based on the example, makes a
>> connection to both master/subscriber and then "links" them, it seems ...
>>
>> But, what if the subscriber is rebooted?  Do I have to monitor this from
>> the master side and re-issue the subscribe set command to get them going
>> again?  *Or* is the subscribe set only run *once* when  you first bring on
>> the subscriber, so that if the subscriber is rebooted, the only thing that
>> is needed is to run the 'slon' command on the subscriber for it to pick
>> up/replicate from master again?
> 
> Once the note is completely subscribed, you don't need to reissue the 
> subscribe. even after a reboot yadda yadda yadda..
> for example try this;
>  kill the slon processes on the subsriber and orign.  go for coffee (let some 
> updates happen ect)  then start up the slons again.  and watch them sync up..  

Actually, killing the slon on the origin for extended times while
updates are happening isn't such a smart idea. It causes all those
updates to pile up into the first SYNC event generated when the slon
restarts.

It is not important to have the slon on the subscriber running or the
subscribers database being available. It will try to connect, and keep
doing so in the reconnect interval ... and fail ... and so be it.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


[prev in list] [next in list] [prev in thread] [next in thread]