[
https://issues.apache.org/jira/browse/CASSANDRA-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073610#comment-14073610
]
Brandon Williams commented on CASSANDRA-7601:
---------------------------------------------
If node1 and node3 are the replicas for a given token, and writes were made
with node3 and HH off, node3 will never have the data. Now when it takes the
token from node1, node1 won't stream anything for that token because node3
should already have it. Thus, the token moves to node3 with no transfer and
the data appears lost because it never had the data, and as it stands, node1
never streamed to node2 (which is now a replica) for some reason too. We can
fix that, but the greater issue is that moving the token to node3 can cause new
intersections that also require sending data from node3 to node2, so now we
have to coordinate all this re-replication similar to what removenode does,
which is not simple.
> 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)
