Thanks, Steve. So looks like the only solution is we have to restart slon
service when NTP causes time shift. However, if some events are generated
with the timestamp in the future, after slon service restart, will these
events be handled or still need to wait until that time since the events
timestamp don't changes?


On Mon, Nov 1, 2010 at 11:00 PM, Steve Singer <ssinger at ca.afilias.info>wrote:

> On 10-11-01 12:53 AM, Jason Chen wrote:
>
>> Hi Steve,
>>
>> After detail check log/core dump and sl_event table, I have figured out
>> the root cause which is the time change issue.
>>
>> During the master node configuration, time has changed after configure
>> slon service. I am configuring VM machine in a ESX host which time is
>> earlier 7 hours than NTP server which VM machine is using after
>> configuration. This will cause slon sched thread continuously check and
>> wait for 7 hours. The simple workaround here is to restart slon service
>> to refresh the time in slon sched thread.
>>
>> This might bring a new requirement on slony. Do we have any kind of
>> mechanism to handle time change other than restart slon service?
>> Consider one scenario, after slon service configured successfully and
>> there have many SYNC events generated, then user configures a new
>> external NTP server which might has several days before the current
>> time. This will cause all previous un-confirmed SYNC events cannot be
>> synced until time has caught up.
>>
>> Could you share your insight on this potential issue?
>>
>
> The slony manual recommends that your slon nodes be synchronized with NTP.
>  If the VM has issues getting the correct time from the VM host then you
> might be better running NTP on the VM host.
>
> If your going to be time-traveling your servers then you should restart
> slon in between.
>
>
>
>
>> Thanks,
>> Jason
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-hackers/attachments/20101101/b10a3a4c/attachment.htm