cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7601) Data loss after nodetool taketoken
Date Thu, 24 Jul 2014 21:04:39 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073645#comment-14073645
] 

Brandon Williams edited comment on CASSANDRA-7601 at 7/24/14 9:04 PM:
----------------------------------------------------------------------

bq. In the case of 4445 addtoken how would you know what token to add where to change the
ownership enough

That's the user's problem and it's not impossible, just not trivial.

bq. Should we remove taketoken + shuffle in 2.1.0 and create addtoken in 2.1.1?

I think we should remove them in _at least_ 2.1.0.  Thinking about it a bit more, addtoken
isn't simple either because there's no way to say 'this token is joining' in gossip; it's
all or nothing.


was (Author: brandon.williams):
bq. In the case of 4445 addtoken how would you know what token to add where to change the
ownership enough

That's the user's problem and it's not impossible, not just trivial.

bq. Should we remove taketoken + shuffle in 2.1.0 and create addtoken in 2.1.1?

I think we should remove them in _at least_ 2.1.0.  Thinking about it a bit more, addtoken
isn't simple either because there's no way to say 'this token is joining' in gossip; it's
all or nothing.

> Data loss after nodetool taketoken
> ----------------------------------
>
>                 Key: CASSANDRA-7601
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7601
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core, Tests
>         Environment: Mac OSX Mavericks. Ubuntu 14.04
>            Reporter: Philip Thompson
>            Priority: Minor
>         Attachments: consistent_bootstrap_test.py, taketoken.tar.gz
>
>
> The dtest consistent_bootstrap_test.py:TestBootstrapConsistency.consistent_reads_after_relocate_test
is failing on HEAD of the git branches 2.1 and 2.1.0.
> The test performs the following actions:
> - Create a cluster of 3 nodes
> - Create a keyspace with RF 2
> - Take node 3 down
> - Write 980 rows to node 2 with CL ONE
> - Flush node 2
> - Bring node 3 back up
> - Run nodetool taketoken on node 3 to transfer 80% of node 1's tokens to node 3
> - Check for data loss
> When the check for data loss is performed, only ~725 rows can be read via CL ALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message