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,
