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.