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, >>>>>> >>>> >>>> >>> >>
