<div class="gmail_quote">This isn't really about scenarios in general, just the example you gave:<br><br>On Thu, Aug 4, 2011 at 9:33 AM, Jonathan Langevin <span dir="ltr"><<a href="mailto:firstname.lastname@example.org">email@example.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">One such scenario that I'd be interested in seeing, is a setup where you have a Riak cluster with a specific node that is used for all reads/writes of an application.
<div>The idea is to ensure that the data is always online (via cluster), but also ensure that you always have the latest version of your data (specific single node read/write).</div><div>If this primary node goes down, then just switch the application to a new primary node. That could occur via application logic or other solution that exists between application and riak cluster.</div>
</blockquote><div><br> Riak has no real notion of "primary" node(s), and you don't want to change that. (Though I guess the first node in the preference list for a given hash could be considered the "most primary"... but that's a bit different.) Anyway, you should be able to achieve strong consistency (read your last write) by keeping R + W > N. You shouldn't think of Riak in "master slave" terms you may be used to from your relational database of choice.<br>
<br><a href="http://wiki.basho.com/Tunable-CAP-Controls-in-Riak.html">http://wiki.basho.com/Tunable-CAP-Controls-in-Riak.html</a><br><a href="http://wiki.basho.com/Eventual-Consistency.html">http://wiki.basho.com/Eventual-Consistency.html</a><br>