couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiril Stankov <ki...@open-net.biz>
Subject Re: CouchDB utc_id behavior
Date Thu, 18 Jun 2015 17:14:52 GMT
Solved.
If Couch starts ~ 30 sec. after boot completion, the problem seems to go 
away.
Thanks all.
------------------------------------------------------------------------
*With best regards,*
Kiril Stankov

On 18-Jun-15 2:15 PM, Kiril Stankov wrote:
> Yes, the one from 12:59 is Ok. The one from 12:51 is not.
> I will try now to delay the start of Couchdb with a minute after all 
> other daemons started and see if it will help.
> May be the hardware clock is "off" and it takes time until ntpd syncs 
> it and CouchDB starts in between.
>
>
> ------------------------------------------------------------------------
> *With best regards,*
> Kiril Stankov,
>
> On 17-Jun-15 6:41 PM, Adam Kocoloski wrote:
>> Do you happen to know if either one of these was correct-ish? Do you 
>> see any timestamps in the access logs that are also “off”?
>>
>> 05188de92ef02f -> Mon, 15 Jun 2015 12:51:05 GMT
>> 05188e0805067f -> Mon, 15 Jun 2015 12:59:42 GMT
>>
>> Adam
>>
>>> On Jun 16, 2015, at 12:44 PM, Kiril Stankov <kiril@open-net.biz> wrote:
>>>
>>> Ubuntu, couch 1.6.1, apt-get update few days ago.
>>> -- 
>>> Regards,
>>>
>>> Kiril Stankov,
>>> OpenNet Software ltd.
>>>
>>>
>>> -------- Original Message --------
>>> From: Nick North <north.n@gmail.com>
>>> Sent: June 16, 2015 7:41:50 PM GMT+03:00
>>> To: user@couchdb.apache.org, Joan Touzet <wohali@apache.org>
>>> Subject: Re: CouchDB utc_id behavior
>>>
>>> Thanks for the correction Joan - I had forgotten about the 
>>> possibility of
>>> the clock jumping backwards. However, in this case the obvious 
>>> causes don't
>>> seem to apply, and I'm slightly at a loss. I can't hypothesise a 
>>> mechanism
>>> that would cause now() to return these times if the OS clocks are in 
>>> sync.
>>> Kiril - what setup are you running on?
>>>
>>> Nick
>>>
>>> On Tue, 16 Jun 2015 at 15:48 Kiril Stankov <kiril@open-net.biz> wrote:
>>>
>>>> Hi,
>>>> As I wrote, ntpd is running and both machines have synced time. 
>>>> They were
>>>> not down for weeks.
>>>> -- 
>>>> Regards,
>>>>
>>>> Kiril Stankov,
>>>> OpenNet Software ltd.
>>>>
>>>>
>>>> -------- Original Message --------
>>>> From: Joan Touzet <wohali@apache.org>
>>>> Sent: June 16, 2015 5:38:28 PM GMT+03:00
>>>> To: user@couchdb.apache.org
>>>> Subject: Re: CouchDB utc_id behavior
>>>>
>>>> now() is not guaranteed to be monotonically increasing if the system
>>>> clock rolls backwards, which various things can cause.
>>>>
>>>> You should look into setting up ntpd for your two machines at the very
>>>> least.
>>>>
>>>> -Joan
>>>>
>>>> ----- Original Message -----
>>>>> From: "Nick North" <north.n@gmail.com>
>>>>> To: user@couchdb.apache.org
>>>>> Sent: Monday, June 15, 2015 12:14:50 PM
>>>>> Subject: Re: CouchDB utc_id behavior
>>>>>
>>>>> The utc_id algorithm uses Erlang's now() function for generating
>>>>> timestamps. This is guaranteed to be monotonic increasing, but not
>>>>> necessarily to be in very close correspondence with the operating
>>>>> system
>>>>> clock all the time, especially if you call it very frequently.
>>>>> However, I'm
>>>>> surprised that calls seconds apart are giving this problem. Are your
>>>>> machines VMs? There can be clock problems when they are suspended and
>>>>> reactivated, with clocks initially having the time when the machine
>>>>> was
>>>>> suspended, and then jumping forward, but that's unlikely if they are
>>>>> in
>>>>> fairly constant use. For what it's worth, I use utc_id timestamps for
>>>>> sorting documents, and have not seen this problem, but that doesn't
>>>>> help
>>>>> you very much.
>>>>>
>>>>> Nick
>>>>>
>>>>> On Mon, 15 Jun 2015 at 16:42 Kiril Stankov <kiril@open-net.biz>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> nope, this is not the case.
>>>>>> The newer document has older ID, this is the problem.
>>>>>>
>>>>>> 05188de92ef02f < 05188e0805067f
>>>>>>
>>>>>> But
>>>>>> 05188de92ef02f
>>>>>> was created after
>>>>>> 05188e0805067f
>>>>>>
>>>>>>
>>>>>>
>>>> ------------------------------------------------------------------------

>>>>
>>>>>> *With best regards,*
>>>>>> Kiril Stankov,
>>>>>>
>>>>>> On 15-Jun-15 6:08 PM, Alexander Shorin wrote:
>>>>>>> Time resolution is in microseconds, so difference in one second
>>>>>>> generated notable "leap" forward.
>>>>>>> -- 
>>>>>>> ,,,^..^,,,
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 15, 2015 at 5:10 PM, Kiril Stankov
>>>>>>> <kiril@open-net.biz>
>>>>>> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I have two CouchDB (v1.6.1) servers, fully synchronized between
>>>>>>>> them
>>>>>>>> (master-to-master).
>>>>>>>> The uuids algorithm is utc_id.
>>>>>>>> The servers are synchronized via ntp and there is practically
no
>>>>>>>> time
>>>>>> offset
>>>>>>>> between them.
>>>>>>>> I notice a strange behavior of the ID's of newly posted
>>>>>>>> documents.
>>>>>>>> In some cases, posting to server1, will generate ID, which
is
>>>>>>>> later
>>>>>> than a
>>>>>>>> subsequent post to server 2.
>>>>>>>> E.g., posting to server 1 generates ID:
>>>>>>>> 05188e0805067f_1
>>>>>>>> and then, few seconds later, posting to server 2 generates:
>>>>>>>> 05188de92ef02f_2
>>>>>>>> As you see, the timestamp of the second message is earlier
than
>>>>>>>> the
>>>>>> first
>>>>>>>> (_1 & _2 are suffixes for the two servers).
>>>>>>>> This is causing me a big mess, as I use the timestamp to
sort
>>>>>>>> and order
>>>>>>>> documents.
>>>>>>>> Any idea why this happens?
>>>>>>>> Can someone, please, shed more light on how CouchDB "reads"
the
>>>>>>>> time
>>>>>> for the
>>>>>>>> generation of the ID?
>>>>>>>> Or if you have an idea what may be causing this behavior.
>>>>>>>>
>>>>>>>> Thanks in advance!
>>>>>>>>
>>>>>>>>
>>>> ------------------------------------------------------------------------

>>>>
>>>>>>>> *With best regards,*
>>>>>>>> Kiril Stankov,
>>>>>>>>
>>>>>>
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message