Awesome, thanks for replying back to the thread Kiril. Cheers, Adam
> On Jun 18, 2015, at 1:14 PM, Kiril Stankov <[email protected]> wrote: > > 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 <[email protected]> wrote: >>>> >>>> Ubuntu, couch 1.6.1, apt-get update few days ago. >>>> -- >>>> Regards, >>>> >>>> Kiril Stankov, >>>> OpenNet Software ltd. >>>> >>>> >>>> -------- Original Message -------- >>>> From: Nick North <[email protected]> >>>> Sent: June 16, 2015 7:41:50 PM GMT+03:00 >>>> To: [email protected], Joan Touzet <[email protected]> >>>> 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 <[email protected]> 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 <[email protected]> >>>>> Sent: June 16, 2015 5:38:28 PM GMT+03:00 >>>>> To: [email protected] >>>>> 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" <[email protected]> >>>>>> To: [email protected] >>>>>> 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 <[email protected]> >>>>>> 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 >>>>>>>> <[email protected]> >>>>>>> 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, >>>>>>>>> >>>>>>> >> >> >
