You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Shashilpi Krishan <Sh...@wizecommerce.com> on 2012/09/24 11:39:06 UTC

Cassandra failures while moving token

Hi

Actually problem is that while we move the token in a 12 node cluster we observe cassandra misses (no data as per cassandra for requested row key). As per our understanding we expect that when we move token then that node will first sync up the data as per the new assigned token & only after that it will receive the requests for new range. So not sure why cluster gives a miss as soon as we move token.

Is there any way/utility through which we can tell that a particular "row key" is fetched from which node so as to ensure that token move is completed fine and data is lying on correct new node and also being looked up by cluster on correct node. OR

Please tell that what is the best way out to change the tokens in the cluster.
________________________________
Thanks & Regards

Shashilpi Krishan


CONFIDENTIALITY NOTICE
======================
This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator.

Re: Cassandra failures while moving token

Posted by aaron morton <aa...@thelastpickle.com>.
>  As per our understanding we expect that when we move token then that node will first sync up the data as per the new assigned token & only after that it will receive the requests for new range. 
When you use nodetool move the node will receive write requests for the new range. As well as read and write requests for the old range. 


> So not sure why cluster gives a miss as soon as we move token.
Can you explain the query you ran and the consistency level. 

> Is there any way/utility through which we can tell that a particular “row key” is fetched from which node 

Try nodetool 
  getendpoints <keyspace> <cf> <key> - Print the end points that owns the key

It wont tell you how a particular query worked, but it will say where a row should be.

Cheers

-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com

On 24/09/2012, at 9:39 PM, Shashilpi Krishan <Sh...@wizecommerce.com> wrote:

> Hi
>  
> Actually problem is that while we move the token in a 12 node cluster we observe cassandra misses (no data as per cassandra for requested row key). As per our understanding we expect that when we move token then that node will first sync up the data as per the new assigned token & only after that it will receive the requests for new range. So not sure why cluster gives a miss as soon as we move token.
>  
> Is there any way/utility through which we can tell that a particular “row key” is fetched from which node so as to ensure that token move is completed fine and data is lying on correct new node and also being looked up by cluster on correct node. OR
>  
> Please tell that what is the best way out to change the tokens in the cluster.
> Thanks & Regards
> 
> Shashilpi Krishan
>  
> 
> CONFIDENTIALITY NOTICE
> ======================
> This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator.