vnodeid uniqueness

Jon Meredith jmeredith at
Wed May 16 10:15:26 EDT 2012


It's intentional.  Originally the code only used nodeid, but there was a
problem with ownership change so we fixed it by adding the timestamp.

The issue we found goes like this, if nodeA is originally in the preflistt,
after a few updates you would have a vclock of Vclock1=[{nodea,3}].
Ownership of the partition changes from nodeA to nodeB and there are a few
more updates you have Vclock2=[{nodea,3},{nodeb,2}] which descends from
Vclock1. After the ownership change, nodeA removes it's copy of the object
(as it is stored on nodeB +other nodes).   Now, if the network is
partitioned and used as a fallback, a new vclock would be created
Vclock3=[{nodea,1}], but when that data is handed back it will be lost as
Vclock3 is an ancestor of Vclock2.

The case where multiple vnodes in a preflist are owned by the same node is
interesting, but I think is safe too.  If the put is done on a node that is
in the preflist it will use the first vnode it owns.  If it isn't in the
preflist, it will forward to the first node in the preflist.  Either way,
the updates will happen on the same vnode and will have the vclock
incremented there.


On Tue, May 15, 2012 at 11:54 PM, YAMAMOTO Takashi
<yamt at>wrote:

> hi,
> vnodeid is composed from nodeid and timestamp.
> because of the second-precision of the timestamp, many of vnodes in
> a physical node can share the same vnodeid.  is this an intentional
> behaviour or a bug?  i wonder if it doesn't affect the vclock algorithm.
> YAMAMOTO Takashi
> _______________________________________________
> riak-users mailing list
> riak-users at

Jon Meredith
Platform Engineering Manager
Basho Technologies, Inc.
jmeredith at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the riak-users mailing list