Weird RIAK behavior

Russell Brown russell.brown at me.com
Tue Dec 23 03:20:23 EST 2014


Did you check that you had an intermediate value after the second write as expected? Do you have allow_mult set to true?

On 23 Dec 2014, at 03:20, Claudio Cesar Sanchez Tejeda <demonccc.y at gmail.com> wrote:

> Hi,
> 
> On Mon, Dec 22, 2014 at 11:54 PM, Alexander Sicular <siculars at gmail.com> wrote:
>> Same client code writing to all 5 clusters?
> 
> Yes, it is the same code.
> 
>> 
>> How does the config of the 5th cluster differ from the first 4?
>> 
> 
> Two clusters have one more memory backend configured (they are
> configured with multibackend). The cluster with issues is one of these
> two clusters.
> 
>> Quick notes:
>> Minimum of 5 nodes for a production deployment to ensure the default 3 replicas are all on different physical nodes. Which is a good segue into the fact that you shouldn't run multiple Riak nodes on the same physical hardware. Performance aside, if you lose that physical machine you lose all your data.
> 
> Yes, these clusters (that are located in the same physical machine)
> are used for the developing team.
> 
> Regards.
> 
>> 
>> 
>> @siculars
>> http://siculars.posthaven.com
>> 
>> Sent from my iRotaryPhone
>> 
>>> On Dec 22, 2014, at 18:59, Claudio Cesar Sanchez Tejeda <demonccc.y at gmail.com> wrote:
>>> 
>>> I'm a sysadmin and I managing 5 cluster of RIAK:
>>> 
>>> - two of them are LXC containers on the same physical machine (3 nodes
>>> per cluster)
>>> - one of them are LXC containers located on different physical
>>> machines (6 nodes)
>>> - one of them are LXC containers located on different physical
>>> machines and XEN VMs (6 nodes)
>>> - and the last of them are VMware ESX VMs (3 nodes)
>>> 
>>> Our application works correctly on the first four clusters, but it
>>> doesn't work as we expected on the last one.
>>> 
>>> When we update a key and we retrieve this key in order to write it
>>> again, it has an old value (it doesn't have the first value that we
>>> wrote), for example:
>>> 
>>> The key has: lalala
>>> We retrieve the key, and add lololo, so it should be lalala,lololo
>>> We retrieve the key again, and try to add lelele, so it should be now:
>>> lalala,lololo,lelele, but when we retrieve it again, we only have:
>>> lalala,lelele
>>> 
>>> In the second write action, when we retrieve the key, we obtained a
>>> key with the old value. We set r, w, pr and rw to 3 to the REST
>>> requests, but it doesn't help.
>>> 
>>> All the configuration files are very similiar and we don't have any
>>> major differences in the disk I/O and network performance of the nodes
>>> of the clusters.
>>> 
>>> Did anyone have a similar issue?
>>> 
>>> Regards.
>>> 
>>> _______________________________________________
>>> riak-users mailing list
>>> riak-users at lists.basho.com
>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> 
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com




More information about the riak-users mailing list