[
https://issues.apache.org/jira/browse/CASSANDRA-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073605#comment-14073605
]
T Jake Luciani commented on CASSANDRA-7601:
-------------------------------------------
I added some debug to the test and here is whats happening for a key that ends
up getting lost:
replicas start as node3 and node1. after moving node1's tokens to node3 the
replicas become node2 and node3. Since node3 has no data on it (since it was
down for that portion of the test) we end up having no data on node2 since
node1 didn't stream to node2.
> 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)
