John, welcome to Riak and the forums. Question 1: Availability.
Welcome to the list and thank you for the questions. I'm going to answer 1/3 and hopefully help you form your mental model a little bit better. The short answer is that the odds of having the kind of _un_availability you are proposing is the same as the odds of N nodes in you cluster all going down simultaneously, where N is the number of nodes hosting a particular set of data. When you specify an n_val, this is the number of partitions that your data will be replicated on. This is not the number of physical nodes. For example, if you have a single node cluster, all replicas will exist on the same node. As you increase the number of nodes in the cluster, the ring partitions will be "evenly" distributed to those nodes. However, if the number of nodes in your cluster (M) is not evenly divisible by your ring size, at the end there will be overlap, and you will have instances where an object with an n_val of 3 is only on 2 physical nodes. However, if M >=N and ring_size % M == 0, then data will be replicated to n_val physical machines. Every partition in the ring has a preference list of nodes: these are the nodes that will handle requests to that partition. These preference lists are updated as the status of various nodes change. What this means for you is that as one node goes down, another (fallback) will pick up the slack and handle the read and write requests for it. The fallback node won't (necessarily) have the data on it to handle read requests, but assuming that even 1 node hosting the data is still up, it will be read-repaired and accumulate the data that it needs. Once the primary node comes back online, any new data will be handed off to back it. So, unless all n_val partitions become unavailable simultaneously - or at least within a period of time before any fallbacks were able to read-repair, your data will still be available. One issue to be aware of is that fallbacks are not chosen with respect to primary nodes. Which node acts as a fallback is a function of which nodes are up, the ring size, etc. So it's possible that if your 3 nodes went down, a single node would be acting as the fallback for all of them (e.g. in a 4-node cluster). This is an area we are actively working to improve when enough nodes are available. Hope this helps, -- Jeffrey Massung Software Engineer [email protected] On Jan 8, 2012, at 10:30 PM, John DeTreville wrote: > (An earlier post seems not to have gone through. My apologies in the eventual > case of a duplicate.) > > I'm thinking of using Riak to replace a large Oracle system, and I'm trying > to understand its guarantees. I have a few introductory questions; this is > the first of three. > > I'm trying to understand the reliability of stored data. Imagine (for > example) that I have 5 Riak hosts, and an n_val of 3. Imagine that each host > is down 1% of the time (I bought the disks at a flood sale), and imagine that > host failures are uncorrelated, and imagine that when hosts come back up, > they stay up long enough to fully rejoin the service, and imagine that I > haven't done any writes for a long while. > > Given these assumptions, I might naïvely assume that my data are available > with a probability of about 99.999%, or down about 5 minutes a year. This > would be great (perhaps). Of course, this ignores the possibility that some > of my data may not be replicated at all, perhaps even with all three copies > on the same host. If all I know is that some data may not be replicated, then > all I know is that (some of) my data may be unavailable as much as 3.65 days > a year, which would not be nearly as great. I understand things probably > won't be this bad, but "probably" isn't a probability. > > Is this right? Is there anything I can do to guarantee higher reliability, > short of setting n_val to 5? > > Cheers, > John > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
