Do you mean the ring does not change until the move has completed? On Mon, Jul 4, 2011 at 4:49 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote:
> > > On Mon, Jul 4, 2011 at 10:21 AM, Paul Loy <ketera...@gmail.com> wrote: > >> Well, by issuing a nodetool move when a node is under high load, you >> basically make that node unresponsive. That's fine, but a nodetool move on >> one node also means that that node's replica data needs to move around the >> ring and possibly some replica data from the next (or previous) node in the >> ring. So how does this affect other nodes wrt RF and quorum? Will quorum >> fail until the replicas have moved also? >> >> On Mon, Jul 4, 2011 at 3:08 PM, Dan Hendry <dan.hendry.j...@gmail.com>wrote: >> >>> Moving nodes does not result in downtime provide you use proper >>> replication factors and read/write consistencies. The typical recommendation >>> is RF=3 and QUORUM reads/writes.**** >>> >>> ** ** >>> >>> Dan**** >>> >>> ** ** >>> >>> *From:* Paul Loy [mailto:ketera...@gmail.com] >>> *Sent:* July-04-11 5:59 >>> *To:* user@cassandra.apache.org >>> *Subject:* Re: How to scale Cassandra?**** >>> >>> ** ** >>> >>> That's basically how I understand it. >>> >>> However, I think it gets better with larger clusters as the proportion of >>> the ring you move around at any time is much lower.**** >>> >>> On Mon, Jul 4, 2011 at 10:54 AM, Subscriber <subscri...@zfabrik.de> >>> wrote:**** >>> >>> Hi there, >>> >>> I read a lot of Cassandra's high scalability feature: allowing seamless >>> addition of nodes, no downtime etc. >>> But I wonder how one will do this in practice in an operational system. >>> >>> In the system we're going to implement we're expecting a huge number of >>> writes with uniformly distributed keys >>> (the keys are given and cannot be generated). That means using >>> RandomPartitioner will (more or less) result in >>> the same work-load per node as any other OrderPreservePartitioner - >>> right? >>> >>> But how do you scale a (more or less) balanced Cassandra cluster? I think >>> that in the end >>> you always have to double the number of nodes (adding just a handful of >>> nodes disburdens only the split regions, the >>> work-load of untouched regions will grow with unchanged speed). >>> >>> This seems to be ok for small clusters. But what do you do with when you >>> have several 100s of nodes in your cluster? >>> It seems to me that a balanced cluster is a bless for performance but a >>> curse for scalability... >>> >>> What are the alternatives? One could re-distribute the token ranges, but >>> this would cause >>> downtimes (AFAIK); not an option! >>> >>> Is there anything that I didn't understand or do I miss something else? >>> Is the only left strategy to make sure that >>> the cluster grows unbalanced so one can add nodes to the hotspots? >>> However in this case you have to make sure >>> that this strategy is lasting. Could be too optimistic... >>> >>> Best Regards >>> Udo**** >>> >>> >>> >>> >>> -- >>> --------------------------------------------- >>> Paul Loy >>> p...@keteracel.com >>> http://uk.linkedin.com/in/paulloy**** >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 9.0.901 / Virus Database: 271.1.1/3743 - Release Date: 07/04/11 >>> 02:35:00**** >>> >> >> >> >> -- >> --------------------------------------------- >> Paul Loy >> p...@keteracel.com >> http://uk.linkedin.com/in/paulloy >> > > No. If you are using nodetool move (or any of the nodetool operations) > quorum and replication factor is properly maintained. > -- --------------------------------------------- Paul Loy p...@keteracel.com http://uk.linkedin.com/in/paulloy
