You can use pr and pw to require reads and writes to hit primary vnodes. I suspect this makes it possible to fail writes in the way you are describing.
--- Jeremiah Peschka Founder, Brent Ozar Unlimited On Nov 13, 2012, at 12:51 AM, kamiseq <kami...@gmail.com> wrote: > yes, that was my conclusion thats why my question was 'it is possible to fail > write'. > in a simple scenario you can use R val to ensure that you have enough nodes > to read from and riak will fail if you have less and this could be nice > sometimes. my point was that you cannot fail write, riak will never complain. > > anyway thanks for response > > > pozdrawiam > Paweł Kamiński > > kami...@gmail.com > pkaminski....@gmail.com > ______________________ > > > On 13 November 2012 00:21, Eric Redmond <eredm...@basho.com> wrote: >> Pawel, >> >> I think you've wandered into a real disconnect between how we communicate >> Riak replication, and how it actually works. >> >> Although we say that N="nodes to replicate to", in reality, N="vnodes >> replicated to with every attempt to ensure they are different nodes with no >> guarantee". This is why you can have 3 nodes with 64 vnodes, and still set >> N>3. >> >> Now W is just the number of successful responses for a write to be >> considered a success. W can be any number less than or equal to N, but the >> difference will still be replicated as well, just asynchronously. For >> example, if N=3, W=2, once two nodes (well, vnodes) have responded, your >> write is considered a success. In the background, Riak will still ensure >> that third node is replicated to, giving you three total replicas. >> >> Hope that helps, >> Eric >> >> >> >> On Nov 12, 2012, at 3:01 PM, kamiseq <kami...@gmail.com> wrote: >> >>> this is funny but recently I started to think again about how riak works >>> and I thought I know more or less the basics ;] >>> >>> but I start digging and again I read >>> http://docs.basho.com/riak/latest/tutorials/fast-track/Tunable-CAP-Controls-in-Riak/ >>> and then made few tests with riak bucket configured as follows >>> >>> N = 3 >>> W = 3 >>> >>> I have 2 nodes running in my cluster so far (only 2 are connected) for test >>> and I can still write with hinted handoff. I updated the data and I wrote >>> again with same key - I got success. >>> >>> I changed properties on per request basis and I set w=1 I stopped first >>> node (so I had only one running) and put new key and value. I started first >>> node and query for the key and I got data from both nodes. I did the same >>> with new key again this time with w=3. and again it was successful. >>> >>> what is the real difference between N and W. if hinted handoff always save >>> data for later synchronisation can write ever fail. are there any >>> differences between first write and later updates. >>> >>> I hope it is not really stupid question >>> >>> pozdrawiam >>> Paweł Kamiński >>> >>> kami...@gmail.com >>> pkaminski....@gmail.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 > > _______________________________________________ > 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
