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

Reply via email to