The key is that an RF of 2 and a cluster size of 3 means that every piece of data is owned by 2 nodes, and the assignment of data to the 2 nodes responsible for that data is determined by positions in the hash ring, not by what's up and running. So if you have nodes A, B, and C, and a given key hashes to nodes A and B, then taking down either A or B will prevent a quorum write to those two nodes from succeeding.
Edmond On Fri, Nov 20, 2009 at 2:14 PM, B. Todd Burruss <[email protected]> wrote: > not really. it seems that if i start with 3 nodes, remove 1 of them, i > should still have a quorum, which is 2. this is not what i experience. > > On Fri, 2009-11-20 at 16:03 -0600, Jonathan Ellis wrote: >> Oh, okay. Then it's working as expected. >> >> Does it make more sense to you now? :) >> >> -Jonathan >> >> On Fri, Nov 20, 2009 at 3:43 PM, B. Todd Burruss <[email protected]> wrote: >> > this was on the build i got yesterday, 882359. >> > >> > ... and you are correct about if you start with 2 nodes and take one >> > down - there isn't a quorum and the write/read fails. i tested that as >> > well. >> > >> > thx! >> > >> > >> > On Fri, 2009-11-20 at 15:30 -0600, Jonathan Ellis wrote: >> >> On Fri, Nov 20, 2009 at 11:31 AM, B. Todd Burruss <[email protected]> >> >> wrote: >> >> > one more point on this .. if i only start a cluster with 2 nodes, and i >> >> > use the same config setup (RF=2, etc) .. it works fine. it's only when >> >> > i start with the 3 nodes and remove 1. in fact, i remove the node >> >> > before i do any reads or writes at all, completely fresh database. >> >> >> >> That sounds like a bug. If you have 2 nodes, RF of 2, and take one >> >> node down then quorum anything should always fail. >> >> >> >> Is this on trunk still? >> >> >> >> -Jonathan >> > >> > >> > > > >
