On 10 January 2013 13:07, Ryan Lowe <ryanjl...@gmail.com> wrote: > I have heard before that the recommended minimum cluster size is 4 (with > replication factor of 3). I am curious to know if vnodes would change that > or if that statement was valid to begin with!
The reason that RF=3 is recommended is that it is the minumum RF that allows you to have both strong consistency and tolerate one node failure (reading and writing at consistency level = QUORUM). With RF=2 for example you would have to choose between having strong consistency (read/write at CL=QUORUM) or tolerating one node failure (read/write at CL=ONE). > The use case I am working on is one where we see tremendous amount of load > for just 2 days out of the week and the rest of the time the cluster is > pretty much idle. It appears that vnodes will allow me to auto-scale the > clusters size a little easier, The key advantage of vnodes in this case is that you do not need to manually rebalance the cluster when adding or removing nodes. > but I am wondering what is the smallest I can > get the cluster in physical server count and still have a good replication > count. 3 nodes at RF=3 would be the smallest advisable size. You could even drop this to 2 nodes if you did not need consistency or availability guarantees during the time the cluster is at the smallest size. > I'll panic about having 1 of 2 or 1 of 3 servers going down in an outage as > a separate topic alone at night while not sleeping. Make sure that you over-provision sufficiently so that 2 nodes can handle the load that 3 nodes would normally be taking in the event that a node fails! (Or more generally, ensure N-1 nodes can handle the load of N nodes). Testing a simulated load on a test cluster with one node failure is always a good way to increase your confidence about availability and explore any potential degradation in your client application (latency etc.). > Thanks! > Ryan -- Sam Overton Acunu | http://www.acunu.com | @acunu
