vnodeid uniqueness

YAMAMOTO Takashi yamt at
Thu May 17 23:41:41 EDT 2012


thanks for explanation!


> Hi,
> 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.
> Jon.
> 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

More information about the riak-users mailing list