Hi all,
I have a question regarding setting the n_val.
In the documentation (
http://docs.basho.com/riak/latest/tutorials/fast-track/Tunable-CAP-Controls-in-Riak/)
it is stated that:
n_val must be greater than 0 and less than or equal to the number of actual
nodes in your cluster to get all the b
Two important points:
First, n_val determines how many partitions (or virtual nodes) the data will be
distributed to. The ring size determines how many partitions exist, and should
be a much larger number than the number of servers your cluster will run on.
Riak's default ring size is 64, so de
Alexander,
The simplest answer is that we never recommend running Riak on one node. The
recommended minimum is 5, but you could possibly get away with 3 (the default
repl value).
There is a blog post about this from last year, explaining why:
http://basho.com/why-your-riak-cluster-should-have-a
Alexander,
Your question about n_val on a one-node server is very valid (and also the
question of, so how do you migrate to a larger n_val size when you grow
your cluster).
As an aside -- as John mentioned, Riak is designed from the ground up to be
run on multi-node clusters, so you have to keep
John, Eric,
thank you for your answers.
I understood that running Riak on one node is a bad idea. But having 5
nodes in cluster is too expensive for us right now.
Which settings I have to tune to get a decent performance on 3 node
cluster? 100% availability is not necessary for us but
small respon
With protocol buffers this is the case.
The ifNotModified() method expects you to supply a vector clock which
is then matched against the vector clock of an existing object in Riak
with that key. Since there is no object in riak ... it returns
"notfound" - it can't find it.
Unfortunately that mak
Dmitri,
thanks a lot for such a comprehensive answer!
I actually can afford some downtime but retries is not an option for me due
to response time requirements.
Of course we're going to add nodes in the future but for now we have to
deal with what we have.
On 10 June 2013 20:42, Dmitri Zagidulin
