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