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 <demoncc...@gmail.com> wrote: > Hi, > > On Mon, Dec 22, 2014 at 11:54 PM, Alexander Sicular <sicul...@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 >>> <demoncc...@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@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
